Роздільне тунелювання для клієнтів хотспота — не виняток за застосунком
Виключення застосунку з VPN змінює лише телефон. Підключеному ноутбуку потрібне власне правило пересилання, узгоджене за джерелом, призначенням і NAT.
Дві вимоги, які звучать однаково, — не одне й те саме: «виключи цей застосунок із VPN» і «надішли це єдине призначення поза VPN для ноутбука на моїй точці доступу». Перша змінює те, як сокет на телефоні вибирає мережу. Друга має змінити рішення про пересилання для пакета, що надійшов з іншого пристрою після того, як телефон його вже прийняв. Плутанина між цими двома і призводить до того, що в клієнта хотспота залишається виняток, який завжди стосувався лише браузера самого телефона.
Двома питаннями володіють дві підсистеми
Android тримає мережевий доступ застосунків і тетеринг окремо. Сокети застосунків закріплює за мережею стек зв'язності, а VPN-застосунок вирішує, які з його власних сокетів потраплять у тунель. Переслані пакети від підключеного клієнта обробляє підсистема тетерингу, яка запитує в netd маршрути, правила політики й трансляцію на нижчому інтерфейсі.
Виняток за застосунком оцінюється, коли застосунок відкриває сокет. Пересланий пакет ніколи не доходить до цієї перевірки, бо він виник не із сокета застосунку на цьому пристрої. Саме тому дві настройки не можуть заміняти одна одну, і це не дефект у жодній із них.
Що насправді змінює виняток за застосунком
Конструктор VpnService може назвати пакети, що залишаються поза тунелем, за допомогою addDisallowedApplication, або назвати єдині дозволені всередині пакети за допомогою addAllowedApplication. Ці застосунки тоді відкривають сокети в базовій мережі, а VPN далі володіє маршрутом за замовчуванням для всього іншого.
Обсяг точний: власні сокети пакета, на цьому пристрої, доки тунель піднятий. Він нічого не каже про пересланий трафік, нічого про другий пристрій і нічого про пакети, які система надсилає від імені тетерингу.
Це й не керування призначенням. Виключення браузера виключає кожну адресу, до якої цей браузер доходить, включно з тією, яку ви хотіли залишити в тунелі. Коли вимога називає призначення, а не застосунок, засіб вибору застосунків за самою конструкцією є неправильним інструментом.
Як пересланий пакет виглядає для телефона
Пакет клієнта надходить на інтерфейс хотспота з приватною адресою джерела, призначеною телефоном, скажімо 192.168.43.20, і публічним призначенням. Щоб переслати його, телефону потрібен маршрут до вищого каналу й правило трансляції, аби відповіді знайшли зворотний шлях, бо приватна адреса клієнта в стільниковій мережі нічого не означає.
Android виражає це правилами політики, які вибирають таблицю маршрутизації, а netd перебудовує відповідні таблиці й правила, коли мережі та VPN змінюються. Номер таблиці, пріоритет правила або назва інтерфейсу, скопійовані з повідомлення на форумі чи з тієї самої моделі в старішому випуску, не створюють тривалого володіння. Ця перебудова — ще й причина того, що написане вручну правило може працювати годину й зупинитися після наступного перепідключення.
Яка політика насправді потрібна винятку для хотспота
Перш ніж торкатися правила, запишіть рішення як джерело, призначення й передбачуваний шлях. Мінімальна форма для одного схваленого призначення виглядає так:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Обидва напрямки мають бути повними. Пряма гілка потребує придатного маршруту через стільниковий вищий канал, який випадково є поточним; гілка VPN потребує маршруту тунелю плюс дозволу пересилати. Будь-яка трансляція джерела має відповідати вибраному виходу, бо NAT, застосований на інтерфейсі тунелю, показує адресу тунелю, а не стільникову, і тоді зворотний шлях не узгоджується зі шляхом назовні.
Відповіді мають доходити до того самого нижчого клієнта через відстежуваний стан або явний маршрут, а лічильник вихідних пакетів нічого з цього не доводить. Тримайте й власний зовнішній транспорт VPN поза межами винятку, інакше пакети-носії тунелю успадкують політику, написану для вебзапиту клієнта.
Одна перехоплена адреса — не призначення
Одна адреса IPv4, прочитана з браузера, — це миттєвий знімок. Великі сервіси відповідають з anycast або з обертового набору граничних адрес, багато з них двостекові, а процес входу може торкнутися хостів автентифікації й телеметрії, які сторінка ніколи не показує. Виняток, побудований навколо адреси, яку ви випадково побачили, ламається наступного разу, коли сервіс перерозподіляє навантаження.
Використовуйте задокументовані адреси власника сервісу або діапазон, який він публікує, і враховуйте обидві родини адрес. Якщо вимогу не можна виразити як стабільний набір, це, найімовірніше, питання політики для сервісу, а не трюк маршрутизації на телефоні.
Перевірте з нижчого боку
Три перевірки в цьому порядку: вибраний сервіс з ноутбука, звичайне призначення, яке має залишитися всередині VPN, і застосунок телефона, який має залишитися незачепленим. Потім повторіть після перепідключення й після зміни вищого каналу, бо саме тоді таблиці політики перебудовуються.
Якщо реалізація спільного доступу на телефоні не може втримати цей контракт через перепідключення, перенесіть вибіркову політику на підтримуваний нижчий маршрутизатор, а не накопичуйте root-правила на апараті. Маршрутизатор може виразити збіг джерела й призначення зі стабільним власником, а документація модуля тетерингу — це правильна довідка про те, що телефон насправді робить.