Выдайте хостам LAN обратный маршрут к VPN через опцию 121 DHCP

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

Сначала назовите три адреса

Возьмите конкретную LAN: 192.168.50.0/24 с обычным маршрутизатором по умолчанию на 192.168.50.1 и отдельным VPN-шлюзом на 192.168.50.2. Прошедшие аутентификацию удалённые клиенты занимают 10.90.0.0/24.

Маршрут, нужный каждому участвующему хосту, — 10.90.0.0/24 via 192.168.50.2. Назначение — пул клиентов, а следующий переход — LAN-адрес шлюза, а не его адрес в туннеле.

Закодируйте его как бесклассовый статический маршрут

Опция 121 переносит пары префикса и следующего перехода, а RFC 3442 определяет и кодирование, и вытекающее из него поведение клиента. Для существующего экземпляра dnsmasq, обслуживающего только эту иллюстративную LAN, форма конфигурации такова:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

Не потеряйте маршрут по умолчанию

Вот и ловушка. Клиент, получивший опцию 121, обязан игнорировать обычную опцию Router, поэтому объявление только маршрута пула VPN может оставить этот хост вообще без маршрута по умолчанию. Машина по-прежнему выглядит настроенной и тихо теряет интернет. Пользователи описывают это как упавшую сеть, хотя все интерфейсы подняты.

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

Проверьте, что примет клиент

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

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

Проверьте аренду, затем поиск

Попросите владельца DHCP применить изменение, затем продлите аренду на клиенте. Существующие аренды сохраняют старую конфигурацию до продления, поэтому мгновенный результат не гарантирован.

На клиенте Linux прочитайте фактические маршруты и подтвердите обе записи:

ip -4 route
ip -4 route get 10.90.0.23

Контекстный поиск должен показать маршрут пула через 192.168.50.2 и маршрут по умолчанию через 192.168.50.1. Если маршрута по умолчанию нет, вы воспроизвели ловушку выше.

Затем проверьте реальный обмен

Раздача маршрутов — не весь путь. Отдельному шлюзу по-прежнему нужны пересылка, владение удалёнными партнёрами и политика доступа, разрешающая сервер, а DHCP никого не аутентифицирует.

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