нет доступа к локальной сети за VPN-туннелем

[forsir]

Здравствуйте, уважаемые коллеги.

Столкнулся с непробиваемой стеной, в виде непрохождения пакетов с одного интерфейса сервера на другой. Имеется Ubuntu сервер. Интерфейс tun0 – 10.8.0.42, интерфейс wlp2s0 – 192.168.2.53. На интерфейс tun0 приходят пакеты, адресованные для внутренней локальной сети 192.168.2.x. Но никуда дальше они не идут. tcpdump видит пакеты на tun0:

Код: [Выделить]

tcpdump -i tun0 port 80 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
15:31:03.104115 IP 192.168.1.174.41594 > 192.168.2.34.80: Flags [S], seq 1604979728, win 64240, options [mss 1357,sackOK,TS val 1132044967 ecr 0,nop,wscale 7], length 0
15:31:04.140811 IP 192.168.1.174.41594 > 192.168.2.34.80: Flags [S], seq 1604979728, win 64240, options [mss 1357,sackOK,TS val 1132046004 ecr 0,nop,wscale 7], length 0
15:31:05.166272 IP 192.168.1.174.41594 > 192.168.2.34.80: Flags [S], seq 1604979728, win 64240, options [mss 1357,sackOK,TS val 1132047027 ecr 0,nop,wscale 7], length 0

Но на wlp2s0 по 80-у порту полная тишина.

Таблица маршрутизации на сервере. Маршрут на сеть 192.168.2.x организован посредством OpenVPN.

(Нажмите, чтобы показать/скрыть)

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    600    0        0 wlp2s0
10.8.0.0        10.8.0.41       255.255.255.0   UG    0      0        0 tun0
10.8.0.41       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     10.8.0.41       255.255.255.0   UG    0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
192.168.2.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

Настройки iptables.

(Нажмите, чтобы показать/скрыть)

/proc/sys/net/ip4/ip_forward — «1»
iptables -A FORWARD -i wlp2s0 -o tun0
iptables -A FORWARD -i tun0 -o wlp2s0

Прошу помочь с направлением к заданной цели – достучаться из VPN-туннеля до клиентов внутри локальной сети.

[ALiEN]

Маскарадинг забыли.

[forsir]

    Здравствуйте.
    Благодаря уважаемому ALiENу вопрос был решён, как я думал, на всю оставшуюся. 4 разнесённые локальные сети имели доступ друг к другу во всех направлениях. Но споткнулись на обновлении операционок  . Что как-то, само по себе, удивительно.
    Остановлюсь немного поподробнее, как было.
    4 локальные сети, объединенные посредством OpenVPN. В каждом сегменте, в качестве шлюзов, стоят линуксовые машины.

Код: [Выделить]

сеть шлюз
1-я 192.168.1.x Ubuntu сервер 22.04.5
2-я 192.168.2.x Ubuntu сервер 22.04.5
3-я 192.168.8.x Debian 12
4-я 192.168.11.x         Ubuntu сервер 22.04.5 (здесь стоит OpenVPN сервер)

    Любой клиент любой сети имел доступ к любому клиенту любой сети, при наличии соответствующих расшаренных ресурсов или серверов.
    Но вот на днях на 2-м и 4-м шлюзах обновили операционки до Ubuntu сервер 24.04.1. При обновлениях /proc/sys/net/ip4/ip_forward упали в «0». Но это быстро исправили в «1».
    После обновлений имеем то, что 2-я сеть (192.168.2.x) оказалась почти отрезанной от остальных сетей. Выход из 2-й остался только на 1-ю сеть (192.168.1.x). Больше из 2-й сети никуда не попасть! То есть 1-я, 3-я и 4-я сети функционируют между собой штатно. Ко 2-й сети доступа из 3-й и 4-й сети нет (возможность выхода из 1-й сети на 2-ю сейчас не проверить).
    В данном конкретном случае под обменом информацией между сетями я подразумеваю удалённое управление принтерами через веб-интерфейс. Иногда и настройку удалённых маршрутизаторов.
    И напоследок самое неожиданное. Обмен информацией между 2-й сетью и остальными сетями отсутствует (ну или почти отсутствует), а пинги между всеми сетями, включая 2-ю, проходят исправно во все стороны! Таким образом имеем весьма странную ситуацию: пинги есть, а обмена информацией нет.
    Прошу помощи советом, в какую сторону копать для исправления ситуации?

[ALiEN]

Обмен информацией между 2-й сетью и остальными сетями отсутствует

Что значит "обмен информацией"?
В VPN-сетях broadcast/mdns/llmnr как правило, отсутствует.
Если вы ожидали, что там само всё автоматом найдётся - то увы, нет. 

[forsir]

Что значит "обмен информацией"?

При помощи браузера захожу на веб интерфейсы принтеров, стоящие во всех сегментах сети. Аналогично, посредством веб интерфейса, либо специальной клиентской программой, обращаюсь к видеокамерам, передающим потоковое видео по протоколу rtsp.

В VPN-сетях broadcast/mdns/llmnr как правило, отсутствует.

DNS не используется ни в каком виде! И к принтерам, и к камерам обращение только по их локальным IP. Подчеркну, что до обновления операционных систем на двух серверах всё работало, как надо. А сейчас один сегмент "отвалился". Но пинги, при том, что "обмена информацией нет", проходят между всеми устройствами нормально  .

[forsir]

После долгих мучений решение было найдено! Пишу для тех, кто столкнётся с подобным, или просто интересно. Дело оказалось исключительно в OpenVPN и исключительно на Ubuntu 24.04.1 (напомню, что 2-й сегмент оказался отрезанным от остальных после обновления с 22.04.5 до 24.04.1).
Используя ping с ключём -s был определён максимальный размер пакета, который передаётся без искажений в удалённый сегмент.

(Нажмите, чтобы показать/скрыть)

ping -s 1376 192.168.11.109
PING 192.168.11.109 (192.168.11.109) 1376(1404) bytes of data.
1384 bytes from 192.168.11.109: icmp_seq=3 ttl=126 time=33.5 ms
1384 bytes from 192.168.11.109: icmp_seq=4 ttl=126 time=38.5 ms
1384 bytes from 192.168.11.109: icmp_seq=7 ttl=126 time=43.8 ms
1384 bytes from 192.168.11.109: icmp_seq=8 ttl=126 time=35.0 ms
^C
--- 192.168.11.109 ping statistics ---
10 packets transmitted, 4 received, 60% packet loss, time 9113ms
rtt min/avg/max/mdev = 33.482/37.680/43.790/3.969 ms

Этим значением оказалось 1375. бОльшие значения приводили к потерям пакетов, или полному непрохождению. Как я понял, это параметр MTU, или какой-то другой, который с MTU тесно связан. В OpenVPN существует параметр mssfix, который связан с MTU. На каком-то заграничном форуме рекомендовали начинать со значения MTU-40. Какбы то ни было, при mssfix равном 1432 и ниже, все мои сегменты локалок ожили! При значении 1433 связь 2-го сегмента с остальными пропадала.

Таким образом, чтобы вернуть отрезанный от остальных 2-й сегмент, оказалось достаточно было добавить в на шлюзе 2-го сегмента в client.conf одну строчку:

Код: [Выделить]

mssfix 1432

Всем удачи!