NetGuards SOCKS-modus dekker TCP, ikke hver protokoll

NetGuard okkuperer Androids VPN-grensesnitt for å filtrere trafikk, og det kan overlate støttede tilkoblinger til et SOCKS-endepunkt. Disse to fakta leses ofte som «telefonen er på en VPN», en konklusjon mekanismen ikke støtter. Filteret ser pakker; proxyen ser bare tilkoblingene som faktisk ble overlevert til den. Mellom disse to utsagnene ligger hele spørsmålet om dekning.

FAQ-en i oppstrømsprosjektet dokumenterer både begrensningen til én tjeneste og SOCKS-alternativet. At alternativet finnes er ikke bevis for at hver tillatt pakke bruker det, og nettopp fra dette gapet kommer dekningsspørsmålene.

To videresendingsveier i én app

TCP-siden av implementasjonen inneholder SOCKS-tilkoblingshåndtering, så en tillatt TCP-tilkobling kan forhandles med proxyen og føres gjennom den. UDP-siden har en egen socket-vei, og dens håndtering av sending og mottak avhenger ikke av den TCP-forhandlingen. En datagram som filteret tillater kan derfor nå det vanlige nettet uten å noen gang passere proxyen. Ingenting av dette er en feil i appen; det er rett og slett det de to veiene implementerer.

Denne forskjellen har en konsekvens som folk beskriver feil i begge retninger. Å kalle hver UDP-pakke en lekkasje ignorerer blokkeringsreglene, fordi en avvist datagram aldri forlater enheten. Å kalle hele ordningen en VPN ignorerer den tillatte direkte veien, fordi noe trafikk faktisk forlater uten proxy. Det du har er en filtrert enhet med delvis proxy, og den ærlige beskrivelsen er en matrise, ikke en etikett.

Å annonsere UDP er ikke å implementere det

En SOCKS-server som hevder UDP-støtte, legger ikke til den tilsvarende klienthåndteringen i appen på telefonen din. Protokollens teoretiske egenskaper og oppførselen til den installerte byggingen er forskjellige emner, og bare det andre beskriver trafikken din.

Kontroller versjonen og konfigurasjonen du faktisk kjører, test deretter en ufarlig datagramstrøm og se om den dukker opp hos proxyen. Alt annet er slutninger fra en funksjonsliste, og funksjonslister beskriver intensjoner, ikke kodeveier.

DNS er en tredje vei, ikke en detalj

Navneoppslag legger sin egen gren til matrisen. En lokal DNS-videresender, et vanlig UDP-oppslag, et destinasjonsvertsnavn som proxyen selv løser opp, og en kryptert resolver i nettleseren er fire forskjellige ordninger. De skiller seg i hvem som ser spørringen og hvilken nettverksvei som bærer den, og å blande dem gir en test som ikke beviser noe om de andre.

Bestem bevisst hvilken du vil ha. Hvis kravet er at navn skal løses gjennom tunnelen, vil en nettleserinnstilling alene ikke levere det, og en proxy som selv løser opp vertsnavn endrer bare svaret for tilkoblingene den faktisk håndterer.

Proxy-transporten er ikke automatisk privat

Vanlig SOCKS er ikke en kryptert forbindelse fra telefon til proxy. Hvis endepunktet nås gjennom en annen beskyttet vei, navngi den veien og dens feilpolicy, fordi et fall tilbake til det åpne nettet gjør en privat ordning offentlig uten varsel. Proxyens egen autentisering betyr også noe: en åpen lytter på en delt enhet er en tjeneste ingen står til regnskap for.

Ordninger på tvers av profiler fortjener samme gransking. En arbeidsprofil-VPN beskytter bare trafikken som bruker dens vei, og samtidig eksistens av en personlig profil-brannmur og en arbeidstunnel beviser ikke at brannmurens videre forbindelse når den tunnelen. Verifiser rekkevidde og autentisering i stedet for å anta at de to profilene samarbeider.

Revider dekningen med en matrise, ikke med en sideinnlasting

For en autorisert evaluering, velg ufarlige eksempler som representerer hver klasse du bryr deg om: påkrevd TCP, tillatt UDP og DNS i begge adressefamilier. For hver av dem, registrer om den ble proxet, blokkert eller sendt direkte. Den ene tabellen er leveransen, og den er langt nyttigere enn et skjermbilde av en side som lastet.

Hvis kravet er at all valgt applikasjonstrafikk må passere en ekstern tunnel, velg en implementasjon med eksplisitt støttet kombinert filtrering og tunnellering. En sammensetning med bare TCP-proxy forblir nyttig for smalere oppgaver, forutsatt at den øvrige trafikken håndteres med vilje i stedet for å bli glemt.