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

Ситуация: при подключении к домашней сети извне, невозможно подключиться к хосту (машине), состояние портов "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 - Маршруты...


Указал:

• Адрес - 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 запрещает подключения к ПК извне

Просмотр списка правил разрешений и запретов брандмауэра для входящих подключений (ALLOW IN, DENY IN):

sudo ufw status numbered

sudo ufw status numbered > ~/ufw_backup.txt

Можно временно отключить брандмауэр для проверки подключения без него:

sudo service ufw stop

Включить, если причина не в брандмауэре:

sudo ufw enable

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

sudo apt purge ufw

sudo apt install ufw

Затем восстанавливаем правила вручную на основе резервной копии списка правил ufw_backup.txt.
Например, для запрета подключения к MySQL:

sudo ufw deny 3306/tcp

и т.д..

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

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

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

sudo iptables -L

Более подробная информация о правилах:

sudo iptables -L -n -v

где
-L - list (вывести на экран список правил). Можно вызывать -L с обозначением цепочки правил, применяющихся к пакетам. Например: sudo iptables -L INPUT.
-n - numric (отображать номера ip-адресов и портов в цифровом формате)
-v - verbose (детальная информация)

Ручное добавление разрешающих правил:

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

Сброс всех правил IPTables для ветки INPUT

sudo iptables -F INPUT

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

sudo iptables -X

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

sudo iptables -Z 

Удаление из iptables правил 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

Установка правил iptables, ufw и gufw по умолчанию:

sudo apt purge iptables -y && sudo apt install iptables ufw gufw
sudo ufw enable

Проверка:

sudo iptables -L

Правила приведены в исходное состояние.

sudo ufw status numbered

Состояние: активен

Правил пользователя пока нет.
(Их можно добавить командами ufw, на основе резервной копии правил ufw_backup.txt, как написано выше).

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

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

cat /etc/nftables.conf

sudo service nftables status

По умолчанию правил 3 штуки (input, forward и output), у сервиса nftables должен быть статус inactive (dead).

Причина №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. Промежуточные хосты и фильтрация трафика

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

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

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

По умолчанию

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

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

Для маршрутизаторов Zyxel Keenetik есть документация на сайте поддержки роутеров Keenetik).

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

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

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

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

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

Источники:

• Документация по Iptables.
• Документация Keenetik

Дата последнего изменения: 22.04.2025