Delt tunnelering for hotspot-klientar er ikkje utelukking per app
Å utelukke ein app frå VPN endrar berre telefonen. Den tilkopla berebne maskinen treng si eiga vidaresendingsregel, tilpassa på kjelde, mål og NAT.
To krav som høyrest like ut er ikkje like: «utelukk denne appen frå VPN» og «send dette eine målet utanfor VPN for den berebne maskinen på hotspoten min». Det første endrar korleis ein socket på telefonen vel nettverk. Det andre må endre ei vidaresendingsavgjerd for ein pakke som kom frå ein annan eining etter at telefonen alt har godteke han. Å blande dei to er korleis ein hotspot-klient endar med eit unntak som alltid berre gjaldt nettlesaren til telefonen sjølv.
To delsystem eig dei to spørsmåla
Android held appnettverk og tethering frå kvarandre. Appsocketar blir tildelte eit nettverk av tilkoplingsstakken, og ein VPN-app avgjer kva av sine eigne socketar som går inn i tunnelen. Vidaresende pakkar frå ein tilkopla klient blir handsama av tethering-delsystemet, som ber netd om ruter, policynreglar og omsetjing på nedstraumsgrensesnittet.
Utelukking per app blir vurdert når ein app opnar ein socket. Ein vidaresend pakke når aldri den kontrollen, fordi han ikkje oppstod frå ein appsocket på denne eininga. Det er heile grunnen til at dei to innstillingane ikkje kan erstatte kvarandre, og det er ikkje ein feil i nokon av dei.
Kva utelukking per app faktisk endrar
Ein VpnService-byggjar kan namngje pakkane som blir utanfor tunnelen med addDisallowedApplication, eller namngje dei einaste pakkane som er tillatne innanfor med addAllowedApplication. Desse appane opnar då socketar på det underliggande nettverket medan VPN framleis eig standardruta for alt anna.
Omfanget er presist: dei eigne socketane til pakken, på denne eininga, så lenge tunnelen er oppe. Det seier ingenting om vidaresend trafikk, ingenting om ei anna eining og ingenting om pakkar systemet sender på vegner av tethering.
Det er heller ikkje målkontroll. Å utelukke ein nettlesar utelukkar kvar adresse den nettlesaren når, inkludert den du ville halde inne i tunnelen. Når kravet nemner eit mål i staden for ein app, er appveljaren feil verktøy av konstruksjon.
Korleis ein tethert pakke ser ut for telefonen
Pakken til klienten kjem til hotspot-grensesnittet med ei privat kjeldeadresse tildelt av telefonen, seie 192.168.43.20, og eit offentleg mål. For å vidaresende han treng telefonen ei rute mot ei oppstraumslenkje og ein omsetjingsregel slik at svar finn vegen tilbake, fordi den private adressa til klienten er meiningslaus på mobilnettet.
Android uttrykkjer det med policynreglar som vel ei rutetabell, og netd byggjer dei relevante tabellane og reglane på nytt når nettverk og VPN-ar blir endra. Eit tabellnummer, ein regelprioritet eller eit grensesnittnamn kopiert frå eit foruminnlegg, eller frå same modell på ei eldre utgåve, etablerer ikkje varig eigarskap. Denne ombygginga er også grunnen til at ein handskriven regel kan verke i ein time og stoppe etter neste attkoping.
Kva policy eit hotspot-unntak faktisk treng
Skriv avgjerda som kjelde, mål og tiltenkt veg før du rører ein regel. Minsteform for eitt godkjent mål ser slik ut:
| 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 |
Begge retningane må vere komplette. Den direkte greina treng ei brukbar rute gjennom mobiloppstraumslenkja som tilfeldigvis er gjeldande; VPN-greina treng tunnelruta pluss løyve til å vidaresende. Ei kvar kjeldeomsetjing må samsvare med utgangen du valde, fordi NAT brukt på eit tunnelgrensesnitt viser tunneladressa og ikkje mobiladressa, og returvegen stemmer då ikkje med den utgåande vegen.
Svar må nå same nedstraumsklient gjennom spora tilstand eller ei eksplisitt rute, og ein teljar for utgåande pakkar beviser ingenting av det. Hald også den eigne ytre transporten til VPN utanfor omfanget av unntaket, elles arvar berarpakkane til tunnelen ein policy skriven for ein nettførespurnad frå ein klient.
Éi fanga adresse er ikkje eit mål
Éi einskild IPv4-adresse lesen frå ein nettlesar er eit augneblinksbilete. Store tenester svarar frå anycast eller frå eit roterande sett kantadresser, mange er dobbeltstakka, og ein innloggingsflyt kan røre godkjennings- og telemetriverter som sida aldri viser. Eit unntak bygd rundt adressa du tilfeldigvis såg, blir brote neste gong tenesta rebalanserer.
Bruk dei dokumenterte adressene til tenesteeigaren, eller eit område han publiserer, og rekn med båe adressefamiliane. Dersom kravet ikkje kan uttrykkjast som eit stabilt sett, er det truleg eit policyspørsmål for tenesta og ikkje eit rutetriks på ein telefon.
Stadfest frå nedstraumssida
Tre kontrollar, i denne rekkjefølgja: den valde tenesta frå den berebne maskinen, eit vanleg mål som må bli inne i VPN, og ein telefonapp som må vere upåverka. Gjenta deretter etter ei attkoping og etter ei endring av oppstraumslenkja, for det er då policytabellane blir bygde på nytt.
Dersom delingsimplementasjonen til telefonen ikkje kan halde den kontrakten gjennom ei attkoping, flytt den selektive policyen til ein støtta nedstraumsruter i staden for å samle root-reglar på handsettet. Ein ruter kan uttrykkje kjelde- og målmatcing med ein stabil eigar, og dokumentasjonen for tethering-modulen er den rette referansen for kva telefonen faktisk gjer.