Клиент OpenVPN достигает сервера, но не узлов LAN: контрольный список

Клиент сообщает, что подключён, адрес туннеля отвечает на ping, а в офисной сети LAN ничего не откликается. Я вижу это почти после каждого обновления клиента, и первый порыв — открыть межсетевой экран, что обычно неверный шаг: туннель в порядке, а разрыв находится на одном из трёх переходов, которые пакет должен пройти. Пройдите путь в том порядке, в котором идёт пакет: сначала маршрут клиента, затем пересылка на сервере, затем обратный путь, и вы найдёте виновника неисправности за пару минут.

Первый шаг: наблюдайте за решением маршрутизации клиента

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

ip route get 192.168.50.10

Если в ответе назван ваш физический адаптер и офисный шлюз, никакое изменение на стороне сервера не поможет. OpenVPN раздаёт маршруты только когда сервер их продвигает, поэтому ищите push "route 192.168.50.0 255.255.255.0" в конфигурации сервера и после этого переподключите клиент. Большинство клиентов применяют продвинутые маршруты при подключении, а не при перезагрузке профиля.

В Windows у того же вопроса другая команда. Find-NetRoute -RemoteIPAddress 192.168.50.10 выводит интерфейс и следующий переход, который выбрал бы стек, а route print -4 показывает, существует ли продвинутый префикс вообще.

Второй шаг: убедитесь, что сервер будет пересылать пакет

Если маршрут клиента верен, пакет доходит до сервера, и сервер должен согласиться его пересылать. Переключатель ядра — это первые ворота, и sysctl net.ipv4.ip_forward должен вернуть 1. Установка через echo 1 > /proc/sys/net/ipv4/ip_forward работает до следующей перезагрузки, и именно поэтому та же жалоба возвращается недели спустя.

Запишите это туда, где переживёт перезагрузку:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Вторые ворота — таблица фильтров. Узел с установленным Docker часто имеет политику FORWARD со значением DROP, и туннель наследует это решение. iptables -L FORWARD -v -n показывает и политику, и счётчики пакетов; если политика DROP, пересылке нужно явное разрешение для направления из туннеля в LAN и ещё одно для ответа.

Третий шаг: проследите пакет до LAN и ищите ответ

Наблюдайте за обеими сторонами сервера одновременно. Перехватывайте на туннеле и на интерфейсе LAN, с фильтром на одного клиента и один узел, чтобы вывод оставался читаемым:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Запросы, которые появляются на tun0 и снова на eth0 с источником 10.8.0.x, после чего наступает тишина, означают, что пакет пришёл, а ответ ушёл куда-то ещё. Узел LAN отвечает своему шлюзу по умолчанию, у этого шлюза нет маршрута в пул VPN, и ответ умирает на маршрутизаторе LAN. Пинговать узел LAN с сервера ничего не доказывает об этом пути, потому что этот трафик никогда не пересекает туннель.

Четвёртый шаг: выберите между трансляцией и обратным маршрутом

Два исправления закрывают дыру, и у выбора есть последствия помимо того, работает ли ping. Трансляция источника делает сервер кажущимся отправителем:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ограничьте правило пулом и интерфейсом LAN, затем сделайте его постоянным, иначе следующая перезагрузка межсетевого экрана тихо удалит ваше исправление. Цена — идентичность: каждый клиент выглядит как сервер VPN в журналах LAN и правилах доступа, и per-client policy becomes guesswork.

Статический маршрут для 10.8.0.0/24 на маршрутизаторе LAN, указывающий на сервер VPN, сохраняет адреса клиентов видимыми и является лучшим долгосрочным ответом, когда этот маршрутизатор ваш. Многие площадки какое-то время держат оба решения: NAT для немедленного исправления и маршрут, как только написана политика межсетевого экрана. Если сервер — это партнёр «сайт-сайт», а не пул, стороне сервера также нужен iroute для удалённой подсети, иначе маршрут партнёра существует, но трафик клиентов никогда с ним не связывается.

Пятый шаг: проверьте со стороны клиента и запишите, что изменилось

Замыкайте цикл со стороны клиента, а не сервера. Подключитесь к реальному сервису на узле LAN, затем подтвердите, что счётчики трансляции сдвинулись с помощью iptables -t nat -L POSTROUTING -v -n, потому что правило без пакетов — это правило, которое никогда не совпадало. conntrack -L -s 10.8.0.5 показывает поток и его состояние, когда нужно доказательство, что обратное направление отслеживается.

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