NetGuards SOCKS-läge täcker TCP, inte alla protokoll

NetGuard tar Androids VPN-gränssnitt i anspråk för att filtrera trafik, och kan lämna över stödda anslutningar till en SOCKS-slutpunkt. Dessa två fakta läses ofta som ”telefonen är på en VPN”, en slutsats som mekanismen inte stöder. Filtret ser paket; proxyn ser bara de anslutningar som faktiskt lämnades över till den. Mellan dessa två påståenden ligger hela frågan om täckning.

Ursprungsprojektets FAQ dokumenterar både begränsningen till en enda tjänst och SOCKS-alternativet. Att alternativet finns är inte bevis för att varje tillåtet paket använder det, och det är ur denna lucka täckningsfrågorna uppstår.

Två vidarebefordringsvägar i en och samma app

TCP-sidan av implementeringen innehåller hantering av SOCKS-anslutningar, så en tillåten TCP-anslutning kan förhandlas med proxyn och föras genom den. UDP-sidan har en separat socket-väg, och dess hantering av sändning och mottagning beror inte på den TCP-förhandlingen. Ett datagram som filtret tillåter kan därför nå det vanliga nätet utan att någonsin passera proxyn. Inget av detta är en defekt i appen; det är helt enkelt vad de två vägarna implementerar.

Denna skillnad har en konsekvens som människor beskriver fel i båda riktningarna. Att kalla varje UDP-paket en läcka ignorerar blockeringsreglerna, eftersom ett avvisat datagram aldrig lämnar enheten. Att kalla hela arrangemanget en VPN ignorerar den tillåtna direkta vägen, eftersom en del trafik faktiskt lämnar utan proxy. Det du har är en filtrerad enhet med delvis proxy, och den ärliga beskrivningen är en matris, inte en etikett.

Att annonsera UDP är inte att implementera det

En SOCKS-server som hävdar UDP-stöd lägger inte till motsvarande klientsidig hantering i appen på din telefon. Protokollets teoretiska egenskaper och det installerade byggets beteende är olika ämnen, och bara det andra beskriver din trafik.

Kontrollera versionen och konfigurationen du faktiskt kör, testa sedan ett ofarligt datagramflöde och se om det dyker upp hos proxyn. Allt annat är slutsatser från en funktionslista, och funktionslistor beskriver avsikter, inte kodvägar.

DNS är en tredje väg, inte en detalj

Namnuppslagning lägger till sin egen gren i matrisen. En lokal DNS-vidarebefordrare, en vanlig UDP-förfrågan, ett destinationsvärdnamn som proxyn själv löser upp och en krypterad resolver i webbläsaren är fyra olika arrangemang. De skiljer sig i vem som ser förfrågan och vilken nätverksväg som bär den, och att blanda dem ger ett test som inte bevisar något om de andra.

Bestäm medvetet vilken du vill ha. Om kravet är att namn löses upp genom tunneln räcker inte en webbläsarinställning, och en proxy som själv löser upp värdnamn ändrar bara svaret för de anslutningar den faktiskt hanterar.

Transporten genom proxyn är inte automatiskt privat

Vanlig SOCKS är inte en krypterad länk från telefon till proxy. Om slutpunkten nås via en annan skyddad väg, namnge den vägen och dess felpolicy, eftersom ett fall tillbaka till det öppna nätet gör ett privat arrangemang offentligt utan varning. Proxyns egen autentisering spelar också roll: en öppen lyssnare på en delad enhet är en tjänst som ingen står till svars för.

Arrangemang mellan profiler förtjänar samma granskning. En arbetsprofil-VPN skyddar bara den trafik som använder dess väg, och att en brandvägg i den personliga profilen finns samtidigt som en arbetstunnel bevisar inte att brandväggens vidare anslutning når den tunneln. Verifiera nåbarhet och autentisering i stället för att anta att de två profilerna samarbetar.

Granska täckningen med en matris, inte med en sidladdning

Välj för en auktoriserad utvärdering ofarliga exempel som representerar varje klass du bryr dig om: nödvändig TCP, tillåten UDP och DNS i båda adressfamiljerna. Anteckna för varje om det proxades, blockerades eller skickades direkt. Den enda tabellen är leveransen, och den är mycket mer användbar än en skärmbild av en sida som laddades.

Om kravet är att all vald applikationstrafik måste passera en fjärrtunnel, välj en implementering med uttryckligen stödd kombinerad filtrering och tunnling. En sammansättning med bara TCP-proxy förblir användbar för snävare uppgifter, förutsatt att den övriga trafiken hanteras med avsikt i stället för att glömmas bort.