Як пропустити через VPN лише одну приватну підмережу

Виберіть між маршрутом на клієнті, маршрутом, який надсилає сервер, і узгодженими селекторами, а потім проведіть одну приватну підмережу без повного тунелю.

Одна приватна підмережа через тунель, а все інше звичайним шляхом це невелике прохання з дуже багатьма способами зробити його неправильно. Результат визначає не прапорець з назвою split tunneling, а те, де рішення застосовується: у власній таблиці маршрутів клієнта, у маршруті, який надсилає сервер, або в політиці, про яку домовляються два кінці. Виберіть неправильний рівень і отримаєте або повний тунель, якого ви ніколи не хотіли, або маршрут у тунель, який інша сторона відмовляється приймати. Перед відкриттям будь-якої конфігурації я застосовую перевірку з трьох умов, а потім вибираю один із механізмів нижче.

Три умови, які визначають схему

По-перше, вам потрібен точний префікс і маска від власника мережі. Мережа 10.x не є префіксом; 10.20.0.0/16 є. Переконайтеся, що вона не перетинається з вашою домашньою LAN, мостом Docker або іншим VPN, який ви запускаєте, бо перетин робить маршрут неоднозначним і ядро вибирає запис, який ви не мали на увазі.

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

По-третє, точка застосування. Деякі клієнти встановлюють маршрут, а решту робить операційна система. Інші узгоджують політику, і політика, яку шлюз не приймає, не створює тунелю взагалі: пакети відкидаються без явної помилки. Визначте, який із двох випадків ваш, перш ніж щось писати.

WireGuard: AllowedIPs це таблиця маршрутів

На клієнті AllowedIPs перелічує призначення, яким дозволено входити в тунель, а wg-quick перетворює кожен запис на звичайний маршрут. Отже клієнтська половина цього завдання це один рядок.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Тепер порівняйте запис сервера для того самого клієнта. Він описує, що сервер надішле клієнту, а це зазвичай адреса тунелю клієнта, а не приватна підмережа.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

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

Якщо ви керуєте маршрутами самі, задайте Table = off під [Interface] і додайте потрібний маршрут. Тоді нічого не додається автоматично, тому маршрут належить тому, що піднімає інтерфейс.

OpenVPN: надішліть маршрут, а потім переконайтеся, що він дійшов

На звичайному сервері зміна це одна директива в конфігурації сервера, поруч із пулом клієнтів.

push "route 10.20.0.0 255.255.0.0"

Клієнт додає його при підключенні. Режим відмови проявляється, коли той самий профіль надсилає ще й redirect-gateway, або коли хтось уже додав route-nopull: перше перетворює сеанс на повний тунель, а друге відкидає кожен надісланий маршрут, включно з вашим.

Клієнту, якому потрібна вузька поведінка щодо сервера з повним тунелем, слід ігнорувати лише ті частини, яких він не хоче. У OpenVPN 2.4 і новіших для цього існує pull-filter.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

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

Коли приватна підмережа не на сервері VPN, а за іншим клієнтом, сервер треба повідомити. Додайте файл для кожного клієнта через client-config-dir, що містить iroute 10.20.0.0 255.255.0.0, плюс відповідний route, щоб інші клієнти вивчили шлях. Без iroute сервер не має причини надсилати цей префікс саме тим тунелем.

IPsec: селектори трафіку мають збігатися

У IPsec немає маршруту, який треба надіслати. Два кінці домовляються, які адреси живуть усередині тунелю, а трафік поза узгодженими селекторами не шифрується і не йде через нього. На клієнті strongSwan селектори задані явно.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Якщо шлюз налаштований з 0.0.0.0/0 з обох боків, звуження IKEv2 зазвичай зводить дочірній SA до перетину двох пропозицій, що і є бажаним результатом. Деякі шлюзи натомість відхиляють пропозицію, яка не відповідає їхнім налаштованим селекторам, і журнал тоді показує невдалий дочірній SA, а не скаргу на маршрутизацію. Коли це стається, зміна належить шлюзу, бо маршрут на клієнті не може створити тунель для селектора, який інша сторона не прийме.

У Windows вбудований клієнт ховає те саме рішення за двома параметрами. Розділення тунелю має бути ввімкнене, а префікс має бути зареєстрований у профілі.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

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

Тримайте кінцеву точку й DNS поза рішенням

Кінцева точка VPN має залишатися доступною без тунелю, інакше тунель обвалюється сам у себе. Коли маршрутизується лише 10.20.0.0/16, це відбувається автоматично, оскільки кінцева точка це публічна адреса. У профілі повного тунелю це не так, і клієнту потрібен явний маршрут до хоста кінцевої точки, перш ніж підніметься тунель.

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

Перевірте, потім перезавантажтеся і перевірте знову

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Перший рядок називає інтерфейс. Якщо він називає ваш фізичний інтерфейс, маршрут так і не став. У Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 відповідає на те саме питання, а остання перевірка має й далі показувати вашу звичайну адресу, а не адресу сервера VPN.

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

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

Схожі статті