Udelukket app stadig online? Regler per app og for ruter er forskellige

At udelukke en pakke er en ruterinstruks, ikke en blokering, så de sider, der indlæses efter VPN-forbindelsen, er forventede og ikke bevis på en fejl. Udelukkelsen fjerner appen fra tunnelen i stedet for at blokere den, og det almindelige netværk bærer dens trafik. To separate politikker mødes her: den ene vælger processer, den anden vælger destinationer. At læse dem i den rækkefølge forklarer, hvorfor et tilsluttet ikon og en fungerende app ikke er en modsætning.

Hvorfor en udelukkelse holder netværket åbent

VpnService.Builder accepterer enten en tilladelsesliste eller en blokeringsliste, aldrig begge. Pakker på en tilladelsesliste er de eneste, der sendes gennem tunnelen. En blokeringsliste vender det om: hver pakke undtagen de listede bruger tunnelen, og de listede beholder den fysiske vej. En pakke, der ikke er listet, er under en tilladelsesliste også uden for tunnelen, så udelukkelse er den normale tilstand for de fleste apps i den tilstand.

Det gør en lokal blokeringspost til en ruterbeslutning, ikke en firewallregel. Hvis kravet er at forhindre en app i at nå en vært, skal tunnelen dække den, og serveren eller en lokal politik skal afvise trafikken. At fjerne en app fra tunnelen ændrer kun, hvilken grænseflade der bærer dens pakker.

Play Store-tilfældet er det sædvanlige bevidste eksempel. At udelukke butikkens pakke lader downloads bruge den underliggende forbindelse, når VPN-udgangen forstyrrer overførsler, og det viser, at udelukkelse betyder omgåelse, ikke blokering.

Én profil, én liste

Byggeren kaster en fejl, hvis begge kald bruges, så profilen foran dig er enten en tilladelses- eller en blokeringsliste. Den ene kendsgerning afgør, hvordan hver senere observation skal læses. Kontroller koden eller den administrerede konfiguration før rutertabellen, fordi listen afgør, hvad resten af outputtet betyder. En hybrid profil er ikke en tilstand, du kan kigge på.

Forskellen forudsiger også, hvad en nyligt installeret app vil gøre. Under en tilladelsesliste forbliver den udenfor, indtil nogen tilføjer den, mens den under en blokeringsliste slutter sig til tunnelen som standard.

Administrerede konfigurationer viser det samme valg under forskellige nøglenavne, og nogle konsoller beskriver det som per-app VPN-tilstand i stedet for som en liste. Adfærden reduceres stadig til de to kald, så spor indstillingen tilbage til pakkelisten i stedet for at stole på etiketten. Hvis etiketten og listen er uenige, vinder listen.

Følg UID-reglen til tunnelens tabel

Android giver hver app sit eget Linux-bruger-ID, og VPN-tjenesten installerer politikregler, der matcher UID-intervaller. Matchende trafik sendes til en rutertabel, hvis standardrute peger på tun-enheden. Tabelnummeret tildeles per VPN-instans, så det ændres efter en genopkobling eller efter oprettelse af en anden VPN-profil.

Regeloutputtet er kortet. Hver linje navngiver en opslagstabel, og den tabel holder standardruten, der afgør, om matchende pakker kommer ind i tunnelen.

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

Kør den tredje kommando først for at få UID'en, og find derefter reglen, hvis interval indeholder den. Den regel peger på et tabelnummer, og ip route show table <n> med det nummer viser, om der findes en standardrute gennem tun-enheden. Hvis tabellen ikke har en standardrute, er appen valgt, men har ingen vej, hvilket er en anden fejl.

Disse kommandoer kræver et build, der kan fejlfindes, eller en enhed, hvor adb shell kan læse netværkstilstanden. På en produktionshåndsæt svarer pakkehåndteringen stadig, men ruterinspektionen kan blive afvist, så noter, hvad du kan, og behandl resten som uverificeret.

En rute kræver et præfiks, ikke en app

Builder.addRoute kræver destinationspræfikser til tunnelen. En profil, der kun tilføjer 10.0.0.0/8 sender det præfiks gennem tunnelen og lader enhver anden destination blive på den fysiske vej. Det er almindelig opdelt tunnellering, og det er uafhængigt af, hvilke apps reglerne valgte.

Server-skubbet konfiguration afspejler den samme model. Individuelle ruteskub tilføjer præfikser, mens en redirect-gateway-direktiv erstatter standardruten og fanger alt for de apps, tunnelen dækker. At fjerne den direktiv kan krympe en fungerende tunnel til et enkelt undernet uden nogen ændring på enheden.

En skubbet rute med en usædvanlig gateway eller metrisk kvalifikator kan også undlade at blive installeret. Foretræk den almindelige præfiksform og lad serveren håndtere videresendelse og NAT.

Læs snittet, før du ændrer en indstilling

Tunnelen bærer snittet mellem de dækkede processer og de krævede destinationer. En dækket app, der beder om en adresse uden for de offentliggjorte præfikser, forlader via det fysiske netværk. En blokeret pakke forbliver udenfor, selv når den beder om en adresse inden for disse præfikser. Ingen af tilfældene er en fejl; begge er de to politikker, der gør deres arbejde.

En per-app VPN kan også efterlade en tilknyttet app uden forbindelse. Når on-demand er slået fra, og tunnelen er nede, forbliver appen bundet til per-app VPN'en og har ingen reserve, hvilket ligner en ødelagt app snarere end en politiktilstand. At slå on-demand til eller fjerne tilknytningen via administration ændrer det.

Diagnostiser én akse ad gangen. Bekræft tilladelse eller blokering først, læs de installerede UID-regler og tabeller som det andet, og test en anden app mod den samme destination sidst. Den anden app adskiller procesvalg fra destinationsvalg i en enkelt anmodning.

Skriv resultatet ned som app, destination og tabelnummer. Den tuple er det, den næste ændring skal bevare.