☰

Что может вызвать ошибку «Connection Refused» при простейшей настройке nginx centos на GCE?

tag-icon • tag-icon nginx firewall reverse-proxy google-cloud-platform node.js
Что может вызвать ошибку «Connection Refused» при простейшей настройке nginx centos на GCE?

Обновлять

Я выполнил те же шаги, что и ниже, за исключением предоставленного универсального VPS (не Google), и все сработало, как и ожидалось, включая неперечисленные шаги, такие как включение HTTPS с помощью Certbot... Поэтому я предполагаю, что в GCE есть какая-то особая конфигурация, которую я неправильно понимаю/неправильно использую/не делаю, что и вызывает описанную ниже проблему. Есть идеи, что это может быть за штука в GCE?

Настраивать

У меня есть экземпляр Google Cloud Compute Engine с установленным на нем Debian. По умолчанию, во время настройки этого экземпляра GCE, я разрешил трафик HTTP и HTTPS через предоставленные параметры брандмауэра GCE. Я вошел в экземпляр GCE через SSH и сделал следующее:

Снимок экрана предоставления разрешения GCE http/httpsДоказательство GCE, разрешающего движение

1.) Установлены nginx и ufw

sudo apt install nginx ufw

2.) Включены правила UFW, разрешающие соединения HTTP, HTTPS и SSH.

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

3.) Включил nginx, оставив конфигурацию по умолчанию

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

4.) Убедился, что мой домен направлен на правильный IP-адрес.

Тесты

Тесты по керлингу

Когда я захожу на домен, я все еще получаю ошибку «domain.com отказано в подключении». Если я выполняю

curl localhost

Я получаю ожидаемый контент по умолчанию. Если я ввожу

проверка Netstat

netstat -a

Я вижу, что слушаю внешний мир через нужные порты.

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

проверка UFW

Если я проверю правила брандмауэра, то увижу следующее

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)

Я считаю, что это означает, что мои порты открыты правильно.

Проверка пинга

Я могу пропинговать свой сервер по домену, и он возвращает правильный IP-адрес.

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

Проверка регистрации

Когда я захожу в /var/log/nginx/error.log, он пуст (после посещения домена с неудачным результатом)

Когда я захожу в /var/log/nginx/access.log, там есть одна запись, когда я проверял, сработал ли «curl localhost» (что и произошло).

Насколько я могу судить, nginx не выдает никаких ошибок.

Заключение

На данный момент я исчерпал все возможные пути решения этой проблемы, за исключением прямого обращения в службу поддержки Google... Я пытаюсь использовать максимально простой возможный вариант использования, чтобы минимизировать переменные, и все еще сталкиваюсь с ошибкой «отказано в подключении» при посещении моего сайта через IP или домен, когда он размещен в Google, когда он размещен у 2 других провайдеров, он работает просто отлично. Вывод? Я в замешательстве...

решение1

Я вижу 3 основных пункта в вашем вопросе: приложение nodejs как бэкенд, nginx не слушает порт 443 и конфигурация обратного прокси. Давайте разберем это, чтобы рассмотреть каждый пункт изолированно.

  1. приложение nodejs: попробуйте получить к нему доступ с локального хоста и убедитесь, что оно отвечает правильно

завитокhttp://127.0.0.1/3000

  1. nginx не прослушивает порт 443: для этого необходимо настроить блок сервера на nginx, а также хорошей идеей будет перенаправление с HTTP на 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;
}

Для выдачи сертификата я предлагаю вам использовать certbot или один скрипт ACME.

т.е. используя acme.sh вы можете выпустить сертификат с помощью команды:

/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"

Выпустив сертификат и установив его, перезапустите nginx и проверьте его.

  1. Третий пункт — настройка nginx как обратного прокси для предоставления вашего приложения через HTTPS. Я думаю, что конфигурация выше должна работать. Если нет, я предлагаю вам прочитать этот документ с GoCD, который объясняет именно этот тип конфигурации:

Настройте обратный прокси-сервер

решение2

Я ПОНЯЛ!!!

.APP! Все это время это был домен верхнего уровня .app!!!

Я собирался купить случайное доменное имя, чтобы предоставить имя и IP комментатору, выбрал .app просто ради прикола (придумал глупое имя для этого тестирования) и прочитал это: «.APP — это защищенное пространство имен. Вы можете купить Foobarington.app сейчас, но для подключения к веб-сайту потребуется сертификат SSL. Узнайте больше о защищенных пространствах имен и о том, как получить сертификат SSL

ТАК! Когда я попытался указать свой домен .app на сервере, он не загрузился, потому что на тот момент у моего сервера не было SSL-сертификата. Я намеревался использовать CertBot для получения сертификата, но изначально им требуется http-доступ для выполнения автоматизированной выдачи сертификатов.

Мне нужно выяснить, как заставить Certbot (или эквивалентное решение) работать для меня, используя этот тип TLD и хост, но именно тип TLD, который у меня есть, и привел к этой проблеме!

Связанный контент