Вопрос или проблема
Я пытался диагностировать проблему, когда любой HTTPS-запрос к моему VPS возвращает ошибку ERR_CONNECTION_CLOSED. Я использую Let’s Encrypt, реализованный на NGINX, в то время как веб-сервером является приложение на Node.js.
Сайт обслуживается под конкретным поддоменом, скажем, это mysub.domain.com.
Вот что показывает сканирование Nmap на mysub.domain.com:
443/tcp open https?
А вот что показывает аналогичное сканирование на публичном IP-адресе:
443/tcp closed https
У моего VPS нет брандмауэра, по крайней мере, на самом хосте. Вот вывод команды iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
ОБНОВЛЕНИЕ Вот вывод команды netstat -tlpdn
Активные интернет-соединения (только серверы)
Протокол Recv-Q Send-Q Локальный адрес Удаленный адрес Состояние PID/Имя программы
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 367/sshd
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 7283/nginx -g daemo
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 773/mysqld
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7283/nginx -g daemo
tcp6 0 0 :::22 :::* LISTEN 367/sshd
tcp6 0 0 :::8080 :::* LISTEN 5873/nodejs
ОБНОВЛЕНИЕ Вот содержимое sites-available/default NGINX
server {
listen 443 ssl;
server_name mysub.domain.com;
ssl_certificate /etc/letsencrypt/live/mysub.domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysub.domain.com/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15768000;
location / {
proxy_pass http://localhost:8080;
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;
}
}
server {
listen 80;
server_name mysub.domain.com;
return 301 https://$host$request_uri;
}
Администратор объекта, где находится VPS, сообщил мне, что они открыли порт 443. Не хватает ли чего-то? Или это моя ошибка?
Как оказалось, администратор действительно упустил что-то. Объект реализует какой-то странный NAT/IP-перенаправитель и забыл перенаправить трафик на порт 443 к моему VPS.
Ответ или решение
Порт 443 закрыт в сканированиях Nmap: анализ проблемы и решение
Введение
При диагностике проблемы с доступом к вашему VPS, возвращающего ошибку ERR_CONNECTION_CLOSED при HTTPS запросах, важно правильно понимать работу сетевых протоколов и настройки вашего веб-сервера. В этом случае вы провели сканирование с помощью Nmap и получили неоднозначные результаты: порт 443 кажется открытым при сканировании поддомена, но закрытым при сканировании по публичному IP-адресу. В этой статье мы детально разберем причины такой ситуации и предложим возможные решения.
Анализ ситуации
1. Результаты сканирования Nmap:
-
mysub.domain.com:
443/tcp open https? -
Публичный IP-адрес:
443/tcp closed httpsЭти результаты указывают на то, что сервер, вероятно, настроен на обработку запросов на HTTPS для поддомена, но не отвечает на запросы напрямую по IP. Это может происходить из-за нескольких причин.
2. Настройки NGINX:
Ваш файл конфигурации NGINX правильно настроен для прослушивания порта 443 с SSL, а также имеется соответствующий редирект с порта 80 на 443, что критично для безопасного доступа. Однако, чтобы правильно функционировать, NGINX должен получать трафик на этот порт от сети.
3. Вывод iptables:
Ваши правила iptables показывают, что входящий, исходящий и пересылаемый трафик не блокируется, что указывает на то, что на уровне ОС нет ограничений.
4. Состояние службы:
Согласно выводу netstat, NGINX действительно слушает на порту 443:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 7283/nginx -g daemoВозможные причины
1. Проблемы с NAT/IP-форвардингом:
Как выяснилось, администраторы хостинга забыли настроить NAT или IP-форвардинг для порта 443, чтобы трафик корректно направлялся на ваш VPS. Это распространённая проблема, которая может возникнуть в средах с виртуализацией или сложной сетевой инфраструктурой.
2. Ошибки конфигурации на стороне провайдера:
Если ваш провайдер использует многоуровневую архитектуру маршрутизации, возможно, они не учли правила для HTTPS. Это может привести к тому, что трафик не доходит до вашего VPS на порту 443.
Рекомендации по устранению
-
Проверка настроек NAT: Свяжитесь с вашим провайдером и подтвердите, что они правильно настроили перенаправление трафика на порту 443.
-
Тестирование подключения: Попробуйте выполнить telnet или ncat на порт 443 вашего публичного IP-адреса, чтобы проверить, доступен ли порт.
telnet <ваш_IP> 443 -
Логи NGINX: Просмотрите логи NGINX (
access.logиerror.log), чтобы увидеть, есть ли попытки подключения на порт 443. -
Изучение документации провайдера: Убедитесь, что вы понимаете возможные ограничения и требования вашего хостинга.
-
Повторное тестирование после исправлений: После внесения изменений протестируйте доступность порта 443 снова с помощью Nmap.
Заключение
Проблемы с подключением к порту 443 могут быть обусловлены множеством факторов, включая ошибки конфигурации на уровне вашего VPS или на стороне провайдера. Главное, что необходимо сделать — это часть работы по устранению проблемы — это последовательное тестирование и работа с технической поддержкой для выяснения причин закрытого порта. Надеюсь, данная информация поможет вам в решении вашей проблемы.