Modul SOCKS al NetGuard acoperă TCP, nu fiecare protocol

NetGuard ocupă interfața VPN a Androidului pentru a filtra traficul și poate preda conexiunile acceptate către un punct final SOCKS. Aceste două fapte sunt adesea citite ca „telefonul este pe un VPN”, o concluzie pe care mecanismul nu o susține. Filtrul vede pachete; proxy-ul vede doar conexiunile care i-au fost efectiv predate. Între aceste două afirmații stă întreaga întrebare a acoperirii.

Întrebările frecvente ale proiectului original documentează atât limitarea la un singur serviciu, cât și opțiunea SOCKS. Existența opțiunii nu este dovada că fiecare pachet permis o folosește, iar întrebările despre acoperire provin exact din această lacună.

Două căi de redirecționare într-o singură aplicație

Partea TCP a implementării conține tratarea conexiunilor SOCKS, astfel încât o conexiune TCP permisă poate fi negociată cu proxy-ul și transportată prin el. Partea UDP are o cale de socket separată, iar tratarea trimiterii și primirii ei nu depinde de acea negociere TCP. Prin urmare, un datagram pe care filtrul îl permite poate ajunge în rețeaua obișnuită fără a trece vreodată prin proxy. Nimic din toate acestea nu este un defect al aplicației; este pur și simplu ceea ce implementează cele două căi.

Această distincție are o consecință pe care oamenii o descriu greșit în ambele direcții. A numi fiecare pachet UDP o scurgere ignoră regulile de blocare, pentru că un datagram respins nu pleacă niciodată. A numi întreaga aranjare un VPN ignoră calea directă permisă, pentru că o parte din trafic chiar pleacă fără proxy. Ceea ce ai este un dispozitiv filtrat cu proxy parțial, iar descrierea onestă este o matrice, nu o etichetă.

A anunța UDP nu înseamnă a-l implementa

Un server SOCKS care pretinde suport UDP nu adaugă tratarea corespunzătoare pe partea de client în aplicația de pe telefonul tău. Caracteristicile teoretice ale protocolului și comportamentul versiunii instalate sunt subiecte diferite, iar doar al doilea descrie traficul tău.

Verifică versiunea și configurația pe care o rulezi efectiv, apoi testează un flux de datagrame inofensiv și observă dacă apare la proxy. Orice altceva este o inferență dintr-o listă de funcții, iar listele de funcții descriu intenții, nu căi de cod.

DNS este o a treia cale, nu un detaliu

Rezolvarea numelor adaugă propria ramură matricei. Un redirecționar DNS local, o interogare UDP obișnuită, un nume de gazdă de destinație rezolvat de proxy-ul însuși și un rezolvitor criptat din browser sunt patru aranjamente distincte. Ele diferă prin cine vede interogarea și prin ce cale de rețea o transportă, iar amestecarea lor produce un test care nu demonstrează nimic despre celelalte.

Decide deliberat pe care îl vrei. Dacă cerința este ca numele să fie rezolvate prin tunel, o singură setare de browser nu o va oferi, iar un proxy care rezolvă singur numele de gazdă schimbă răspunsul doar pentru conexiunile pe care le tratează efectiv.

Transportul prin proxy nu este privat automat

SOCKS simplu nu este o legătură criptată de la telefon la proxy. Dacă punctul final este atins printr-o altă cale protejată, numește acea cale și politica ei de eșec, pentru că o revenire la rețeaua deschisă transformă o aranjare privată într-una publică fără avertisment. Și autentificarea proxy-ului contează: un ascultător deschis pe un dispozitiv partajat este un serviciu de care nimeni nu răspunde.

Aranjamentele între profiluri merită aceeași examinare. Un VPN de profil de lucru protejează doar traficul care îi folosește calea, iar coexistența unui firewall de profil personal cu un tunel de lucru nu dovedește că legătura ulterioară a firewall-ului ajunge la acel tunel. Verifică accesibilitatea și autentificarea în loc să presupui că cele două profiluri cooperează.

Auditează acoperirea cu o matrice, nu cu încărcarea unei pagini

Pentru o evaluare autorizată, alege exemple inofensive care reprezintă fiecare clasă care te interesează: TCP necesar, UDP permis și DNS în ambele familii de adrese. Pentru fiecare, notează dacă a fost proxificat, blocat sau trimis direct. Acel singur tabel este rezultatul și este mult mai util decât o captură de ecran a unei pagini încărcate.

Dacă cerința este ca tot traficul de aplicații selectat să treacă printr-un tunel la distanță, alege o implementare cu filtrare și tunelare combinate susținute explicit. O compoziție cu proxy doar TCP rămâne utilă pentru sarcini mai înguste, cu condiția ca celălalt trafic să fie tratat intenționat, nu uitat.