Delt tunnelering for hotspot-klienter er ikke utelukkelse per app

To krav som høres like ut er ikke like: «utelukk denne appen fra VPN» og «send dette ene målet utenfor VPN for den bærbare maskinen på hotspoten min». Det første endrer hvordan en socket på telefonen velger nettverk. Det andre må endre en videresendingsbeslutning for en pakke som kom fra en annen enhet etter at telefonen allerede har godtatt den. Å blande de to er hvordan en hotspot-klient ender med et unntak som alltid bare gjaldt telefonens egen nettleser.

To delsystemer eier de to spørsmålene

Android holder appnettverk og tethering fra hverandre. Appsockets tildeles et nettverk av tilkoblingsstakken, og en VPN-app avgjør hvilke av dens egne sockets som går inn i tunnelen. Videresendte pakker fra en tilkoblet klient håndteres av tethering-delsystemet, som ber netd om ruter, policyregler og oversettelse på nedstrømsgrensesnittet.

Utelukkelse per app vurderes når en app åpner en socket. En videresendt pakke når aldri den kontrollen, fordi den ikke oppsto fra en appsocket på denne enheten. Det er hele grunnen til at de to innstillingene ikke kan erstatte hverandre, og det er ikke en feil i noen av dem.

Hva utelukkelse per app faktisk endrer

En VpnService-bygger kan navngi pakkene som blir utenfor tunnelen med addDisallowedApplication, eller navngi de eneste pakkene som er tillatt innenfor med addAllowedApplication. Disse appene åpner da sockets på det underliggende nettverket mens VPN fortsatt eier standardruten for alt annet.

Omfanget er presist: pakkens egne sockets, på denne enheten, så lenge tunnelen er oppe. Det sier ingenting om videresendt trafikk, ingenting om en annen enhet og ingenting om pakker systemet sender på vegne av tethering.

Det er heller ikke målkontroll. Å utelukke en nettleser utelukker hver adresse den nettleseren når, inkludert den du ville holde inne i tunnelen. Når kravet nevner et mål i stedet for en app, er appvelgeren feil verktøy av konstruksjon.

Hvordan en tethert pakke ser ut for telefonen

Klientens pakke ankommer hotspot-grensesnittet med en privat kildeadresse tildelt av telefonen, si 192.168.43.20, og et offentlig mål. For å videresende den trenger telefonen en rute mot en oppstrømskobling og en oversettelsesregel slik at svar finner veien tilbake, fordi klientens private adresse er meningsløs på mobilnettet.

Android uttrykker det med policyregler som velger en rutetabell, og netd bygger de relevante tabellene og reglene på nytt når nettverk og VPN-er endres. Et tabellnummer, en regelprioritet eller et grensesnittnavn kopiert fra et foruminnlegg, eller fra samme modell på en eldre utgivelse, etablerer ikke varig eierskap. Denne gjenoppbyggingen er også grunnen til at en håndskrevet regel kan virke i en time og stoppe etter neste gjentilkobling.

Hvilken policy et hotspot-unntak faktisk trenger

Skriv beslutningen som kilde, mål og tiltenkt vei før du rører en regel. Minsteform for ett godkjent mål ser slik ut:

Begge retninger må være komplette. Den direkte grenen trenger en brukbar rute gjennom mobiloppstrømskoblingen som tilfeldigvis er gjeldende; VPN-grenen trenger tunnelruten pluss tillatelse til å videresende. Enhver kildeoversettelse må samsvare med utgangen du valgte, fordi NAT brukt på et tunnelgrensesnitt viser tunneladressen og ikke mobiladressen, og returveien stemmer da ikke med den utgående veien.

Svar må nå samme nedstrømsklient gjennom sporet tilstand eller en eksplisitt rute, og en teller for utgående pakker beviser ingenting av det. Hold også VPN-ens egen ytre transport utenfor unntakets omfang, ellers arver tunnelens bærerpakker en policy skrevet for en klients nettforespørsel.

Én fanget adresse er ikke et mål

Én enkelt IPv4-adresse lest fra en nettleser er et øyeblikksbilde. Store tjenester svarer fra anycast eller fra et roterende sett kantadresser, mange er dobbeltstakket, og en innloggingsflyt kan berøre godkjennings- og telemetriverter som siden aldri viser. Et unntak bygget rundt adressen du tilfeldigvis så, brytes neste gang tjenesten rebalanserer.

Bruk tjenesteeierens dokumenterte adresser, eller et område den publiserer, og regn med begge adressefamiliene. Hvis kravet ikke kan uttrykkes som et stabilt sett, er det sannsynligvis et policyspørsmål for tjenesten og ikke et rutetriks på en telefon.

Verifiser fra nedstrømssiden

Tre kontroller, i denne rekkefølgen: den valgte tjenesten fra den bærbare maskinen, et vanlig mål som må bli inne i VPN, og en telefonapp som må være upåvirket. Gjenta deretter etter en gjentilkobling og etter en endring av oppstrømskobling, for det er da policytabellene bygges på nytt.

Hvis telefonens delingsimplementasjon ikke kan holde den kontrakten gjennom en gjentilkobling, flytt den selektive policyen til en støttet nedstrømsruter i stedet for å samle root-regler på håndsettet. En ruter kan uttrykke kilde- og målmatcing med en stabil eier, og dokumentasjonen for tethering-modulen er den riktige referansen for hva telefonen faktisk gjør.