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 dvije č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 dvije tvrdnje stoji cijelo 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 prosljeđivanja unutar jedne aplikacije

TCP strana implementacije sadrži obradu SOCKS veza, pa se dozvoljena TCP veza može dogovoriti s proxyjem i prenijeti 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 posljedicu koju ljudi pogrešno opisuju u oba smjera. Nazvati svaki UDP paket curenjem znači ignorisati pravila blokiranja, jer odbijeni datagram nikada ne izlazi. Nazvati cijeli aranžman VPN-om znači ignorisati dozvoljeni direktni put, jer dio saobraćaja zaista izlazi bez proxyja. Ono što imate je filtrirani uređaj s djelimič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.

Provjerite 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 namjere, a ne putanje koda.

DNS je treći put, a ne detalj

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

Svjesno odlučite koji želite. Ako je zahtjev da se imena razrješavaju kroz tunel, samo postavka preglednika to neće ispuniti, a proxy koji sam razrješava imena hostova mijenja 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 neuspjeha, jer povratak na otvorenu mrežu pretvara privatni aranžman u javni bez upozorenja. I sama autentifikacija proxyja je važna: otvoreni slušalac na dijeljenom uređaju usluga je za koju niko ne polaže račune.

Aranžmani između profila zaslužuju istu provjeru. 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. Provjerite dostupnost i autentifikaciju umjesto da pretpostavljate da dva profila sarađuju.

Revizija pokrivenosti matricom, a ne učitavanjem stranice

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

Ako je zahtjev 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 namjerno, a ne zaboravljeno.