Поделениот тунел за клиенти на пристапна точка не е исклучување по апликации
Исклучувањето на апликација од 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 правила на апаратот. Рутерот може да изрази совпаѓање на извор и одредиште со стабилен сопственик, а документацијата на модулот за тетеринг е вистинската референца за тоа што телефонот навистина прави.