NetGuardov SOCKS način pokriva TCP, ne svaki protokol

NetGuard zauzima VPN interfejs Androida radi filtriranja saobraćaja i može predati podržane veze SOCKS odredištu. Ove dve činjenice često se čitaju kao „telefon je na VPN-u“, a to je zaključak koji mehanizam ne podržava. Filter vidi pakete; proxy vidi samo veze koje su mu zaista predate. Između te dve tvrdnje stoji celo pitanje pokrivenosti.

FAQ u izvorniku dokumentuje i ograničenje na jednu uslugu i SOCKS opciju. Postojanje opcije nije dokaz da je svaki dozvoljeni paket koristi, i upravo iz tog jaza dolaze pitanja pokrivenosti.

Dva puta prosleđivanja unutar jedne aplikacije

TCP strana implementacije sadrži obradu SOCKS veza, pa se dozvoljena TCP veza može dogovoriti s proxyjem i preneti kroz njega. UDP strana ima zaseban put soketa, a njeno rukovanje slanjem i primanjem ne zavisi od tog TCP dogovora. Zato datagram koji filter dozvoli može doći do obične mreže, a da nikada ne prođe kroz proxy. Ništa u tome nije defekt aplikacije; to je jednostavno ono što dva puta implementiraju.

Ova razlika ima posledicu koju ljudi pogrešno opisuju u oba smera. Nazvati svaki UDP paket curenjem znači ignorisati pravila blokiranja, jer odbijeni datagram nikada ne izlazi. Nazvati ceo aranžman VPN-om znači ignorisati dozvoljeni direktni put, jer deo saobraćaja zaista izlazi bez proxyja. Ono što imate je filtrirani uređaj s delimičnim proxyjem, a iskren opis je matrica, a ne oznaka.

Objavljivati UDP nije isto što i implementirati ga

SOCKS server koji tvrdi da podržava UDP ne dodaje odgovarajuću klijentsku obradu aplikaciji na vašem telefonu. Teoretske mogućnosti protokola i ponašanje instalirane verzije različite su teme, i samo druga opisuje vaš saobraćaj.

Proverite verziju i konfiguraciju koju zaista pokrećete, zatim testirajte bezopasan tok datagrama i pogledajte da li se pojavljuje na proxyju. Sve ostalo je zaključak iz liste mogućnosti, a liste mogućnosti opisuju namere, a ne putanje koda.

DNS je treći put, a ne detalj

Razrešavanje imena dodaje svoju granu matrici. Lokalni DNS prosleđivač, običan UDP upit, ime hosta odredišta koje razrešava sam proxy i šifrovani razrešavač u pregledaču četiri su različita aranžmana. Razlikuju se po tome ko vidi upit i kojim mrežnim putem se prenosi, a njihovo mešanje daje test koji ništa ne dokazuje o ostalima.

Svesno odlučite koji želite. Ako je zahtev da se imena razrešavaju kroz tunel, samo postavka pregledača to neće ispuniti, a proxy koji sam razrešava imena hostova menja odgovor samo za veze koje zaista obrađuje.

Transport kroz proxy nije automatski privatan

Običan SOCKS nije šifrovana veza od telefona do proxyja. Ako se odredište dostiže drugim zaštićenim putem, imenujte taj put i njegovu politiku neuspeha, jer povratak na otvorenu mrežu pretvara privatan aranžman u javni bez upozorenja. I sama autentifikacija proxyja je važna: otvoren slušalac na deljenom uređaju usluga je za koju niko ne polaže račune.

Aranžmani između profila zaslužuju istu proveru. VPN radnog profila štiti samo saobraćaj koji koristi njegov put, a paralelno postojanje firewall-a ličnog profila i radnog tunela ne dokazuje da dalja veza firewall-a dostiže taj tunel. Proverite dostupnost i autentifikaciju umesto da pretpostavljate da dva profila sarađuju.

Revizija pokrivenosti matricom, a ne učitavanjem stranice

Za odobrenu procenu odaberite bezopasne primere koji predstavljaju svaku klasu koja vas zanima: obavezan TCP, dozvoljen UDP i DNS u obe adresne familije. Za svaki zapišite da li je bio proksiran, blokiran ili poslat direktno. Ta jedna tabela je rezultat i mnogo je korisnija od snimka ekrana stranice koja se učitala.

Ako je zahtev da sav odabrani saobraćaj aplikacija prolazi kroz udaljeni tunel, odaberite implementaciju s izričito podržanim kombinovanim filtriranjem i tuneliranjem. Sastav samo s TCP proxyjem ostaje koristan za uže zadatke, pod uslovom da se ostali saobraćaj obrađuje namerno, a ne zaboravljeno.