VPN-клиенты доходят до сервера, но не до LAN: какое решение?

Клиент пингует адрес туннеля OpenVPN-сервера и получает ответ, затем пробует хост в LAN сервера и не получает ничего. Это разделение сильно сужает неисправность: туннель поднят, пересылка, вероятно, работает, а ответ уходит через дверь, которая не ведёт назад. Есть три решения, и правильное зависит от того, что вы контролируете и от чего готовы отказаться. Ответьте на три вопроса ниже по порядку, и выбор перестанет быть делом вкуса.

Сначала определите, какое направление сломано

Запрос приходит на интерфейс туннеля с адресом источника из пула VPN. Сервер пересылает его хосту в LAN, и этот хост отвечает шлюзу, который называет его собственная таблица, обычно маршрутизатору LAN. Если у маршрутизатора нет маршрута к пулу, ответ там умирает или блуждает в сторону интернета.

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Если хост в LAN уже указывает на VPN-сервер, ваша проблема — правило фаервола или ограничение MTU, а не отсутствующий обратный путь. Не добавляйте маршрут, чтобы исправить фильтр.

Вопрос первый: можете ли вы редактировать маршрутизатор удалённой LAN?

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

Он тихо отказывает в тот день, когда кто-то изменит пул. Запишите значение один раз и считайте изменение в любом из трёх мест изменением во всех трёх.

NAS или коммутатор уровня Layer 3, который хостит службу, нуждается в том же маршруте, если он не отправляет всё через маршрутизатор, у которого он есть. Проверьте устройство, которое завершает подсеть, а не только то, что смотрит в интернет. Небольшие сети часто имеют три устройства с мнением о маршрутизации.

Вопрос второй: может ли LAN перестать видеть адреса клиентов?

Когда маршрутизатор принадлежит кому-то другому, трансляция на VPN-сервере не требует сотрудничества. Хост в LAN видит адрес LAN сервера, отвечает ему, а сервер транслирует обратно. Поэтому устройства и роли удалённого доступа на базе NAT ведут себя именно так.

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

Цена — это атрибуция: адреса на клиента исчезают из журналов LAN. Любой список разрешённых на хосте в LAN тогда должен называть сервер вместо пула.

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

Вопрос третий: сам сервер не является ли клиентом другого туннеля?

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

Решение — маскировать и исходящий туннель, чтобы провайдер видел только адрес туннеля сервера. Обратному направлению нужно собственное правило, потому что сервер, начинающий соединение к своему клиенту, — это другой поток. Без этого правила клиент отвечает на адрес, который не может маршрутизировать. Поставьте узкое правило перед любым широким маскированием, чтобы победила конкретная трансляция.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Хосты с несколькими интерфейсами добавляют родственную неисправность, которая со стороны клиента выглядит одинаково. Ответ уходит через интерфейс с меньшей метрикой, потому что адрес источника выбран из другой таблицы. Проверьте обратный путь поиском, а не предполагайте, что путь вперёд его подразумевает.

Затем проверьте оба направления и оба размера

После изменения пингуйте от клиента к хосту в LAN, а затем от хоста в LAN к клиенту. Второе направление — то, которое люди пропускают, и именно оно выявляет неполное правило трансляции. Запишите оба результата с отметкой времени, чтобы более поздняя регрессия была сравнимой.

Затем переместите реальные данные, потому что маленький пинг, который проходит, пока большая передача стоит, — это симптом MTU. Эта неисправность появляется сразу после того, как вы поздравили себя с исправленным маршрутом.

Наконец проверьте снова после перезагрузки. Команды маршрутов и фаервола во время работы её не переживают, и исправление, которое исчезает при следующем запуске, снова диагностирует кто-то с меньшим контекстом. Сделайте изменение постоянным так, как ваша система уже делает, и затем один раз намеренно перезагрузитесь.