Подељено тунеловање за клијенте приступне тачке није искључивање по апликацијама
Искључивање апликације из VPN-а мења само телефон. Повезани преносни рачунар треба сопствено правило прослеђивања, усклађено по извору, одредишту и NAT-у.
Два захтева која звуче исто нису иста: „искључи ову апликацију из VPN-а“ и „пошаљи ово једно одредиште изван VPN-а за преносни рачунар на мојој приступној тачки“. Први мења како гнездо на телефону бира мрежу. Други мора да промени одлуку о прослеђивању за пакет који је стигао са другог уређаја након што га је телефон већ прихватио. Мешање тога двоје је начин на који клијент приступне тачке заврши са изузетком који се одувек односио само на прегледач самог телефона.
Два подсистема поседују два питања
Android држи мрежу апликација и tethering одвојено. Гнезда апликација додељује мрежи стек повезивања, а VPN апликација одлучује која њена сопствена гнезда улазе у тунел. Прослеђене пакете са повезаног клијента обрађује подсистем за tethering, који од netd-а тражи руте, правила политике и превођење на доњем интерфејсу.
Искључивање по апликацији се процењује када апликација отвори гнездо. Прослеђени пакет никада не стиже до те провере, јер није настао из гнезда апликације на овом уређају. То је цео разлог зашто те две поставке не могу да замене једна другу, и то није грешка ни у једној од њих.
Шта искључивање по апликацији заиста мења
Градитељ VpnService-а може да именује пакете који остају изван тунела помоћу addDisallowedApplication, или да именује једине пакете дозвољене унутра помоћу addAllowedApplication. Те апликације затим отварају гнезда на основној мрежи, док VPN и даље поседује подразумевану руту за све остало.
Обухват је прецизан: сопствена гнезда пакета, на овом уређају, док је тунел подигнут. Не говори ништа о прослеђеном саобраћају, ништа о другом уређају и ништа о пакетима које систем шаље у име tethering-а.
То није ни контрола одредишта. Искључивање прегледача искључује сваку адресу до које тај прегледач стигне, укључујући ону коју сте хтели да задржите у тунелу. Када захтев именује одредиште, а не апликацију, бирач апликација је погрешан алат већ по самој конструкцији.
Како прослеђени пакет изгледа телефону
Пакет клијента долази на интерфејс приступне тачке са приватним изворним адресом који је доделио телефон, рецимо 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-а или из ротирајућег скупа ивичних адреса, многе су двостеке, а ток пријаве може да дотакне host-ове за аутентификацију и телеметрију које страница никада не приказује. Изузетак изграђен око адресе коју сте случајно видели ломи се следећи пут када услуга прерасподели оптерећење.
Користите документоване адресе власника услуге или опсег који он објављује и узмите у обзир обе фамилије адреса. Ако захтев не може да се изрази као стабилан скуп, то је вероватно питање политике за услугу, а не трик усмеравања на телефону.
Проверите са доње стране
Три провере, овим редом: изабрана услуга са преносног рачунара, уобичајено одредиште које мора да остане у VPN-у и апликација телефона која мора да остане нетакнута. Затим поновите после поновног повезивања и после промене горње везе, јер се тада таблице политике поново граде.
Ако имплементација дељења на телефону не може да одржи тај уговор кроз поновно повезивање, преместите селективну политику на подржани доњи рутер уместо да гомилате root правила на апарату. Рутер може да изрази подударање извора и одредишта са стабилним власником, а документација модула за tethering је права референца за то шта телефон заиста ради.