Дайте хостам 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 падає, тож застарілий наступний стрибок може перетворити цей префікс на чорну діру задовго після зникнення тунелю.