NetGuard SOCKS režīms aptver TCP, ne katru protokolu

NetGuard aizņem Android VPN saskarni, lai filtrētu satiksmi, un var nodot atbalstītos savienojumus SOCKS galapunktam. Šie divi fakti bieži tiek lasīti kā “tālrunis ir VPN”, kas ir secinājums, ko mehānisms neatbalsta. Filtrs redz paketes; starpniekservers redz tikai tos savienojumus, kas tam faktiski tika nodoti. Starp šiem diviem apgalvojumiem atrodas viss pārklājuma jautājums.

Sākotnējā projekta BUJ dokumentē gan viena pakalpojuma ierobežojumu, gan SOCKS iespēju. Iespējas pastāvēšana nav pierādījums, ka katra atļautā pakete to izmanto, un pārklājuma jautājumi rodas tieši no šīs plaisas.

Divi pārsūtīšanas ceļi vienā lietotnē

Implementācijas TCP puse satur SOCKS savienojumu apstrādi, tāpēc atļautu TCP savienojumu var saskaņot ar starpniekserveri un pārvadāt caur to. UDP pusei ir atsevišķs ligzdas ceļš, un tās sūtīšanas un saņemšanas apstrāde nav atkarīga no šīs TCP saskaņošanas. Tāpēc datagramma, ko filtrs atļauj, var sasniegt parasto tīklu, nekad neizejot caur starpniekserveri. Nekas no tā nav lietotnes defekts; tas vienkārši ir tas, ko abi ceļi implementē.

Šai atšķirībai ir sekas, ko cilvēki abos virzienos apraksta nepareizi. Katras UDP paketes saukšana par noplūdi ignorē bloķēšanas noteikumus, jo noraidīta datagramma nekad neiziet. Visas konstrukcijas saukšana par VPN ignorē atļauto tiešo ceļu, jo daļa satiksmes tiešām iziet bez starpniekservera. Tas, kas jums ir, ir filtrēta ierīce ar daļēju starpniecību, un godīgais apraksts ir matrica, nevis etiķete.

UDP reklamēšana nav tā implementēšana

SOCKS serveris, kas apgalvo UDP atbalstu, nepievieno atbilstošo klienta puses apstrādi lietotnei jūsu tālrunī. Protokola teorētiskās īpašības un instalētās versijas uzvedība ir dažādas tēmas, un tikai otrā raksturo jūsu satiksmi.

Pārbaudiet versiju un konfigurāciju, ko jūs faktiski izmantojat, pēc tam pārbaudiet nekaitīgu datagrammu plūsmu un vērojiet, vai tā parādās starpniekserverī. Viss cits ir secinājums no funkciju saraksta, un funkciju saraksti apraksta nodomus, nevis koda ceļus.

DNS ir trešais ceļš, nevis sīkums

Nosaukumu izšķiršana pievieno matricai savu zaru. Vietējais DNS pārsūtītājs, parasts UDP vaicājums, galamērķa resursdatora nosaukums, ko izšķir pats starpniekserveris, un šifrēts atrisinātājs pārlūkā ir četras atšķirīgas konstrukcijas. Tās atšķiras ar to, kas redz vaicājumu un kurš tīkla ceļš to nes, un to sajaukšana dod testu, kas par pārējām neko nepierāda.

Apzināti izlemiet, kuru vēlaties. Ja prasība ir, lai nosaukumi tiktu izšķirti caur tuneli, vien pārlūka iestatījums to nenodrošinās, un starpniekserveris, kas pats izšķir resursdatoru nosaukumus, maina atbildi tikai tiem savienojumiem, kurus tas faktiski apstrādā.

Transportēšana caur starpniekserveri nav automātiski privāta

Vienkāršs SOCKS nav šifrēta saite no tālruņa līdz starpniekserverim. Ja galapunkts tiek sasniegts pa citu aizsargātu ceļu, nosauciet šo ceļu un tā kļūmes politiku, jo atkāpšanās uz atvērto tīklu bez brīdinājuma pārvērš privātu konstrukciju publiskā. Svarīga ir arī paša starpniekservera autentifikācija: atvērts klausītājs koplietotā ierīcē ir pakalpojums, par kuru neviens neatskaitās.

Konstrukcijas starp profiliem pelna tādu pašu pārbaudi. Darba profila VPN aizsargā tikai to satiksmi, kas izmanto tā ceļu, un personīgā profila ugunsmūra un darba tuneļa līdzāspastāvēšana nepierāda, ka ugunsmūra tālākais savienojums sasniedz šo tuneli. Pārbaudiet sasniedzamību un autentifikāciju, nevis pieņemiet, ka abi profili sadarbojas.

Auditējiet pārklājumu ar matricu, nevis ar lapas ielādi

Autorizētam novērtējumam izvēlieties nekaitīgus piemērus, kas pārstāv katru jums svarīgo klasi: nepieciešamo TCP, atļauto UDP un DNS abās adrešu saimēs. Katram pierakstiet, vai tas tika starpniekots, bloķēts vai nosūtīts tieši. Šī vienīgā tabula ir rezultāts, un tā ir daudz noderīgāka par ielādētas lapas ekrānuzņēmumu.

Ja prasība ir, lai visa izvēlētā lietojumprogrammu satiksme ietu caur attālinātu tuneli, izvēlieties implementāciju, kas skaidri atbalsta kombinētu filtrēšanu un tunelēšanu. Kompozīcija tikai ar TCP starpniekserveri joprojām ir noderīga šaurākiem uzdevumiem, ar nosacījumu, ka pārējā satiksme tiek apstrādāta apzināti, nevis aizmirsta.