Роздільне тунелювання за застосунком або за призначенням: що вибрати

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

Два правила діють на різних рівнях

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

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

Правила застосунків підходять для мобільних клієнтів і керованих агентів

Android показує вибір безпосередньо: VpnService.Builder.addAllowedApplication() і addDisallowedApplication() приймають імена пакетів і застосовують рішення для кожного UID, як описано в посібнику розробника VPN для Android. У iOS є відповідник через правила VPN для окремих застосунків на основі ідентифікаторів пакетів, які зазвичай доставляються профілем MDM, а не набираються вручну.

Настільні клієнти це слабке місце. Більшість клієнтів VPN для Windows і macOS маршрутизують за призначенням і взагалі не пропонують вибір за процесом, бо драйвер тунелю бачить пакети, а не процеси. Якщо ваш план залежить від тунелювання одного застосунку на ноутбуці, перевірте реальні можливості клієнта, перш ніж будувати навколо цього; можливо, ви вибираєте між списком призначень і другою машиною.

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

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

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

OpenVPN доходить до того ж місця через просунуту таблицю маршрутів. route-nopull не дає серверу диктувати маршрути, після чого клієнтський route 10.20.0.0 255.255.0.0 vpn_gateway покриває рівно офісний префікс. IPv6 це окреме твердження в кожному з цих клієнтів, і забути його це найпоширеніший спосіб витоку навколо правильно виглядаючого розділення IPv4.

Ім'я вузла це не маршрут. Якщо профіль пропонує поле домену, ставтеся до нього як до імені, яке клієнт розв'язує один раз, а не як до постійного діапазону адрес; мережі доставки вмісту та балансувальники навантаження завтра видадуть інші адреси.

Де ламаються обидві моделі: помічники, спільні служби, розв'язувачі

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

Правила призначення ламаються на спільних службах і на іменах. Файлові ресурси, принтери, внутрішній DNS і сервер ліцензій живуть на адресах, тому тунель одного застосунку дає браузеру доступ, а підключений диск лишається мертвим. Ця різниця покриття не є помилкою жодної з моделей, але саме вона робить тунель одного застосунку таким частим джерелом ситуації, коли VPN працює, а спільний ресурс зник.

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

Порядок дій: вибрати, застосувати, перевірити

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

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

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Перші два рядки називають інтерфейс, який використав би справжній пункт призначення; wg show друкує налаштований список префіксів; у Windows Find-NetRoute відповідає на те саме питання, на яке відповість стек під час надсилання пакета. Якщо інтерфейс це тунель, правило збіглося.

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