Varför trådlös felsökningstrafik inte bevisar en VPN-läcka

Du aktiverade trådlös felsökning, anslöt en laptop och sessionen fortsatte att fungera medan VPN var på. Det ser ut som om något slank förbi tunneln. Nästan säkert inte. En felsökningssession och en apps begäran till en webbplats är olika nätverksrelationer, och bara en av dem ska korsa tunneln.

Jag har stött på den här felläsningen två gånger: en gång med telefonen och laptopen på samma Wi-Fi, och en gång efter en omstart när parningen överlevde. I båda fallen gjorde VPN exakt det den var konfigurerad för.

Namnge observationen innan du namnge buggen

Tre händelser kan föregå ett läckagepåstående, och de är inte utbytbara. Ett verktyg kan upptäcka en tjänst, enheten kan godkänna en arbetsstation, eller en auktoriserad session kan faktiskt transportera kommandon och byte. Skriv ned vilken du såg, eftersom var och en bevisar mindre än folk antar.

Upptäckt är vanligtvis mDNS eller en portskanning. Parning är ett registreringsbeslut som fattas på telefonen, bekräftat med en kod som användaren skriver. En levande session betyder att trafik rörde sig mellan två parade ändpunkter. Inget av det beskriver vart en apps HTTPS-begäran tar vägen.

Håll destination, gränssnitt, adressfamilj, tidsstämpel och användarprofil kopplade till händelsen. Utan de detaljerna kan observationen inte jämföras med den avsedda policyn för lokalnätet, eller med den VPN-version som kördes då.

Varför de två vägarna aldrig möts

Trådlös felsökning är en inkommande anslutning till enheten. adbd lyssnar på en port bunden till Wi-Fi-gränssnittet, och arbetsstationen ansluter till den efter parningen. Riktningen spelar roll: din laptop når in i telefonen, inte tvärtom. Det är motsatsen till ett utgående läckage.

En apps internettrafik lämnar tunnelgränssnittet som VpnService installerar, matchat efter UID och routingregler. adbd är en systemdemon som körs som shell-användaren, inte en app i den routingmängden. Den stannar på den underliggande Wi-Fi-länken även när varje app är fäst vid tunneln.

Låsläget framtvingar tunneln för täckta appar. Det gör inte en lyssnande socket till en utgångsväg.

Därför kan en fungerande ADB-session och en fungerande kill switch samexistera utan motsägelse. För att bevisa en läcka måste du observera den riktning som borde vara blockerad.

Hur ett utgångstest faktiskt ser ut

Testa den täckta appen, inte felsökningskanalen. Ställ in feltillståndet med avsikt, gör sedan en ny begäran och registrera vad som hände.

1. Bekräfta att VPN är den enda vägen: slå på alltid-på VPN med blockera anslutningar utan VPN.
2. Stoppa VPN på det stödda sättet och bekräfta att appen rapporterar ingen anslutning.
3. Skicka en ofarlig begäran från den appen och notera om den misslyckas eller lyckas.
4. Upprepa med trådlös felsökning på, sedan av, så att variabeln isoleras.

En blockerad begäran under de förhållandena är bevis. En lyckad ADB-session är det inte, och inte heller en enda ping från en terminalapp.

Om begäran ändå lyckas medan låsläget är på, registrera appens UID och dess VPN-tillstånd, det aktiva nätverket och klientversionen. Den kombinationen är ett riktigt fynd.

Parning överlever sessionen

Parning är bestående tillstånd, inte ett handslag du kan glömma efter kabeltestet. Androids felsökningsdokumentation beskriver det trådlösa arbetsflödet och noterar att relationen varar tills den uttryckligen glöms bort eller auktorisationerna återkallas.

Kontrollera vad som fortfarande är auktoriserat innan du skyller på tunneln. Öppna Trådlös felsökning, titta på Parade enheter och glöm allt du inte längre känner igen. Kör adb devices från arbetsstationen för att se vilka poster som fortfarande svarar, och adb disconnect för att släppa en inaktuell. Slår du av trådlös felsökning stängs den lyssnande porten helt.

På ett delat eller otillförlitligt nätverk, lämna det av. En bestående auktorisation på ett nätverk du inte kontrollerar är ett större problem än en hypotetisk TUN-omgång.

Innan du rapporterar den buggen

En användbar rapport namnger den exakta gräns som misslyckades. Inkludera enhetsmodell och Android-version, VPN-klient och version, om låsläget var aktiverat, app-paketet och UID, och nätverket telefonen var på. Lägg till kommandot eller begäran som skapade observationen, plus tiden det inträffade. Utan det kan ingen återskapa den gräns du hävdar är bruten.

Inaktivera inte framtvingandet och exponera inte felsökning på ett otillförlitligt nätverk för att få testet att verka mer dramatiskt. Det ändrar systemet du mäter och lämnar bevis som ingen kan upprepa.

Om ditt enda bevis är att ADB anslöt medan VPN var på, mätte du fel väg. Kör appnivåtestet igen först; svaret kommer vanligtvis där.