Wireguard vpn и проблема подключения к отдельным портам в локальной сети за сервером vpn

[R0cky]

Исходные данные:

Сервер Wireguard vpn поднят на "взрослой" платформе x86 под управлением Debian. К нему в качестве клиентов с разных мест подключаются клиентами два роутера Keenetic Hopper. Оба на крайней стабильной прошивке. На обоих установлена entware на внутреннюю память. Настроена маршрутизация, доступ для обоих клиентов в локальную сеть за сервером Wireguard (вида 192.168.1.0/24) есть. На ип адресе 192.168.1.44 (который присвоен в локальной сети той же машине, на которой поднят сервер Wireguard) крутятся также socks tor (порт 9050) и торрент клиент transmission-daemon (порт 9091). Кроме того на 22 порту есть доступ к серверу по ssh.

Теперь о проблеме: с самого начала почему-то для обоих клиентов (кинетиков) при обращении к адресу 192.168.1.44 были не доступны вышеозначенные порты 9050 и 9091, но при этом например доступ по ssh (порт 22) работал прекрасно. Также прекрасно доступны ресурсы samba, поднятые на том же адресе  192.168.1.44.

Теперь самое странное - через какое то время на одном из роутеров кинетик доступ к этим портам и ресурсам появился. Какие либо целенаправленные настройки того роутера я не производил, точно их воспроизвести к сожалению не могу. На втором роутере доступ именно к портам  9050 и 9091, открытых на адресе 192.168.1.44, по прежнему отсутствует.

Выглядит это так:

На проблемном кинетике:

# nmap 192.168.1.44 -p 9050
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:03 +05
Nmap scan report for 192.168.1.44
Host is up (0.068s latency).

PORT     STATE    SERVICE
9050/tcp filtered tor-socks

Nmap done: 1 IP address (1 host up) scanned in 1.81 seconds
~ # nmap 192.168.1.44 -p 9091
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:03 +05
Nmap scan report for 192.168.1.44
Host is up (0.089s latency).

PORT     STATE    SERVICE
9091/tcp filtered xmltec-xmlmail

Nmap done: 1 IP address (1 host up) scanned in 1.98 seconds
~ # nmap 192.168.1.44 -p 22
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:04 +05
Nmap scan report for 192.168.1.44
Host is up (0.10s latency).

PORT   STATE SERVICE
22/tcp open  ssh

На другом кинетике, где проблема исчезла по неясной причине:

~ # nmap 192.168.1.44 -p 9050
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:05 +05
Nmap scan report for 192.168.1.44
Host is up (0.028s latency).

PORT     STATE SERVICE
9050/tcp open  tor-socks

Nmap done: 1 IP address (1 host up) scanned in 1.13 seconds
~ # nmap 192.168.1.44 -p 9091
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:06 +05
Nmap scan report for 192.168.1.44
Host is up (0.028s latency).

PORT     STATE SERVICE
9091/tcp open  xmltec-xmlmail

Nmap done: 1 IP address (1 host up) scanned in 1.07 seconds
~ # nmap 192.168.1.44 -p 22
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 10:06 +05
Nmap scan report for 192.168.1.44
Host is up (0.028s latency).

PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 1.10 seconds

Обратите внимание, что статус портов 9050 и 9091 на проблемном киентике не closed, а именно filtered ! Но кто или что их фильтрует никак не могу понять!

Прошу помощи коллектива, заранее благодарен!

 

 

Изменено 10 июля, 2022 пользователем R0cky

[R0cky]

Попробовал с проблемного роутера настроить впн подключение до debian-сервера по протоколу openvpn - порты доступны. Похоже какая то проблема с реализацией в прошивке именно wireguard протокола...

[Monstr86]

Я бы проверил iptables на debian сервере, может там что то не так.

[R0cky]

5 часов назад, Monstr86 сказал:

Я бы проверил iptables на debian сервере, может там что то не так.

Настройки сети на сервере проверены много раз. Очень вряд ли, что проблема на стороне сервера хотя бы потому, что оба кинетика подключаются к одному и тому же впн, то есть находятся в одной подсети 10.8.3.0/24. Все правила и разрешения iptables в том числе межсетевого трафика на сервере debian настроены по подсетям. Соответственно, если бы проблема была бы в сервере, то она присутствовала бы на обоих клиентах - кинетиках.

Может у техподдержки или у кого то из участников форума есть возможность воспроизвести аналогичную задачу и отписаться по наличию проблемы?

Изменено 12 июля, 2022 пользователем R0cky

[R0cky]

Запустил tcpdump на сервере Debian, вот вывод:

Скрытый текст

tcpdump -nn -i wg0 host 192.168.1.44 and port 9091
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
20:27:56.007133 IP 10.8.3.3.49194 > 192.168.1.44.9091: Flags [S], seq 3700018748, win 1024, options [mss 1460], length 0
20:27:56.007153 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
20:27:56.783259 IP 10.8.3.3.49195 > 192.168.1.44.9091: Flags [S], seq 3699953213, win 1024, options [mss 1460], length 0
20:27:56.783278 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
20:27:57.021341 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
20:27:57.789339 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
20:27:59.039340 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
20:27:59.807308 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
20:28:03.133309 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
20:28:03.903303 IP 192.168.1.44.9091 > 10.8.3.3.49195: Flags [S.], seq 2932892427, ack 3699953214, win 64240, options [mss 1460], length 0
20:28:11.197341 IP 192.168.1.44.9091 > 10.8.3.3.49194: Flags [S.], seq 516608816, ack 3700018749, win 64240, options [mss 1460], length 0
20:28:11.796617 IP 10.8.3.2.52953 > 192.168.1.44.9091: Flags [S], seq 1042555351, win 1024, options [mss 1460], length 0
20:28:11.796636 IP 192.168.1.44.9091 > 10.8.3.2.52953: Flags [S.], seq 2625312514, ack 1042555352, win 64240, options [mss 1460], length 0
20:28:11.831303 IP 10.8.3.2.52953 > 192.168.1.44.9091: Flags [R], seq 1042555352, win 0, length 0

10.8.3.2 это адрес кинетика, на котором нет проблем с доступом к портам 9091 и 9050

10.8.3.3 - проблемный в этом плане кинетик.

Видно, что есть инициация коннекта с 10.8.3.3, затем идут ответные пакеты с адреса 192.168.1.44:9091 на адрес 10.8.3.3, но последний более не отвечает

 

Вывод tcpdump на беспроблемном кинетике:

Скрытый текст

tcpdump -nn -i nwg1 host 192.168.1.44 and port 9091
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nwg1, link-type RAW (Raw IP), capture size 262144 bytes
22:33:12.124993 IP 10.8.3.2.61155 > 192.168.1.44.9091: Flags [S], seq 3722118243, win 1024, options [mss 1460], length 0
22:33:12.152607 IP 192.168.1.44.9091 > 10.8.3.2.61155: Flags [S.], seq 1372688115, ack 3722118244, win 64240, options [mss 1460], length 0
22:33:12.152844 IP 10.8.3.2.61155 > 192.168.1.44.9091: Flags [R], seq 3722118244, win 0, length 0

Видно, что пакеты ходят, а вот так картина выглядит на проблемном:

Скрытый текст

 tcpdump -nn -i nwg0 host 192.168.1.44 and port 9091
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on nwg0, link-type RAW (Raw IP), capture size 262144 bytes
22:39:24.810961 IP 10.8.3.3.54628 > 192.168.1.44.9091: Flags [S], seq 1695354802, win 1024, options [mss 1460], length 0
22:39:25.338232 IP 10.8.3.3.54629 > 192.168.1.44.9091: Flags [S], seq 1695289267, win 1024, options [mss 1460], length 0

Исходящие запросы идут, а в ответ полная тишина. Отсюда делаю вывод, что стоит какой то фильтр на кинетике. Как его отключить? техподдержка, ау?

 

Изменено 16 июля, 2022 пользователем R0cky

[R0cky]

Вроде разобрался. Проблема судя по всему была в том, что в силу некоторых настроек на Debian сервере исходящие пакеты от висящих на нем сервисов tor и transmission-daemon шли с некорректной чексуммой. А на кинетике видимо по умолчанию такие пакеты отбрасываются. Кое-что поправил на серваке, пакеты в цепочке output от сервисов tor и transmission-daemon пошли с корректной чексуммой и сразу все заработало.

Внимание вопрос к техподдержке: как отключить на кинетике фильтрацию пакетов с неправильной чексуммой? ИМХО это бредовая настройка, поскольку чексумма может сломаться по очень многим причинам и само по себе это не значит, что пакет носит злонамеренный характер.