Utesluten app fortfarande online? Regler per app och för rutter skiljer sig

Att utesluta ett paket är en rutteringsinstruktion, inte en blockering, så sidorna som laddas efter att VPN:en ansluter är väntade och inte bevis på ett fel. Uteslutningen tar bort appen från tunneln i stället för att blockera den, och det vanliga nätet bär dess trafik. Här möts två separata policyer: den ena väljer processer, den andra väljer destinationer. Att läsa dem i den ordningen förklarar varför en ansluten ikon och en fungerande app inte är en motsägelse.

Varför en uteslutning håller nätet öppet

VpnService.Builder accepterar antingen en tillåtelselista eller en blockeringslista, aldrig båda. Endast paket på en tillåtelselista dirigeras genom tunneln. En blockeringslista vänder på det: varje paket utom de listade använder tunneln, och de listade behåller den fysiska vägen. Ett paket som inte är listat är under en tillåtelselista också utanför tunneln, så uteslutning är normaltillståndet för de flesta appar i det läget.

Det gör en lokal blockeringspost till ett rutteringsbeslut, inte en brandväggsregel. Om kravet är att hindra en app från att nå en värd måste tunneln täcka den, och servern eller en lokal policy måste avvisa trafiken. Att ta bort en app från tunneln ändrar bara vilket gränssnitt som bär dess paket.

Play Store-fallet är det vanliga avsiktliga exemplet. Att utesluta butikens paket låter nedladdningar använda den underliggande anslutningen när VPN-utgången stör överföringar, och det visar att uteslutning betyder kringgående, inte blockering.

En profil, en lista

Byggaren kastar ett fel om båda anropen används, så profilen framför dig är antingen en tillåtelse- eller en blockeringslista. Det enda faktumet avgör hur varje senare observation ska läsas. Kontrollera koden eller den hanterade konfigurationen före rutterningstabellen, eftersom listan avgör vad resten av utdata betyder. En hybridprofil är inte ett tillstånd du kan titta på.

Skillnaden förutsäger också vad en nyligen installerad app kommer att göra. Under en tillåtelselista stannar den utanför tills någon lägger till den, medan den under en blockeringslista ansluter till tunneln som standard.

Hanterade konfigurationer visar samma val under olika nyckelnamn, och vissa konsoler beskriver det som per-app-VPN-läge i stället för som en lista. Beteendet reduceras ändå till de två anropen, så spåra inställningen tillbaka till paketlistan i stället för att lita på etiketten. Om etiketten och listan inte stämmer överens vinner listan.

Följ UID-regeln till tunnelns tabell

Android ger varje app sitt eget Linux-användar-ID, och VPN-tjänsten installerar policyregler som matchar UID-intervall. Matchande trafik skickas till en rutterningstabell vars standardrutt pekar på tun-enheten. Tabellnumret tilldelas per VPN-instans, så det ändras efter en återanslutning eller efter att en andra VPN-profil skapats.

Regelutdata är kartan. Varje rad namnger en slagningstabell, och den tabellen håller standardrutten som avgör om matchande paket kommer in i tunneln.

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

Kör det tredje kommandot först för att få UID:t och hitta sedan regeln vars intervall innehåller det. Den regeln pekar på ett tabellnummer, och ip route show table <n> med det numret visas om det finns en standardrutt genom tun-enheten. Om tabellen inte har någon standardrutt är appen vald men har ingen väg, vilket är ett annat fel.

De här kommandona kräver en byggbar build eller en enhet där adb shell kan läsa nätverkstillståndet. På en produktionshandenhet svarar pakethanteraren fortfarande, men rutteringsinspektionen kan avvisas, så registrera det du kan och behandla resten som overifierat.

En rutt kräver ett prefix, inte en app

Builder.addRoute kräver destinationsprefix för tunneln. En profil som bara lägger till 10.0.0.0/8 skickar det prefixet genom tunneln och lämnar varje annan destination på den fysiska vägen. Det är vanlig delad tunnling, och det är oberoende av vilka appar reglerna valde.

Serverpushad konfiguration speglar samma modell. Enskilda ruttpushar lägger till prefix, medan ett redirect-gateway-direktiv ersätter standardrutten och fångar allt för de appar som tunneln täcker. Att ta bort det direktivet kan krympa en fungerande tunnel till ett enda delnät utan någon ändring på enheten.

En pushad rutt med en ovanlig gateway eller metrisk kvalificerare kan också misslyckas med att installeras. Föredra den enkla prefixformen och låt servern hantera vidarebefordran och NAT.

Läs snittet innan du ändrar en inställning

Tunneln bär snittet av de täckta processerna och de begärda destinationerna. En täckt app som begär en adress utanför de publicerade prefixen lämnar via det fysiska nätet. Ett blockerat paket stannar utanför även när det begär en adress inom dessa prefix. Inget av fallen är en bugg; båda är de två policyerna som gör sitt jobb.

Ett per-app-VPN kan också lämna en associerad app utan anslutning. När on-demand är av och tunneln ligger nere förblir appen bunden till per-app-VPN:en och har ingen reserv, vilket ser ut som en trasig app snarare än ett policytillstånd. Att slå på on-demand eller ta bort associationen via hantering ändrar det.

Diagnostisera en axel i taget. Bekräfta tillåtelse eller blockering först, läs de installerade UID-reglerna och tabellerna som nummer två, och testa en andra app mot samma destination sist. Den andra appen skiljer processval från destinationsval i en enda begäran.

Skriv ner resultatet som app, destination och tabellnummer. Det är den tupeln som nästa ändring måste bevara.