SOCKS-modusen i NetGuard dekkjer TCP, ikkje kvar protokoll

NetGuard okkuperer VPN-grensesnittet til Android for å filtrera trafikk, og det kan overlevera støtta tilkoplingar til eit SOCKS-endepunkt. Desse to fakta vert ofte lesne som «telefonen er på ein VPN», ein konklusjon mekanismen ikkje støttar. Filteret ser pakkar; proxyen ser berre tilkoplingane som faktisk vart overleverte til han. Mellom desse to utsegnene ligg heile spørsmålet om dekning.

FAQ-en i oppstraumsprosjektet dokumenterer både avgrensinga til éin teneste og SOCKS-alternativet. At alternativet finst er ikkje prov for at kvar tillaten pakke brukar det, og nettopp frå dette gapet kjem dekningsspørsmåla.

To vidaresendingsvegar i éin app

TCP-sida av implementasjonen inneheld SOCKS-tilkoplingshandtering, så ei tillaten TCP-tilkopling kan forhandlast med proxyen og førast gjennom han. UDP-sida har ein eigen socket-veg, og handteringa hennar av sending og mottak er ikkje avhengig av den TCP-forhandlinga. Eit datagram som filteret tillèt kan difor nå det vanlege nettet utan å nokon gong passera proxyen. Ingenting av dette er ein feil i appen; det er rett og slett det dei to vegane implementerer.

Denne skilnaden har ei fylgje som folk skildrar feil i begge retningar. Å kalla kvar UDP-pakke ein lekkasje ignorerer blokkeringsreglane, fordi eit avvist datagram aldri forlèt eininga. Å kalla heile ordninga ein VPN ignorerer den tillatne direkte vegen, fordi noko trafikk faktisk forlèt utan proxy. Det du har er ei filtrert eining med delvis proxy, og den ærlege skildringa er ein matrise, ikkje ein etikett.

Å annonsera UDP er ikkje å implementera det

Ein SOCKS-server som hevdar UDP-støtte legg ikkje til den tilsvarande klienthandteringa i appen på telefonen din. Dei teoretiske eigenskapane til protokollen og åtferda til den installerte bygginga er ulike emne, og berre det andre skildrar trafikken din.

Kontroller versjonen og konfigurasjonen du faktisk køyrer, test deretter ein ufarleg datagramstraum og sjå om han dukkar opp hos proxyen. Alt anna er slutningar frå ei funksjonsliste, og funksjonslister skildrar intensjonar, ikkje kodevegar.

DNS er ein tredje veg, ikkje ein detalj

Namneoppslag legg si eiga grein til matrisen. Ein lokal DNS-vidaresendar, eit vanleg UDP-oppslag, eit destinasjonsvertsnamn som proxyen sjølv løyser opp, og ein kryptert resolver i nettlesaren er fire ulike ordningar. Dei skil seg i kven som ser spørjinga og kva nettverksveg som ber henne, og å blanda dei gjev ein test som ikkje provar noko om dei andre.

Avgjer medvite kva du vil ha. Viss kravet er at namn skal løysast gjennom tunnelen, vil ei nettlesarinnstilling åleine ikkje levera det, og ein proxy som sjølv løyser opp vertsnamn endrar berre svaret for tilkoplingane han faktisk handterer.

Proxy-transporten er ikkje automatisk privat

Vanleg SOCKS er ikkje ei kryptert samband frå telefon til proxy. Viss endepunktet vert nådd gjennom ein annan verna veg, nemn den vegen og feilpolitikken hans, fordi eit fall tilbake til det opne nettet gjer ei privat ordning offentleg utan varsel. Autentiseringa til proxyen sjølv tel òg: ein open lyttar på ei delt eining er ei teneste ingen står til rekneskap for.

Ordningar på tvers av profilar fortener same gransking. Ein arbeidsprofil-VPN verner berre trafikken som brukar vegen hans, og at ein personleg profil-brannmur og ein arbeidstunnel finst samstundes provar ikkje at den vidare sambandet til brannmuren når den tunnelen. Verifiser rekkevidd og autentisering i staden for å gå ut frå at dei to profilane samarbeider.

Revider dekninga med ein matrise, ikkje med ei sideinnlasting

For ei autorisert vurdering, vel ufarlege døme som representerer kvar klasse du bryr deg om: påkravd TCP, tillaten UDP og DNS i begge adressefamiliane. For kvar av dei, registrer om han vart proxa, blokkert eller send direkte. Den eine tabellen er leveransen, og han er langt nyttigare enn eit skjermbilete av ei side som lasta.

Viss kravet er at all vald applikasjonstrafikk må passera ein ekstern tunnel, vel ein implementasjon med eksplisitt støtta kombinert filtrering og tunnellering. Ein samansetning med berre TCP-proxy er framleis nyttig for smalare oppgåver, føresett at den øvrige trafikken vert handtert med vilje i staden for å verta gløymt.