Utestengt app fortsatt på nettet? Regler per app og for ruter er ulike

Å utestenge en pakke er en ruteinstruks, ikke en blokkering, så sidene som lastes etter at VPN-en kobles til, er forventet og ikke bevis på en feil. Utestengingen fjerner appen fra tunnelen i stedet for å blokkere den, og det vanlige nettet bærer trafikken. To separate policyer møtes her: den ene velger prosesser, den andre velger destinasjoner. Å lese dem i den rekkefølgen forklarer hvorfor et tilkoblet ikon og en fungerende app ikke er en motsetning.

Hvorfor en utestenging holder nettet åpent

VpnService.Builder godtar enten en tillatelsesliste eller en blokkeringsliste, aldri begge. Pakker på en tillatelsesliste er de eneste som rutes gjennom tunnelen. En blokkeringsliste snur det: hver pakke unntatt de oppførte bruker tunnelen, og de oppførte beholder den fysiske veien. En pakke som ikke er oppført, er under en tillatelsesliste også utenfor tunnelen, så utestenging er normaltilstanden for de fleste apper i den modusen.

Det gjør en lokal blokkeringspost til en rutebeslutning, ikke en brannmurregel. Hvis kravet er å hindre en app i å nå en vert, må tunnelen dekke den, og serveren eller en lokal policy må avvise trafikken. Å fjerne en app fra tunnelen endrer bare hvilket grensesnitt som bærer pakkene dens.

Play Store-tilfellet er det vanlige bevisste eksempelet. Å utestenge butikkpakken lar nedlastinger bruke den underliggende forbindelsen når VPN-utgangen forstyrrer overføringer, og det viser at utestenging betyr omgåelse, ikke blokkering.

Én profil, én liste

Byggeren kaster en feil hvis begge kallene brukes, så profilen foran deg er enten en tillatelses- eller en blokkeringsliste. Den ene kjensgjerningen avgjør hvordan hver senere observasjon skal leses. Sjekk koden eller den administrerte konfigurasjonen før rutetabellen, fordi listen avgjør hva resten av utdataene betyr. En hybrid profil er ikke en tilstand du kan se på.

Forskjellen forutsier også hva en nylig installert app vil gjøre. Under en tillatelsesliste blir den utenfor til noen legger den til, mens den under en blokkeringsliste blir med i tunnelen som standard.

Administrerte konfigurasjoner viser det samme valget under forskjellige nøkkelnavn, og noen konsoller beskriver det som per-app VPN-modus i stedet for som en liste. Atferden reduseres likevel til de to kallene, så spor innstillingen tilbake til pakkelisten i stedet for å stole på etiketten. Hvis etiketten og listen er uenige, vinner listen.

Følg UID-regelen til tunnelens tabell

Android gir hver app sin egen Linux-bruker-ID, og VPN-tjenesten installerer policyregler som samsvarer med UID-intervaller. Sammensvarende trafikk sendes til en rutetabell der standardruten peker på tun-enheten. Tabellnummeret tildeles per VPN-instans, så det endres etter en gjentilkobling eller etter at en andre VPN-profil er opprettet.

Regelutdataene er kartet. Hver linje navngir en oppslagstabell, og den tabellen holder standardruten som avgjør om samsvarende pakker kommer inn i tunnelen.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Kjør den tredje kommandoen først for å få UID-en, og finn deretter regelen hvis intervall inneholder den. Den regelen peker på et tabellnummer, og ip route show table <n> med det nummeret viser om det finnes en standardrute gjennom tun-enheten. Hvis tabellen ikke har en standardrute, er appen valgt, men har ingen vei, noe som er en annen feil.

Disse kommandoene krever et bygg som kan feilsøkes, eller en enhet der adb shell kan lese nettverkstilstanden. På en produksjonshåndsett svarer pakkebehandleren fortsatt, men ruteinspeksjonen kan bli avvist, så registrer det du kan, og behandle resten som ubekreftet.

En rute krever et prefiks, ikke en app

Builder.addRoute krever destinasjonsprefikser for tunnelen. En profil som bare legger til 10.0.0.0/8 sender det prefikset gjennom tunnelen og lar hver annen destinasjon bli på den fysiske veien. Det er vanlig delt tunnellering, og det er uavhengig av hvilke apper reglene valgte.

Server-pushet konfigurasjon speiler den samme modellen. Individuelle rutepush legger til prefikser, mens en redirect-gateway-direktiv erstatter standardruten og fanger alt for appene tunnelen dekker. Å fjerne det direktivet kan krympe en fungerende tunnel til ett enkelt subnett uten noen endring på enheten.

En pushet rute med en uvanlig gateway eller metrisk kvalifikator kan også mislykkes i å installeres. Foretrekk den enkle prefiksformen og la serveren håndtere videresending og NAT.

Les snittet før du endrer en innstilling

Tunnelen bærer snittet av de dekkede prosessene og de krevde destinasjonene. En dekket app som ber om en adresse utenfor de publiserte prefiksene, forlater via det fysiske nettet. En blokkert pakke blir utenfor selv når den ber om en adresse innenfor disse prefiksene. Ingen av tilfellene er en feil; begge er de to policyene som gjør jobben sin.

En per-app VPN kan også etterlate en tilknyttet app uten tilkobling. Når on-demand er av og tunnelen er nede, forblir appen bundet til per-app VPN-en og har ingen reserve, noe som ser ut som en ødelagt app snarere enn en policytilstand. Å slå på on-demand eller fjerne tilknytningen via administrasjon endrer det.

Diagnostiser én akse om gangen. Bekreft tillatelse eller blokkering først, les de installerte UID-reglene og tabellene som nummer to, og test en annen app mot den samme destinasjonen til slutt. Den andre appen skiller prosessvalg fra destinasjonsvalg i én enkelt forespørsel.

Skriv ned resultatet som app, destinasjon og tabellnummer. Den tuppelen er det den neste endringen må bevare.