☰

¿Qué causaría la "Conexión rechazada" con la configuración más simple de nginx centos en GCE?

tag-icon • tag-icon nginx firewall reverse-proxy google-cloud-platform node.js
¿Qué causaría la "Conexión rechazada" con la configuración más simple de nginx centos en GCE?

Actualizar

Seguí los mismos pasos que se indican a continuación, excepto en un VPS genérico proporcionado (no Google) y funcionó según lo previsto, incluidos pasos no enumerados, como habilitar HTTPS con Certbot... Así que mi presunción es que hay alguna configuración especial en GCE que estoy malentendido/mal uso/no hacer eso está causando el problema que se describe a continuación. ¿Alguna idea sobre qué podría ser esa cosa en la CME?

Configuración

Tengo una instancia de Google Cloud Compute Engine con Debian instalado. De forma predeterminada, durante la configuración de esta instancia de GCE, permití el tráfico HTTP y HTTPS a través de las opciones de firewall de GCE proporcionadas. Entré a la instancia de GCE a través de SSH e hice lo siguiente:

Captura de pantalla de la concesión del permiso http/https de GCEEvidencia de que GCE permite el tráfico.

1.) Nginx y ufw instalados

sudo apt install nginx ufw

2.) Se habilitaron las reglas de UFW que permiten conexiones HTTP, HTTPS y SSH.

sudo ufw allow (http/https/ssh)
sudo systemctl enable ufw
sudo systemctl start ufw

3.) Nginx habilitado dejando la configuración predeterminada

sudo systemctl enable nginx
sudo nginx -t ( returned "ok" results )
sudo systemctl start nginx

4.) Me aseguré de que mi dominio apuntara a la IP correcta

Pruebas

Pruebas de rizado

Cuando visito el dominio, todavía aparece el error "dominio.com se negó a conectarse" si ejecuto

curl localhost

Obtengo el contenido predeterminado esperado si entro

Comprobación de netstat

netstat -a

Puedo ver que estoy escuchando el mundo exterior en los puertos adecuados.

tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN

cheque UFW

Si reviso las reglas de mi firewall veo lo siguiente

sudo ufw status
SSH                        ALLOW       Anywhere                  
224.0.0.251 mDNS           ALLOW       Anywhere                  
22                         ALLOW       Anywhere                  
80                         ALLOW       Anywhere                  
443                        ALLOW       Anywhere                  
3000                       ALLOW       Anywhere                  
SSH (v6)                   ALLOW       Anywhere (v6)             
ff02::fb mDNS              ALLOW       Anywhere (v6)             
22 (v6)                    ALLOW       Anywhere (v6)             
80 (v6)                    ALLOW       Anywhere (v6)             
443 (v6)                   ALLOW       Anywhere (v6)             
3000 (v6)                  ALLOW       Anywhere (v6)

Lo que creo indica que mis puertos están abiertos correctamente.

Comprobación de ping

Puedo hacer ping a mi servidor por dominio y regresa correctamente con la IP esperada.

Pinging FizzBuzz.app [cor.rec.t.IP] with 32 bytes of data:
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=33ms TTL=57
Reply from cor.rec.t.IP: bytes=32 time=34ms TTL=57

Ping statistics for cor.rec.t.IP:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum = 34ms, Average = 33ms

Comprobación de registro

Cuando visito /var/log/nginx/error.log está vacío (después de visitar el dominio con un resultado fallido)

Cuando visito /var/log/nginx/access.log, tiene una única entrada para cuando verifiqué si "curl localhost" funcionaba (y así fue).

Entonces, lo mejor que puedo decir es que nginx no muestra ningún error.

Conclusión

A partir de ahora, he agotado todas las vías posibles para resolver este problema, excepto desembolsar directamente el soporte de Google... Estoy intentando utilizar el caso de uso más simple posible para minimizar las variables y todavía me encuentro con un mensaje "se negó a "Error de conexión" al visitar mi sitio a través de la IP o el dominio cuando está alojado en Google, cuando lo tengo alojado en otros 2 proveedores funciona bien. ¿Conclusión? Estoy desconcertado...

Respuesta1

Puedo ver 3 puntos principales en su pregunta: la aplicación nodejs como backend, nginx no escucha en el puerto 443 y configuración de proxy inverso. Analicémoslo para ver cada punto aislado.

  1. Aplicación nodejs: intente acceder a ella desde localhost y confirme que responde correctamente

rizohttp://127.0.0.1/3000

  1. nginx no escucha en el puerto 443: debe configurar un bloque de servidor en nginx para eso, y también es una buena idea redirigir de HTTP a HTTPS:
server {
    listen 80 default_server;
    server_name fizzbuzz.app www.fizzbuzz.app;
    return 301 https://fizzbuzz.app$request_uri;
}


server {
    listen 8443 ssl;
    server_name fizzbuzz.app www.fizzbuzz.app;

    index index.html index.htm;

    access_log /var/log/nginx/fizzbuzz-access.log;
    error_log /var/log/nginx/fizzbuzz-error.log error;

     location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
     }

    ssl_certificate     /etc/ssl/certs/fizzbuzz.app-fullchain.pem;
    ssl_certificate_key /etc/ssl/private/fizzbuzz.app.key;
}

Para emitir su certificado, le sugiero que utilice certbot o un script ACME.

es decir, usando acme.sh puede emitir un certificado usando el comando:

/root/.acme.sh/acme.sh --issue --nginx -d fuzzbuzz.app -d www.fuzzbuzz.ap

/root/.acme.sh/acme.sh --install-cert -d fuzzbuzz.app -d www.fuzzbuzz.app \
--cert-file /etc/ssl/certs/fuzzbuzz.app.crt \
--key-file /etc/ssl/certs/fuzzbuzz.app.key \
--fullchain-file ${CERTS_DIR}/fuzzbuzz.app-fullchain.pem \
--log /var/log/acme_log \
--reloadcmd "systemctl restart nginx"

Después de haber emitido su certificado y tenerlo en su lugar, reinicie nginx y pruébelo

  1. El tercer punto es configurar nginx como proxy inverso para exponer su aplicación a través de HTTPS. Creo que la configuración anterior debería funcionar. En caso de que no sea así, le sugiero que lea este documento de GoCD que explica exactamente este tipo de configuración:

Configurar un proxy inverso

Respuesta2

¡¡¡ME LO IMAGINÉ!!!

.APLICACIÓN! ¡¡¡Fue el TLD .app todo este tiempo!!!

Me dirigía a comprar un nombre de dominio aleatorio para proporcionar un nombre y una IP a un comentarista, seleccioné uno .app solo por diversión (se me ocurrió un nombre tonto para esta prueba) y leí esto: ".APP es un espacio de nombres Puede comprar Foobarington.app ahora, pero necesitará un certificado SSL para conectarse al sitio web. Obtenga más información sobre los espacios de nombres seguros y cómo obtener un certificado SSL.

¡ENTONCES! Cuando intenté apuntar mi dominio .app al servidor, no se cargaba porque mi servidor en ese momento no tenía un certificado SSL. Tenía la intención de usar CertBot para obtener el certificado, pero inicialmente requieren acceso http para realizar la concesión automática del certificado.

Necesito descubrir cómo hacer que Certbot (o una solución equivalente) funcione para mí usando este tipo de TLD y host, pero definitivamente es el tipo de TLD que tengo el que generó este problema.

información relacionada