Modaliteti SOCKS i NetGuard mbulon TCP, jo çdo protokoll

NetGuard zë ndërfaqen VPN të Android për të filtruar trafikun, dhe mund t'i dorëzojë lidhjet e mbështetura një pike fundore SOCKS. Këto dy fakte shpesh lexohen si «telefoni është në një VPN», një përfundim që mekanizmi nuk e mbështet. Filtri sheh paketa; përfaqësuesi sheh vetëm lidhjet që iu dorëzuan atij në të vërtetë. Midis këtyre dy pohimeve qëndron e gjithë çështja e mbulimit.

FAQ e projektit burimor dokumenton si kufizimin në një shërbim të vetëm ashtu edhe opsionin SOCKS. Ekzistenca e opsionit nuk është provë që çdo paketë e lejuar e përdor atë, dhe pyetjet e mbulimit lindin pikërisht nga kjo boshllëk.

Dy rrugë përcjelljeje brenda një aplikacioni

Ana TCP e zbatimit përmban trajtimin e lidhjeve SOCKS, kështu që një lidhje TCP e lejuar mund të negociohet me përfaqësuesin dhe të transportohet përmes tij. Ana UDP ka një rrugë të veçantë soketi, dhe trajtimi i dërgimit e pranimit të saj nuk varet nga ai negociim TCP. Prandaj, një datagram që filtri e lejon mund të arrijë rrjetin e zakonshëm pa kaluar kurrë përmes përfaqësuesit. Asgjë nga kjo nuk është defekt i aplikacionit; është thjesht ajo që zbatojnë dy rrugët.

Ky dallim ka një pasojë që njerëzit e përshkruajnë gabimisht në të dy drejtimet. Të quash çdo paketë UDP rrjedhje injoron rregullat e bllokimit, sepse një datagram i refuzuar nuk del kurrë. Të quash të gjithë rregullimin VPN injoron rrugën direkte të lejuar, sepse një pjesë e trafikut në të vërtetë del pa përfaqësues. Ajo që keni është një pajisje e filtruar me përfaqësues të pjesshëm, dhe përshkrimi i ndershëm është një matricë, jo një etiketë.

Të reklamosh UDP nuk është ta zbatosh atë

Një server SOCKS që pretendon mbështetje UDP nuk i shton aplikacionit në telefonin tuaj trajtimin përkatës në anën e klientit. Karakteristikat teorike të protokollit dhe sjellja e ndërtimit të instaluar janë tema të ndryshme, dhe vetëm e dyta përshkruan trafikun tuaj.

Kontrolloni versionin dhe konfigurimin që ekzekutoni në të vërtetë, pastaj provoni një rrjedhë datagrami të padëmshme dhe vëzhgoni nëse shfaqet te përfaqësuesi. Çdo gjë tjetër është përfundim nga një listë veçorish, dhe listat e veçorive përshkruajnë qëllime, jo rrugë kodi.

DNS është rruga e tretë, jo një detaj

Zgjidhja e emrave i shton matricës degën e vet. Një përcjellës lokal DNS, një kërkesë UDP e zakonshme, një emër hosti destinacioni i zgjidhur nga vetë përfaqësuesi dhe një zgjidhës i kriptuar në shfletues janë katër rregullime të dallueshme. Ato ndryshojnë në atë se kush e sheh kërkesën dhe cila rrugë rrjeti e mbart atë, dhe përzierja e tyre prodhon një test që nuk provon asgjë për të tjerat.

Vendosni me vetëdije cilën dëshironi. Nëse kërkesa është që emrat të zgjidhen përmes tunelit, vetëm një rregullim i shfletuesit nuk do ta ofrojë atë, dhe një përfaqësues që zgjidh vetë emrat e hosteve ndryshon përgjigjen vetëm për lidhjet që trajton në të vërtetë.

Transporti përmes përfaqësuesit nuk është automatikisht privat

SOCKS i thjeshtë nuk është një lidhje e kriptuar nga telefoni te përfaqësuesi. Nëse pika fundore arrihet përmes një rruge tjetër të mbrojtur, emërtoni atë rrugë dhe politikën e saj të dështimit, sepse kthimi në rrjetin e hapur e kthen një rregullim privat në publik pa paralajmërim. Rëndësi ka edhe vërtetimi i vetë përfaqësuesit: një dëgjues i hapur në një pajisje të përbashkët është një shërbim për të cilin askush nuk jep llogari.

Rregullimet midis profileve meritojnë të njëjtin shqyrtim. Një VPN profili pune mbron vetëm trafikun që përdor rrugën e tij, dhe bashkëekzistenca e një muri zjarri të profilit personal me një tunel pune nuk provon se lidhja e mëtejshme e murit të zjarrit arrin atë tunel. Verifikoni arritshmërinë dhe vërtetimin në vend që të supozoni se dy profilet bashkëpunojnë.

Auditoni mbulimin me një matricë, jo me ngarkimin e një faqeje

Për një vlerësim të autorizuar, zgjidhni shembuj të padëmshëm që përfaqësojnë çdo klasë që ju intereson: TCP i kërkuar, UDP i lejuar dhe DNS në të dyja familjet e adresave. Për secilin, shënoni nëse u përfaqësua, u bllokua ose u dërgua drejtpërdrejt. Ai tabelë i vetëm është rezultati, dhe është shumë më i dobishëm sesa një pamje ekrani e një faqeje të ngarkuar.

Nëse kërkesa është që i gjithë trafiku i aplikacioneve i zgjedhur të kalojë përmes një tuneli të largët, zgjidhni një zbatim me filtrim dhe tunelizim të kombinuar të mbështetur shprehimisht. Një përbërje me vetëm përfaqësues TCP mbetet e dobishme për detyra më të ngushta, me kusht që trafiku tjetër të trajtohet me qëllim dhe jo i harruar.