Dve zahtevi, ki se slišita enako, nista enaki: „izključi to aplikacijo iz VPN“ in „pošlji ta en sam cilj izven VPN za prenosnik na moji dostopni točki“. Prva spremeni, kako vtičnica v telefonu izbere omrežje. Druga mora spremeniti odločitev o posredovanju paketa, ki je prišel iz druge naprave, potem ko ga je telefon že sprejel. Zamenjevanje obeh je razlog, da odjemalec dostopne točke ostane z izjemo, ki je vedno veljala le za brskalnik samega telefona.

Dve vprašanji imata dva podsistema

Android drži omrežje aplikacij in tethering ločeno. Vtičnice aplikacij dodeli omrežju sklad povezljivosti, aplikacija VPN pa odloči, katere od njenih lastnih vtičnic vstopijo v tunel. Posredovane pakete povezanega odjemalca obdela podsistem za tethering, ki od netd zahteva poti, pravila politike in prevajanje na spodnjem vmesniku.

Izključitev po aplikacijah se oceni, ko aplikacija odpre vtičnico. Posredovani paket nikoli ne doseže tega preverjanja, ker ni nastal iz vtičnice aplikacije na tej napravi. To je ves razlog, da se dve nastavitvi ne moreta zamenjati, in to ni napaka v nobeni od njiju.

Kaj izključitev po aplikacijah v resnici spremeni

Graditelj VpnService lahko poimenuje pakete, ki ostanejo izven tunela, z addDisallowedApplication, ali poimenuje edine pakete, dovoljene znotraj, z addAllowedApplication. Te aplikacije nato odprejo vtičnice v osnovnem omrežju, medtem ko VPN še naprej poseduje privzeto pot za vse ostalo.

Obseg je natančen: lastne vtičnice paketa, na tej napravi, dokler je tunel dvignjen. Ne pove ničesar o posredovanem prometu, ničesar o drugi napravi in ničesar o paketih, ki jih sistem pošilja v imenu tetheringa.

Ni niti nadzor cilja. Izključitev brskalnika izključi vsak naslov, ki ga ta brskalnik doseže, vključno s tistim, ki si ga hotel obdržati v tunelu. Ko zahteva poimenuje cilj namesto aplikacije, je izbirnik aplikacij že po zgradbi napačno orodje.

Kako posredovani paket izgleda za telefon

Odjemalčev paket prispe na vmesnik dostopne točke z zasebnim naslovom vira, ki ga dodeli telefon, recimo 192.168.43.20, in javnim ciljem. Da bi ga posredoval, telefon potrebuje pot proti nadrejeni povezavi in pravilo prevajanja, da odgovori najdejo pot nazaj, ker zasebni naslov odjemalca v mobilnem omrežju nič ne pomeni.

Android to izrazi s pravili politike, ki izberejo usmerjevalno tabelo, netd pa ustrezne tabele in pravila znova zgradi, ko se omrežja in VPN spremenijo. Številka tabele, prioriteta pravila ali ime vmesnika, prepisani z objave na forumu ali iz istega modela v starejši izdaji, ne vzpostavijo trajnega lastništva. Ta ponovna gradnja je tudi razlog, da lahko ročno napisano pravilo deluje eno uro in se po naslednji ponovni povezavi ustavi.

Kakšno politiko izjema za dostopno točko v resnici potrebuje

Preden se dotaknete pravila, zapišite odločitev kot vir, cilj in predvideno pot. Najmanjša oblika za en odobren cilj je videti takole:

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

Obe smeri morata biti popolni. Neposredna veja potrebuje uporabno pot čez mobilno nadrejeno povezavo, ki je trenutno aktualna; veja VPN potrebuje pot tunela in dovoljenje za posredovanje. Vsak prevod vira se mora ujemati z izbranim izhodom, ker NAT, uporabljen na vmesniku tunela, prikaže naslov tunela in ne mobilnega, in takrat se povratna pot ne ujema s potjo navzven.

Odgovori morajo doseči istega spodnjega odjemalca prek sledenega stanja ali izrecne poti, števec odhodnih paketov pa od tega ničesar ne dokaže. Držite tudi lastni zunanji transport VPN izven obsega izjeme, sicer paketi nosilci tunela podedujejo politiko, napisano za spletno zahtevo odjemalca.

En zajet naslov ni cilj

En sam naslov IPv4, prebran iz brskalnika, je posnetek. Velike storitve odgovarjajo iz anycasta ali iz vrtljivega nabora robnih naslovov, mnoge so dvoskladne, pretok prijave pa se lahko dotakne gostiteljev preverjanja pristnosti in telemetrije, ki jih stran nikoli ne pokaže. Izjema, zgrajena okoli naslova, ki si ga slučajno videl, se ob naslednjem uravnavanju obremenitve zlomi.

Uporabite dokumentirane naslove lastnika storitve ali obseg, ki ga objavlja, in upoštevajte obe družini naslovov. Če zahteve ni mogoče izraziti kot stabilen nabor, je to verjetno vprašanje politike za storitev in ne trik usmerjanja na telefonu.

Preverite s spodnje strani

Tri preverbe v tem vrstnem redu: izbrana storitev s prenosnika, običajen cilj, ki mora ostati v VPN, in aplikacija v telefonu, ki mora ostati nedotaknjena. Nato ponovite po ponovni povezavi in po spremembi nadrejene povezave, ker se takrat tabele politike znova zgradijo.

Če izvedba souporabe v telefonu ne more obdržati te pogodbe skozi ponovno povezavo, premaknite selektivno politiko na podprt spodnji usmerjevalnik, namesto da kopičite pravila root na napravi. Usmerjevalnik lahko izrazi ujemanje vira in cilja s stabilnim lastnikom, in dokumentacija modula za tethering je prava referenca za to, kar telefon v resnici počne.

Sorodni članki