O que causaria "Conexão recusada" com a configuração mais simples do nginx centos no GCE?

Question

Atualizar

Segui as mesmas etapas abaixo, exceto em um VPS genérico fornecido (não o Google) e funcionou conforme previsto, incluindo etapas não listadas, como ativar HTTPS com Certbot... Portanto, presumo que haja alguma configuração especial no GCE que estou mal-entendido/uso indevido/não fazer isso está causando o problema descrito abaixo. Alguma idéia do que poderia ser essa coisa no GCE?

Configurar

Tenho uma instância do Google Cloud Compute Engine com Debian instalado. Por padrão, durante a configuração desta instância do GCE, permiti o tráfego HTTP e HTTPS por meio das opções de firewall do GCE fornecidas. Entrei na instância do GCE via SSH e fiz o seguinte:

Captura de tela da concessão de permissão http/https do GCEEvidência de GCE permitindo o tráfego

1.) Nginx e ufw instalados

sudo apt install nginx ufw

2.) Habilitadas regras do UFW permitindo conexões HTTP, HTTPS e SSH

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

3.) Habilitou o nginx deixando a configuração padrão

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

4.) Garanti que meu domínio estivesse apontado para o IP correto

Testes

Testes de ondulação

Quando visito o domínio, ainda recebo o erro "domain.com recusou-se a conectar" Se eu executar

curl localhost

Eu recebo o conteúdo padrão esperado se eu entrar

Verificação de Netstat

netstat -a

Posso ver que estou ouvindo o mundo exterior nos portos apropriados

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  

Verificação UFW

Se eu verificar minhas regras de firewall, vejo o seguinte

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)  

O que acredito indica que minhas portas estão abertas corretamente.

Verificação de ping

Consigo fazer ping no meu servidor pelo domínio e ele retorna corretamente com o IP esperado.

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

Verificação de registro

Quando visito /var/log/nginx/error.log ele está vazio (depois de visitar o domínio com resultado com falha)

Quando visito /var/log/nginx/access.log, ele tem uma única entrada para quando verifiquei se "curl localhost" funcionou (o que funcionou)

Então, pelo que posso dizer, o nginx não está mostrando nenhum erro.

Conclusão

No momento, esgotei todos os caminhos possíveis para resolver esse problema, exceto pagar diretamente pelo suporte do Google... Estou tentando usar o caso de uso mais simples possível para minimizar variáveis ​​e ainda estou com um "recusou-se a connect" erro ao visitar meu site através do IP ou do domínio quando ele é hospedado pelo Google, quando eu o hospedei por 2 outros provedores, ele funciona perfeitamente. Conclusão? Estou confuso...

Answer 1

Posso ver três pontos principais em sua pergunta: aplicativo nodejs como backend, nginx não escutando na porta 443 e configuração de proxy reverso. Vamos decompô-lo para observar cada ponto isolado.

1. aplicativo nodejs: tente acessá-lo no localhost e confirme se está respondendo corretamente

ondulaçãohttp://127.0.0.1/3000

2. nginx não escuta na porta 443: Você deve configurar um bloco de servidor no nginx para isso, e também é uma boa ideia redirecionar de HTTP para 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 seu certificado, sugiro que você use o certbot ou um script ACME.

ou seja, usando acme.sh você pode emitir um certificado usando o 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"

Depois de emitir seu certificado e colocá-lo em vigor, reinicie o nginx e teste-o

3. O terceiro ponto é configurar o nginx como proxy reverso para expor seu aplicativo via HTTPS. Acho que a configuração acima deve funcionar. Caso isso não aconteça, sugiro que você leia este documento do GoCD que explica exatamente esse tipo de configuração:

Configurar um proxy reverso

Answer 2

Eu descobri!!!

.APLICATIVO! Foi o TLD .app o tempo todo!!!

Eu estava indo comprar um nome de domínio aleatório para fornecer um nome e IP a um comentarista, selecionei um .app só por diversão (tive um nome bobo pensado para este teste) e li isto: ".APP é um seguro namespace. Você pode comprar Foobarington.app agora, mas será necessário um certificado SSL para conexão com o site. Saiba mais sobre namespaces seguros e como obter um certificado SSL.

ENTÃO! Quando tentei apontar meu domínio .app para o servidor, ele não carregou porque meu servidor naquele momento não tinha um certificado SSL. Eu pretendia usar o CertBot para obter o certificado, mas eles exigem acesso http inicialmente para fazer a concessão automatizada do certificado.

Preciso descobrir como fazer com que o Certbot (ou solução equivalente) funcione para mim usando esse tipo de TLD e host, mas é definitivamente o tipo de TLD que tenho que gerou esse problema!