В настоящее время у меня возникают некоторые проблемы на работе, когда наш веб находится под ssl и используется порт 443. я нашел это интернет сайт который проверяет статус вашего сервера. Там написано, что 443 закрыта.
Port 443 is closed on xx.xxx.xx.xxx.
Через некоторое время я все перепробовал и не знаю, что делаю не так.
netstat показывает это:
sudo netstat -anltp | grep LISTEN
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
И
netstat -nap | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 27898/nginx
tcp 1 0 127.0.0.1:34371 127.0.0.1:443 CLOSE_WAIT 25998/openssl
Предполагается, что nginx прослушивает этот порт, верно?
Выглядит именно так, потому что если я использую клиент openssl, я получаю:
openssl s_client -connect 127.0.0.1:443
CONNECTED(00000003)
Но когда я пытаюсь связаться со своим сервером извне, используя порт 443, я получаю время ожидания соединения.
openssl s_client -connect xx.xx.xx.xx:443
connect: Connection timed out
connect:errno=110
А вот правила iptable
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
Chain ufw-after-forward (0 references)
target prot opt source destination
Chain ufw-after-input (0 references)
target prot opt source destination
Chain ufw-after-logging-forward (0 references)
target prot opt source destination
Chain ufw-after-logging-input (0 references)
target prot opt source destination
Chain ufw-after-logging-output (0 references)
target prot opt source destination
Chain ufw-after-output (0 references)
target prot opt source destination
Chain ufw-before-forward (0 references)
target prot opt source destination
Chain ufw-before-input (0 references)
target prot opt source destination
Chain ufw-before-logging-forward (0 references)
target prot opt source destination
Chain ufw-before-logging-input (0 references)
target prot opt source destination
Chain ufw-before-logging-output (0 references)
target prot opt source destination
Chain ufw-before-output (0 references)
target prot opt source destination
Chain ufw-reject-forward (0 references)
target prot opt source destination
Chain ufw-reject-input (0 references)
target prot opt source destination
Chain ufw-reject-output (0 references)
target prot opt source destination
Chain ufw-track-input (0 references)
target prot opt source destination
Chain ufw-track-output (0 references)
target prot opt source destination
Любое предложение будет оценено.
Спасибо.
ОБНОВЛЕНИЕ: я забыл упомянуть, что на самом деле брандмауэр не работает:
ufw status
Status: inactive
Сначала некоторые проверки:
P.S. Учитывая ваше редактирование (nginx прослушивает порт 443), это похоже на проблему с брандмауэром. Обратите внимание, что существует два типа межсетевых экранов: внутренний (работает на вашем сервере) и внешний (работает на другом компьютере, который контролирует доступ к сети вашего сервера). Ваше обновление показывает только то, что внутреннего брандмауэра нет.
Если вы используете какую-либо службу хостинга, например Amazon Web Services, которая предоставляет интерфейсный интерфейс, поищите группы безопасности, применимые к вашему экземпляру запущенного узла.
В моем случае мне просто нужно было добавить исключение 443 к разрешенным службам, и все.