NetGuards SOCKS-tilstand dækker TCP, ikke alle protokoller

NetGuard optager Androids VPN-grænseflade for at filtrere trafik, og det kan overlade understøttede forbindelser til et SOCKS-endepunkt. Disse to kendsgerninger læses ofte som “telefonen er på en VPN”, hvilket er en konklusion, mekanismen ikke understøtter. Filteret ser pakker; proxyen ser kun de forbindelser, der faktisk blev overladt til den. Mellem disse to udsagn ligger hele spørgsmålet om dækning.

FAQ'en i opstrømsprojektet dokumenterer både begrænsningen til én tjeneste og SOCKS-muligheden. Mulighedens eksistens er ikke bevis for, at hver tilladt pakke bruger den, og netop dette hul er, hvor dækningsspørgsmålene kommer fra.

To videresendelsesveje i én app

TCP-siden af implementeringen indeholder SOCKS-forbindelseshåndtering, så en tilladt TCP-forbindelse kan forhandles med proxyen og føres gennem den. UDP-siden har en separat socketvej, og dens håndtering af afsendelse og modtagelse afhænger ikke af den TCP-forhandling. Et datagram, som filteret tillader, kan derfor nå det almindelige netværk uden nogensinde at passere proxyen. Intet af dette er en defekt i appen; det er ganske enkelt, hvad de to veje implementerer.

Denne sondring har en konsekvens, som folk beskriver forkert i begge retninger. At kalde hver UDP-pakke en lækage ignorerer blokeringsreglerne, fordi et afvist datagram aldrig forlader enheden. At kalde hele arrangementet en VPN ignorerer den tilladte direkte vej, fordi noget trafik faktisk forlader uden proxy. Det, du har, er en filtreret enhed med delvis proxy, og den ærlige beskrivelse er en matrice, ikke en etiket.

At annoncere UDP er ikke at implementere det

En SOCKS-server, der hævder UDP-understøttelse, tilføjer ikke den tilsvarende klienthåndtering til appen på din telefon. Protokollens teoretiske funktioner og adfærden i den installerede build er forskellige emner, og kun det andet beskriver din trafik.

Kontroller den version og konfiguration, du faktisk kører, test derefter en uskadelig datagramstrøm, og se, om den dukker op hos proxyen. Alt andet er slutninger fra en funktionsliste, og funktionslister beskriver hensigter, ikke kodestier.

DNS er en tredje vej, ikke en detalje

Navneopløsning tilføjer sin egen gren til matricen. En lokal DNS-videresender, en almindelig UDP-opslag, et destinationsværtsnavn, som proxyen selv opløser, og en krypteret resolver i browseren er fire forskellige arrangementer. De adskiller sig i, hvem der ser forespørgslen, og hvilken netværksvej der bærer den, og at blande dem giver en test, der intet beviser om de andre.

Beslut bevidst, hvilken du vil have. Hvis kravet er, at navne opløses gennem tunnelen, vil en browserindstilling alene ikke levere det, og en proxy, der selv opløser værtsnavne, ændrer kun svaret for de forbindelser, den faktisk håndterer.

Proxytransporten er ikke automatisk privat

Almindelig SOCKS er ikke et krypteret led fra telefon til proxy. Hvis endepunktet nås gennem en anden beskyttet vej, skal du navngive den vej og dens fejlpolitik, fordi et fald tilbage til det åbne netværk gør et privat arrangement offentligt uden varsel. Proxyens egen godkendelse betyder også noget: en åben lytter på en delt enhed er en tjeneste, som ingen står til regnskab for.

Arrangementer på tværs af profiler fortjener samme granskning. En arbejdsprofil-VPN beskytter kun den trafik, der bruger dens vej, og samtidig eksistens af en personlig profil-firewall og en arbejdstunnel beviser ikke, at firewallens videre forbindelse når den tunnel. Verificer rækkevidde og godkendelse i stedet for at antage, at de to profiler samarbejder.

Revider dækningen med en matrice, ikke med en sideindlæsning

Til en autoriseret evaluering skal du vælge uskadelige eksempler, der repræsenterer hver klasse, du bekymrer dig om: påkrævet TCP, tilladt UDP og DNS i begge adressefamilier. For hver af dem skal du registrere, om den blev proxet, blokeret eller sendt direkte. Den ene tabel er leverancen, og den er langt mere nyttig end et skærmbillede af en side, der indlæstes.

Hvis kravet er, at al valgt applikationstrafik skal passere en ekstern tunnel, skal du vælge en implementering med eksplicit understøttet kombineret filtrering og tunnellering. En sammensætning med kun TCP-proxy forbliver nyttig til snævrere opgaver, forudsat at den øvrige trafik håndteres med vilje i stedet for at blive glemt.