Как проверить, открыт ли брандмауэр для порта, но не прослушивается порт

Мы будем развертывать новое приложение на сервере, и приложение будет прослушивать порт 8443. Мы попросили команду Network открыть брандмауэр для порта 8443 на этом сервере перед развертыванием приложения. В настоящее время приложение не прослушивает данный порт на сервере.

В любом случае я могу убедиться, что брандмауэр открыт для порта 8443

ОС: Solaris 10 10/09 s10s_u8wos_08a SPARC

5 Solutions collect form web for “Как проверить, открыт ли брандмауэр для порта, но не прослушивается порт”

Если вы хотите узнать, можете ли вы сформировать TCP-соединение с удаленной машины, установите OpenCSW на этом и целевом компьютере и установите netcat на обоих. Это синтаксис использования netcat для проверки соединений TCP:

nc -vz targetServer portNum

Например, чтобы проверить SSH на «homeServer1»:

nc -vz homeserver1 22

Это позволяет вам тестировать подключение на уровне TCP от удаленной системы. Netcat также может быть настроен для прослушивания на порту, а не для работы в качестве клиента. Чтобы прослушать его на TCP / 8443:

На сервере, на котором будет nc -l homeserver1 8443 приложение: nc -l homeserver1 8443

На машине, которая находится за пределами брандмауэра: nc -vz homeserver.fqdn 8443

Это пример успешного выполнения:

 [jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443 Connection to ditirlns01.ncat.edu 8443 port [tcp/pcsync-https] succeeded! 

Неудачное выполнение:

 [jadavis6@ditirlns01 ~]$ nc -vz ditirlns01.ncat.edu 8443 nc: connect to ditirlns01.ncat.edu port 8443 (tcp) failed: Connection refused 

Брандмауэры должны отвечать сообщением ICMP, когда они блокируют запрос. Однако это не обязательно так (вам будет интересна эта хорошая статья ).

Вы можете протестировать снаружи, чтобы узнать, доступен ли порт через брандмауэр, и если да, то что-нибудь слушает. Вот три разных сценария, связанных с запросом tcp, который вы можете наблюдать с помощью wireshark , или с каким-либо другим сниффером пакетов, и тем, что вы увидите:

1) Брандмауэр отклоняет запрос

Вы получите сообщение ICMP, и инструмент, делающий запрос, должен немедленно сообщить вам об этом («недоступный, запрещенный администратором» и т. Д.). Под «инструментом» я подразумеваю клиент, который вы используете для отправки запроса (я использовал telnet ).

«Нет маршрута к хосту» может указывать на это, но это может также указывать на более тонкие проблемы маршрутизации.

2) Брандмауэр отбрасывает пакет

Ответ отсутствует, поэтому инструмент ждет, пока он не выйдет из строя или вам не станет скучно.

3) Брандмауэр разрешает пакет (или нет брандмауэра), но ничто не слушает порт.

Появляется сообщение TCP RST / ACK. Я предполагаю, что протокол TCP требует этого. Другими словами, если ничто не слушает порт, сама ОС отправляет этот ответ. Это может быть трудно отличить от # 1 только на основе того, что сообщает инструмент, потому что в обоих случаях он может сказать то же самое (однако, скорее всего, это отличает это как «отказ от соединения» по сравнению с №1, «недоступность сети», ). Сценарий № 1 (сообщение об отклонении ICMP) и # 3 (сообщение TCP RST / ACK), наблюдаемое в пакете сниффера на клиентской машине, отчетливо отличается.

Единственный другой вариант здесь – это то, что пакет разрешен брандмауэром и что-то прослушивается, поэтому вы получаете успешное соединение.

Другими словами: предполагая, что ваша сеть в целом работает правильно, если вы получаете # 1 или # 2, это означает, что брандмауэр активно предотвращает доступ к порту. # 3 произойдет, если ваш сервер не запущен, но порт доступен, и, конечно, (неявное) # 4 – успешное соединение.

Вы можете использовать команду netstat чтобы увидеть, открыт ли порт и прослушивается.

пример

 $ netstat -anp | less Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:41716 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:17500 0.0.0.0:* LISTEN 3034/dropbox tcp 0 0 0.0.0.0:17501 0.0.0.0:* LISTEN 3033/dropbox tcp 0 0 127.0.0.1:2143 0.0.0.0:* LISTEN 3191/ssh tcp 0 0 127.0.0.1:2025 0.0.0.0:* LISTEN 3191/ssh 

На выходе отображаются процессы (столбец справа налево) , которые прослушивают порты TCP. Номера портов – это номера, которые следуют за двоеточиями после IP-адресов (например, 0.0.0.0:111 – это порт 111).

IP-адреса показывают локальные и внешние адреса . Локальная будет вашей системой, а Foreign – любыми адресами, которые могут быть подключены к вашему TCP-порту или подключены к одному из их TCP-портов.

Так что в случае порта 22, это демон ssh, запущенный в моей системе, это LISTENING для соединений. Как только кто-то пытается подключиться к ssh , он выдает копию самого себя и выталкивает это соединение на другой порт, сохраняя TCP-порт 22 открытым для дополнительных подключений по мере их поступления.

Конфигурация и состояние конфигурации брандмауэра зависят от брандмауэра / ОС.

Что вы можете сделать, это попробовать его с сервера2:

 nmap server1 

Вы можете использовать онлайн-инструмент, например http://www.firewallruletest.com, чтобы узнать, могут ли внешние хосты устанавливать соединения tcp.

  • Скрипт Socat exec в туннеле
  • Убейте любую службу, запущенную на определенном порту
  • открытие порта 7 (порт эха) на Linux / Debian
  • Разница между MTU для маршрута и MTU для интерфейса
  • SSH-подобный сеанс, который выживает при отключении физической сети
  • socat duplicate stdin для каждого подключенного клиента
  • В linux «/ proc / sys / net / ipv4 / tcp_keepalive_time» влияет как на клиента, так и на сервер?
  • Как перенаправить / переправить между устройством tun / tap и сокетом с помощью Linux-инструментов?
  • Как включить удаленные подключения Tcp \ Ip в Centos 7.0
  • Почему гидра не отключается?
  • Регистратор данных на основе tcpdump
  • Linux и Unix - лучшая ОС в мире.