Način SOCKS v NetGuardu pokriva TCP, ne vsak protokol

NetGuard zasede vmesnik VPN sistema Android, da filtrira promet, in lahko podprte povezave preda končni točki SOCKS. Ti dve dejstvi se pogosto bereta kot »telefon je v VPN«, kar je sklep, ki ga mehanizem ne podpira. Filter vidi pakete; posrednik vidi le povezave, ki so mu bile dejansko predane. Med tema dvema trditvama stoji vse vprašanje pokritosti.

FAQ izvirnega projekta dokumentira tako omejitev na eno storitev kot možnost SOCKS. Obstoj možnosti ni dokaz, da jo uporablja vsak dovoljen paket, in vprašanja o pokritosti izhajajo prav iz te vrzeli.

Dve poti posredovanja v eni aplikaciji

Stran TCP implementacije vsebuje obdelavo povezav SOCKS, zato je dovoljeno povezavo TCP mogoče dogovoriti s posrednikom in jo prenesti skozi njega. Stran UDP ima ločeno pot vtičnice, njena obdelava pošiljanja in sprejemanja pa ni odvisna od tega dogovora TCP. Zato lahko datagram, ki ga filter dovoli, doseže običajno omrežje, ne da bi kdaj šel skozi posrednika. Nič od tega ni napaka aplikacije; to je preprosto tisto, kar izvajata obe poti.

Ta razlika ima posledico, ki jo ljudje napačno opisujejo v obeh smereh. Vsak paket UDP označiti za uhajanje pomeni ignorirati pravila blokiranja, ker zavrnjen datagram nikoli ne odide. Celotno ureditev označiti za VPN pomeni ignorirati dovoljeno neposredno pot, ker del prometa res odide brez posrednika. Kar imate, je filtrirana naprava z delnim posrednikom, pošten opis pa je matrika, ne oznaka.

Oglaševati UDP še ni izvajati ga

Strežnik SOCKS, ki trdi, da podpira UDP, aplikaciji v vašem telefonu ne doda ustrezne obdelave na strani odjemalca. Teoretične značilnosti protokola in vedenje nameščene različice so različne teme, in le drugo opisuje vaš promet.

Preverite različico in konfiguracijo, ki jo resnično izvajate, nato preizkusite neškodljiv tok datagramov in opazujte, ali se pojavi pri posredniku. Vse drugo je sklep iz seznama funkcij, seznami funkcij pa opisujejo namere, ne poti kode.

DNS je tretja pot, ne podrobnost

Razreševanje imen doda matriki svojo vejo. Lokalni posredovalnik DNS, običajna poizvedba UDP, ime gostitelja cilja, ki ga razreši posrednik sam, in šifriran razreševalnik v brskalniku so štiri različne ureditve. Razlikujejo se po tem, kdo vidi poizvedbo in katera omrežna pot jo nosi, njihovo mešanje pa da preizkus, ki o drugih ničesar ne dokaže.

Zavestno se odločite, katero želite. Če je zahteva, da se imena razrešujejo skozi tunel, samo nastavitev brskalnika tega ne bo zagotovila, posrednik, ki sam razrešuje imena gostiteljev, pa spremeni odgovor le za povezave, ki jih resnično obdeluje.

Prenos skozi posrednika ni samodejno zaseben

Običajni SOCKS ni šifrirana povezava od telefona do posrednika. Če je končna točka dosežena po drugi zaščiteni poti, poimenujte to pot in njeno politiko odpovedi, ker vrnitev v odprto omrežje brez opozorila spremeni zasebno ureditev v javno. Pomembna je tudi avtentikacija posrednika: odprt poslušalec na deljeni napravi je storitev, za katero nihče ne odgovarja.

Ureditve med profili si zaslužijo enako preučitev. VPN delovnega profila ščiti le promet, ki uporablja njegovo pot, in soobstoj požarnega zidu osebnega profila z delovnim tunelom ne dokazuje, da nadaljnja povezava požarnega zidu doseže ta tunel. Preverjajte dosegljivost in avtentikacijo, namesto da domnevate, da profila sodelujeta.

Pokritost revidirajte z matriko, ne z nalaganjem strani

Za pooblaščeno oceno izberite neškodljive primere, ki predstavljajo vsak razred, ki vas zanima: zahtevani TCP, dovoljeni UDP in DNS v obeh družinah naslovov. Za vsakega zabeležite, ali je bil posredovan, blokiran ali poslan neposredno. Ta ena tabela je rezultat in je veliko bolj uporabna kot posnetek zaslona naložene strani.

Če je zahteva, da ves izbrani promet aplikacij poteka skozi oddaljeni tunel, izberite izvedbo z izrecno podprtim kombiniranim filtriranjem in tuneliranjem. Sestava samo s posrednikom TCP ostaja uporabna za ožje naloge, pod pogojem, da se preostali promet obravnava namerno in ne pozabljeno.