Uitgesloten app toch online? Regels per app en voor routes verschillen

Een pakket uitsluiten is een routeringsinstructie, geen blokkade, dus de pagina's die laden nadat de VPN verbindt, zijn te verwachten en geen bewijs van een storing. De uitsluiting haalt de app uit de tunnel in plaats van hem te blokkeren, en het gewone netwerk draagt het verkeer. Hier komen twee aparte beleidsregels samen: de ene kiest processen, de andere kiest bestemmingen. Ze in die volgorde lezen verklaart waarom een verbonden pictogram en een werkende app geen tegenspraak zijn.

Waarom een uitsluiting het netwerk openhoudt

VpnService.Builder accepteert ofwel een toelatingslijst ofwel een blokkeerlijst, nooit beide. Alleen pakketten op een toelatingslijst worden door de tunnel gerouteerd. Een blokkeerlijst keert dat om: elk pakket behalve de genoemde gebruikt de tunnel, en de genoemde houden het fysieke pad. Een niet-genoemd pakket staat onder een toelatingslijst ook buiten de tunnel, dus uitsluiting is de normale toestand voor de meeste apps in die modus.

Dat maakt een lokale blokkadevermelding een routeringsbeslissing, geen firewallregel. Als de eis is om een app te beletten een host te bereiken, moet de tunnel hem dekken en moet de server of een lokaal beleid het verkeer weigeren. Een app uit de tunnel halen verandert alleen welke interface zijn pakketten draagt.

Het Play Store-geval is het gebruikelijke bewuste voorbeeld. De winkelpakket uitsluiten laat downloads de onderliggende verbinding gebruiken wanneer de VPN-uitgang overdrachten verstoort, en het toont dat uitsluiting omzeiling betekent, geen blokkade.

Eén profiel, één lijst

De builder gooit een fout als beide aanroepen worden gebruikt, dus het profiel voor u is ofwel een toelatings- of een blokkeerlijst. Dat ene feit bepaalt hoe elke latere waarneming moet worden gelezen. Controleer de code of de beheerde configuratie vóór de routeringstabel, want de lijst bepaalt wat de rest van de uitvoer betekent. Een hybride profiel is geen toestand waar u naar kunt kijken.

Het verschil voorspelt ook wat een nieuw geïnstalleerde app zal doen. Onder een toelatingslijst blijft hij buiten tot iemand hem toevoegt, terwijl hij onder een blokkeerlijst standaard bij de tunnel komt.

Beheerde configuraties bieden dezelfde keuze onder andere sleutelnamen, en sommige consoles beschrijven het als VPN-modus per app in plaats van als een lijst. Het gedrag komt nog steeds neer op die twee aanroepen, dus volg de instelling terug naar de pakketlijst in plaats van het label te vertrouwen. Als het label en de lijst verschillen, wint de lijst.

Volg de UID-regel naar de tunneltabel

Android geeft elke app zijn eigen Linux-gebruikers-ID, en de VPN-dienst installeert beleidsregels die overeenkomen met UID-bereiken. Overeenkomend verkeer wordt naar een routeringstabel gestuurd waarvan de standaardroute naar het tun-apparaat wijst. Het tabelnummer wordt per VPN-instantie toegewezen, dus het verandert na een herverbinding of na het aanmaken van een tweede VPN-profiel.

De regeluitvoer is de kaart. Elke regel noemt een opzoektabel, en die tabel bevat de standaardroute die bepaalt of overeenkomende pakketten de tunnel binnengaan.

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

Voer eerst de derde opdracht uit om de UID te krijgen en zoek dan de regel waarvan het bereik hem bevat. Die regel wijst naar een tabelnummer, en ip route show table <n> met dat nummer blijkt of er een standaardroute via het tun-apparaat is. Als de tabel geen standaardroute heeft, is de app geselecteerd maar heeft hij geen pad, wat een andere storing is.

Deze opdrachten vereisen een debugbare build of een apparaat waarop adb shell de netwerkstatus kan lezen. Op een productietoestel antwoordt de pakketbeheerder nog, maar de routeringsinspectie kan worden geweigerd, dus leg vast wat u kunt en behandel de rest als onbevestigd.

Een route claimt een prefix, geen app

Builder.addRoute claimt bestemmingsprefixen voor de tunnel. Een profiel dat alleen 10.0.0.0/8 toevoegt, stuurt dat prefix door de tunnel en laat elke andere bestemming op het fysieke pad. Dat is gewoon gesplitst tunnelen, en het is onafhankelijk van welke apps de regels hebben geselecteerd.

De door de server gepushte configuratie weerspiegelt hetzelfde model. Afzonderlijke routepushes voegen prefixen toe, terwijl een redirect-gateway-richtlijn de standaardroute vervangt en alles vangt voor de apps die de tunnel dekt. Die richtlijn verwijderen kan een werkende tunnel zonder enige wijziging op het apparaat inkrimpen tot één subnet.

Een gepushte route met een ongebruikelijke gateway of metrische kwalificatie kan ook niet worden geïnstalleerd. Geef de voorkeur aan de eenvoudige prefixvorm en laat de server de doorgifte en NAT afhandelen.

Lees de doorsnede voordat u een instelling wijzigt

De tunnel draagt de doorsnede van de gedekte processen en de geclaimde bestemmingen. Een gedekte app die een adres buiten de gepubliceerde prefixen vraagt, verlaat via het fysieke netwerk. Een geblokkeerd pakket blijft buiten, zelfs wanneer het een adres binnen die prefixen vraagt. Geen van beide gevallen is een bug; beide zijn de twee beleidsregels die hun werk doen.

Een VPN per app kan een gekoppelde app ook zonder verbinding achterlaten. Wanneer on-demand uit staat en de tunnel plat ligt, blijft de app aan de per-app-VPN gebonden en heeft hij geen terugval, wat op een kapotte app lijkt in plaats van op een beleidstoestand. On-demand aanzetten, of de koppeling via beheer verwijderen, verandert dat.

Diagnostiseer één as tegelijk. Bevestig eerst toestaan of blokkeren, lees ten tweede de geïnstalleerde UID-regels en tabellen, en test ten slotte een tweede app tegen dezelfde bestemming. De tweede app scheidt proceskeuze van bestemmingskeuze in één verzoek.

Schrijf het resultaat op als app, bestemming en tabelnummer. Die tuple is wat de volgende wijziging moet bewaren.