26
July
2024
Почему недоступен хост "ports filtered". Решение проблемы
16:36

Почему недоступен хост "ports filtered". Решение проблемы

26 July 2024 16:36

При подключении к домашнему ПК с работы состояние портов "filtered". Причины и решения.

Отказ от ответственности (Disclaimer): данная статья носит ознакомительный характер и отражает точку зрения автора. Данное сообщение не является "руководством к действию", а лишь содержит рецепты по поводу разрешения ситуации. Более тщательный анализ данной проблемы могут предоставить соответствующие курсы повышения квалификации в области сетевых технологий. СТАТЬЯ НЕ ЯВЛЯЕТСЯ УЧЕБНЫМ МАТЕРИАЛОМ.

Ситуация: при подключении к домашней сети извне, невозможно подключиться к хосту (машине), состояние портов "Filtered".

Что значит состояние порта filtered?

При выполнении команды с localhost домашнего все работает.
При выполнении установления соединения извне, порты не откликаются (к ним нельзя подключиться):
Вывести причину на экран можно при помощи ключа --reason

nmap -Pn 192.168.73.14 -p 5900 --reason

Причина №1. Некорректная маршрутизация

В моем случае подключение к домашней сети происходит через домашний VPN, и соединение успешное. Например, доступен роутер для управления.

Симптомы.
После подключеняи к домашней VPN, в домашней сети доступен маршрутизатор по адресу xxx.xxx.xxx.1, но ПК с адросом xxx.xxx.xxx.2 не отвечает на ping и не работают подключения к нему через SSH, VNC и RDP.

Диагностика

Вначале подключился к домашней сети, затем проверка подключния и маршрутизации

ping 192.168.1.2 # IP адрес целевого (удалённого) ПК

должен быть отклик

sudo traceroute 192.168.1.2 # IP-адрес целевого (удалённого) ПК

Путь должен быть очень коротким, всего из трех узлов, к примеру:

sudo traceroute 192.168.1.4
traceroute to 192.168.1.4 (192.168.1.4), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 22.207 ms 23.414 ms 23.587 ms
2 192.168.1.4 (192.168.1.4) 25.000 ms 24.978 ms 25.004 ms

Решение
На ПК, с которого инициируется подключение к VPN, нужно в параметрах VPN подключения указать маршрут через роутер в целевой локальной сети.
Например, если целевая сеть 192.168.1.0, роутер 192.168.1.1, а целевой ПК имеет IP адрес 192.168.1.2, нужно настроить маршрут с рабочего ПК на целевой 192.168.1.2 через шлюз 192.168.1.1. Это делается в настройках Network Manager - Параметры соединений - Параметры IPv4 - Маршруты...
ipv4-1
ipv4-2
Указал:

  • Адрес - IP адрес ПК в сети к которому подключемся по VNC / RDP / SSH. Например, 192.168.1.2
  • Маска подсети - 255.255.255.0
  • Шлюз - это IP адрес маршрутизатора в целевой сети. Например, 192.168.1.1
  • Метрика 1

Проверка командами ping и traceroute проходит, соединение к X11 через VNC и RDP тоже происходят.

Причина №2: Брандмауэр uwf запрещает подключения к ПК извне

Можно временно отключить брандмауэр домашнего ПК.

sudo service ufw stop

Команда удалит также правила файрволла, их восстановить нельзя. Перед удалением, запишите правила:

sudo ufw status numbered

Если было настроено множество правил, и есть жаление переустановить брандмауэр, его можно удалить при помощи apt uwf purge

sudo apt purge ufw
sudo apt install ufw

Причина №3: некорректная настройка iPTables

После удаления брандмауэра, все равно остаются правила в IPtables, что удивительно.

Чтобы просмотреть правиала IPtables, нужно ввести команду

sudo iptables -L

или

sudo iptables -L -n -v

Добавление разрешающих правил

sudo iptables -P INPUT ACCEPT
# sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Сброс всех правил

sudo iptables -F

Улаление всех цепочек

sudo iptables -X

Сброс счетчиков

sudo iptables -Z 

На ПК удаление правил NAT, mangle и RAW

sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -t raw -F
sudo iptables -t raw -X

Причина №4: включен NFTables

На сервере может быть установлен NFTables:

cat /etc/nftables.conf

Причина №5: не запущены сервисы XRDP или X11VNC

На сервере, к которому подключаюсь, из localhost нужно проверить порты, которые прослушивают службы:

sudo netstat -plnt

Порт 22 - SSHD
Порт 3389 - RDP
Порт 5900 - VNC

Должны быть в состоянии LISTEN. Если нет - проверка состояния соответствующих сервисов

sudo service sshd status
sudo service xrdp status
sudo service x11vnc status

Причина №6. Промежуточные хосты и фильтрация трафика

В случае, если на домашнем маршрутизаторе используется проброс портов, по пути любой маршрутизатор с включенным брандмауэром (firewall-ом) может фильтровать запросы или ответные пакеты к определённым портам. Решения: использовать на домашнем роутере нестандартные номера портов или более сильное решение - отправлять трафик в трубу.

Причина №7. Различные маршруты до разных хостов

Недоступность может быть связана с неправильным пониманием маршрутов.
По умолчанию

  • Весть трафик в публичную сеть Интернет проходит через рабочий роутер не заворачиваясь в тоннель. Маршрут 1.
  • Только трафик до домашней сети уходит в тоннель. Маршрут 2. И т.д.
  • также IP-адрес домашней сети может пересекаться с серым IP-адресом другого клиента провайдера. То есть ваш хост 192.168.73.1 может существовать в сети профайдера. Проверка - traceroute.

Настройкой роутера можно обеспечить заворачивание всего трафика в тоннель после подключения к домашней сети.
Для роутеров Zyxel есть команда консоли для изменения маршрутизации (можно найти в документации на сайте поддержки роутеров). Проверкой служит сервис 2ip.ru - при корректной настройке будет отображаться домашний IP адрес.


Примечание. Если запрещены ответы ICMP на домашнем сервере, их нужно разрешить:

sudo nano /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_all = 1
sysctl -p

Источник данного совета - страница Как заблокировать или разблокировать запросы ping на Ubuntu Server 20.04 LTS на сайте andreyex.ru.

На роутере нет необходимости запрещать ICMP ответы команды PING - по умолчанию ALLOW ICMP from LAN.

/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp