Opdelt tunneling til hotspotklienter er ikke udelukkelse pr. app

To krav, der lyder ens, er ikke ens: »udeluk denne app fra VPN« og »send denne ene destination uden om VPN til den bærbare computer på mit hotspot«. Det første ændrer, hvordan en socket på telefonen vælger et netværk. Det andet skal ændre en videresendelsesbeslutning for en pakke, der kom fra en anden enhed, efter at telefonen allerede har accepteret den. At forveksle de to er, hvordan en hotspotklient ender med en undtagelse, der altid kun gjaldt telefonens egen browser.

To delsystemer ejer de to spørgsmål

Android holder appnetværk og tethering adskilt. Applikationssockets tildeles et netværk af forbindelsesstakken, og en VPN-app afgør, hvilke af dens egne sockets der kommer ind i tunnelen. Videresendte pakker fra en tilsluttet klient håndteres af tethering-delsystemet, som beder netd om ruter, politikregler og oversættelse på downstream-grænsefladen.

Udelukkelsen af en enkelt app vurderes, når en app åbner en socket. En videresendt pakke når aldrig den kontrol, fordi den ikke stammer fra en appsocket på denne enhed. Det er hele grunden til, at de to indstillinger ikke kan erstatte hinanden, og det er ikke en fejl i nogen af dem.

Hvad appudelukkelse faktisk ændrer

En VpnService-builder kan navngive pakker, der bliver uden for tunnelen, med addDisallowedApplication, eller navngive de eneste pakker, der er tilladt indenfor, med addAllowedApplication. Disse apps åbner derefter sockets på det underliggende netværk, mens VPN’en fortsat ejer standardruten for alt andet.

Omfanget er præcist: pakkens egne sockets, på denne enhed, så længe tunnelen er oppe. Det siger intet om videresendt trafik, intet om en anden enhed og intet om pakker, som systemet sender på vegne af tethering.

Det er heller ikke en destinationskontrol. At udelukke en browser udelukker hver adresse, som browseren når, inklusive den, du ville holde inde i tunnelen. Når kravet nævner en destination frem for en app, er appvælgeren det forkerte værktøj af konstruktion.

Sådan ser en tether’et pakke ud for telefonen

Klientens pakke ankommer på hotspot-grænsefladen med en privat kildeadresse tildelt af telefonen, for eksempel 192.168.43.20, og en offentlig destination. For at videresende den har telefonen brug for en rute mod et uplink og en oversættelsesregel, så svar kan finde vej tilbage, fordi klientens private adresse er meningsløs på mobilnettet.

Android udtrykker det med politikregler, der vælger en routingtabel, og netd genopbygger de relevante tabeller og regler, når netværk og VPN’er ændrer sig. Et tabelnummer, en regelprioritet eller et grænsefladenavn kopieret fra et forumindlæg eller fra samme model på en ældre udgivelse skaber ikke varigt ejerskab. Den genopbygning er også grunden til, at en håndskrevet regel kan virke en time og stoppe efter den næste genforbindelse.

Den politik en hotspotundtagelse faktisk har brug for

Skriv beslutningen som kilde, destination og tilsigtet vej, før du rører ved en regel. Den mindste form for én godkendt destination ser sådan ud:

Begge retninger skal være komplette. Den direkte gren har brug for en brugbar rute gennem det mobil-uplink, der tilfældigvis er aktuelt; VPN-grenen har brug for tunnelruten plus tilladelse til at videresende. Enhver kildeoversættelse skal matche det udgangspunkt, du valgte, fordi NAT anvendt på en tunnelgrænseflade viser tunneladressen og ikke mobiladressen, og returvejen stemmer så ikke med den udgående vej.

Svar skal nå den samme downstream-klient gennem sporet tilstand eller en eksplicit rute, og en tæller for udgående pakker beviser intet af det. Hold også VPN’ens egen ydre transport uden for undtagelsens omfang, ellers arver tunnelens bærerpakker en politik skrevet til en klients webforespørgsel.

Én fanget adresse er ikke en destination

En enkelt IPv4-adresse læst fra en browser er et øjebliksbillede. Store tjenester svarer fra anycast eller fra et roterende sæt kantadresser, mange er dobbeltstakkede, og et loginforløb kan røre godkendelses- og telemetriværter, som siden aldrig viser. En undtagelse bygget omkring den adresse, du tilfældigvis så, bryder sammen næste gang, tjenesten rebalancerer.

Brug tjenestens ejers dokumenterede adresser eller et interval, den offentliggør, og regn med begge adressefamilier. Hvis kravet ikke kan udtrykkes som et stabilt sæt, er det sandsynligvis et politikspørgsmål for tjenesten snarere end et routingtrick på en telefon.

Verificér fra downstream-siden

Tre kontroller, i denne rækkefølge: den valgte tjeneste fra den bærbare computer, en almindelig destination, der skal blive inde i VPN’en, og en telefonapp, der skal være upåvirket. Gentag derefter efter en genforbindelse og efter en ændring af uplink, for det er da, politiktabellerne genopbygges.

Hvis telefonens delingsimplementering ikke kan holde den kontrakt gennem en genforbindelse, flyt den selektive politik til en understøttet downstream-router i stedet for at samle root-regler på håndsættet. En router kan udtrykke kilde- og destinationsmatchning med en stabil ejer, og dokumentationen for tethering-modulet er den rigtige reference for, hvad telefonen faktisk gør.