NetGuardov SOCKS način pokriva TCP, ne svaki protokol

NetGuard zauzima VPN sučelje Androida radi filtriranja prometa i može predati podržane veze SOCKS odredištu. Te se dvije činjenice često čitaju kao „telefon je na VPN-u“, a to je zaključak koji mehanizam ne podržava. Filtar vidi pakete; proxy vidi samo veze koje su mu doista predane. Između te dvije tvrdnje stoji cijelo pitanje pokrivenosti.

FAQ u izvorniku dokumentira i ograničenje na jednu uslugu i SOCKS opciju. Postojanje opcije nije dokaz da je svaki dopušteni 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 dopuštena TCP veza može dogovoriti s proxyjem i prenijeti kroz njega. UDP strana ima zaseban put utičnice, a njezino rukovanje slanjem i primanjem ne ovisi o tom TCP dogovoru. Zato datagram koji filtar dopusti 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 ignorirati pravila blokiranja, jer odbijeni datagram nikada ne izlazi. Nazvati cijeli raspored VPN-om znači ignorirati dopušteni izravni put, jer dio prometa doista izlazi bez proxyja. Ono što imate je filtrirani uređaj s djelomičnim proxyjem, a iskren opis je matrica, a ne oznaka.

Oglašavati UDP nije isto što i implementirati ga

SOCKS poslužitelj 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š promet.

Provjerite verziju i konfiguraciju koju doista pokrećete, zatim testirajte bezopasan tok datagrama i pogledajte pojavljuje li se na proxyju. Sve ostalo je zaključak iz popisa mogućnosti, a popisi mogućnosti opisuju namjere, a ne putanje koda.

DNS je treći put, a ne pojedinost

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 šifrirani razrješivač u pregledniku četiri su različita rasporeda. Razlikuju se po tome ko vidi upit i kojim se mrežnim putem 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, sama postavka preglednika to neće ispuniti, a proxy koji sam razrješava imena hostova mijenja odgovor samo za veze koje doista obrađuje.

Transport kroz proxy nije automatski privatan

Običan SOCKS nije šifrirana 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 raspored u javni bez upozorenja. I sama autentifikacija proxyja je važna: otvoreni slušatelj na dijeljenom uređaju usluga je za koju nitko ne polaže račune.

Rasporedi između profila zaslužuju istu provjeru. VPN radnog profila štiti samo promet koji koristi njegov put, a paralelno postojanje vatrozida osobnog profila i radnog tunela ne dokazuje da daljnja veza vatrozida dostiže taj tunel. Provjerite dostupnost i autentifikaciju umjesto da pretpostavljate da dva profila surađuju.

Revizija pokrivenosti matricom, a ne učitavanjem stranice

Za odobrenu procjenu odaberite bezopasne primjere koji predstavljaju svaku klasu koja vas zanima: obavezan TCP, dopušten UDP i DNS u obje adresne obitelji. Za svaki zapišite je li bio proksiran, blokiran ili poslan izravno. Ta jedna tablica je rezultat i mnogo je korisnija od snimke zaslona stranice koja se učitala.

Ako je zahtjev da sav odabrani promet aplikacija prolazi kroz udaljeni tunel, odaberite implementaciju s izričito podržanim kombiniranim filtriranjem i tuneliranjem. Sastav samo s TCP proxyjem ostaje koristan za uže zadatke, pod uvjetom da se ostali promet obrađuje namjerno, a ne zaboravljeno.