Разделеното тунелиране за клиенти на точка за достъп не е изключване по приложения
Изключването на приложение от 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 правила на апарата. Маршрутизаторът може да изрази съпоставяне по източник и дестинация със стабилен собственик, а документацията за модула за тетъринг е правилната справка за това какво всъщност прави телефонът.