Як надіслати одне призначення IPv4 поза тунелем OpenVPN

Більшість конфігурацій повного тунелю надсилають кожен пакет через VPN, і саме директива redirect-gateway робить це можливим. Одне окреме призначення все ж можна виключити. Додавання маршруту до хоста для цієї адреси із заповнювачем net_gateway каже клієнту досягати її через початковий шлюз машини, а все інше продовжує використовувати тунель.

Рядок виглядає безпечно і часто таким є, але він вирішує лише одне питання: куди йдуть пакети для саме цієї адреси IPv4. Він не змінює DNS, IPv6, політику брандмауера чи те, який процес відкрив з'єднання, і кожне з цього може тихо звести виняток нанівець.

Що насправді називає net_gateway

Запис профілю для цього винятку — один рядок: route 198.51.100.77 255.255.255.255 net_gateway. Перша адреса — документаційний заповнювач для призначення, маска робить його маршрутом до одного хоста, а останній токен називає заповнювач шлюзу. OpenVPN розв'язує заповнювачі шлюзів, коли встановлює маршрути. vpn_gateway означає власний шлюз тунелю, дальший бік з'єднання VPN. net_gateway означає шлюз за замовчуванням, який хост мав до того, як VPN щось змінив, зазвичай це локальний маршрутизатор у фізичній мережі.

Третій заповнювач, remote_host, стосується адреси сервера VPN, і він існує, щоб тунель міг досягти сервера фізичним шляхом. Плутанина між цими трьома — найпоширеніша причина, чому виняток потрапляє не туди або взагалі не встановлюється.

Значення читається в момент підключення, а не записується у файл. Якщо машина переміщується в іншу мережу, шлюз до VPN змінюється, і маршрут іде за новим. Зазвичай це те, що потрібно, але це також означає, що поведінка винятку залежить від мережі, з якої клієнт стартував.

Чому маршрут до хоста перемагає маршрут тунелю за замовчуванням

Маршрутизацію визначає найконкретніший відповідний префікс. redirect-gateway def1 зазвичай не замінює маршрут за замовчуванням; він додає дві половини, маршрут для нижньої половини адресного простору і один для верхньої, тож початковий маршрут за замовчуванням зберігається для інших потреб. Ці половини ширші за одну адресу.

Маршрут до однієї адреси з маскою 255.255.255.255 — це /32, тобто максимальна конкретність, яку дає IPv4. Коли оцінюється пакет для цієї адреси, /32 збігається і перемагає незалежно від того, який маршрут було встановлено першим. Це і є механізм винятку, і він працює однаково в Linux, macOS і Windows, поки маршрут справді наявний.

Windows додає другий вимір. Коли два маршрути однаково конкретні, перемагає той із нижчою метрикою, а VPN-адаптер може мати метрику інтерфейсу, яка змінює результат. /32 усе ще конкретніший за половини, тож виняток зазвичай зберігається, але застарілий маршрут із попереднього сеансу може дати заплутаний результат, якщо він так само конкретний.

Чого виняток не покриває

DNS — перша прогалина. Клієнт може просунути внутрішні налаштування резолвера, і операційна система продовжить використовувати їх для запитів. Застосунок, що розв'язує ім'я перед підключенням, може отримати внутрішню адресу для служби, яка має йти напряму, або зовнішню адресу, яка розв'язується правильно, але потім спотикається об наступну прогалину.

IPv6 — друга. Директива маршруту працює лише з IPv4. Призначення з подвійним стеком може віддати перевагу IPv6, який залежно від політики йде через тунель або через маршрут IPv6 за замовчуванням хоста, тож виняток IPv4 ніколи не набуває чинності. Потрібен відповідний маршрут IPv6 або свідоме рішення вимкнути IPv6 для цього клієнта.

Обсяг застосунків — третій. Правило базується на призначенні, тож кожен процес, що підключається до цієї адреси, використовує прямий шлях, чи це той процес, який ви мали на увазі, чи ні. І навпаки, сайт може відповідати з кількох адрес, тож виключення однієї /32 не виключає сайт. Якщо справжня вимога — маршрутизація за застосунками, таблиця маршрутів клієнта Community — неправильний інструмент.

Перевірка винятку без самообману

Почніть зі встановленого маршруту, а не з браузера. У Linux запитайте ядро, який маршрут і наступний стрибок воно використає для конкретної адреси; у Windows прочитайте таблицю маршрутів для цієї /32. Переконайтеся, що шлюз фізичний, а не тунель. Якщо запису немає, профіль не застосовано або клієнт не мав права змінювати маршрути.

Потім перевірте два призначення. Запит до виключеної адреси має вийти через фізичний інтерфейс, а запит до внутрішньої контрольної адреси має все ще використовувати тунель. Перевірка лише виключеної адреси нічого не доводить про решту тунелю, а перевірка публічного сайту перевіряє адресу, на яку розв'язався цей сайт, і вона може не бути адресою з правила.

Нарешті перевірте засоби, які можуть перекрити маршрут. Kill switch на боці клієнта або налаштування Windows block-outside-dns може заборонити прямий трафік, і це виявляється як з'єднання, що не працює, хоча маршрут правильний. Не вимикайте ці засоби, щоб виняток виглядав працюючим; якщо політика забороняє прямий шлях, виняток — проблема дизайну для власника служби VPN.

Перевірте знову після повторного підключення або зміни мережі, бо шлюз до VPN і доступний шлях — це властивості моменту, а не профілю.