Як розділений тунель вирішує, який трафік використовує VPN

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

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

Клієнт встановлює правила, ядро робить вибір

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

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

Той самий вибір існує на кожній платформі, хоч назви змінюються. Windows вштовхує рішення у свою платформу фільтрів, Android оприлюднює список дозволених застосунків через свою службу VPN, а macOS прив'язує тунель до пристрою, який досі підкоряється таблиці маршрутизації. Нотатки Microsoft про маршрутизацію варті прочитання для випадку Windows, а посібник, написаний для однієї платформи, рідко переноситься без змін на іншу.

Прив'язка до застосунку й префікси призначення — різні інструменти

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

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

DNS і аварійний перемикач дотримуються власних правил

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

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

Перевірте розділення з обох боків

Перевірте включений шлях і виключений шлях окремо й оцінюйте результат за назвою інтерфейсу, а не за публічною адресою. Ці команди припускають хост Linux із уже піднятим тунельним пристроєм. Замініть 203.0.113.10 на призначення, яке ваша політика скеровує всередину, а 198.51.100.25 — на те, яке вона відправляє назовні.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

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

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