NetGuard se SOCKS-modus dek TCP, nie elke protokol nie

NetGuard beset Android se VPN-koppelvlak om verkeer te filtreer, en dit kan ondersteunde verbindings aan ’n SOCKS-eindpunt oorhandig. Dié twee feite word dikwels gelees as “die foon is op ’n VPN”, en dit is ’n gevolgtrekking wat die meganisme nie ondersteun nie. Die filter sien pakkette; die volmag sien net die verbindings wat werklik aan hom oorhandig is. Tussen dié twee stellings lê die hele vraag van dekking.

Die opstroom-FAQ dokumenteer sowel die beperking tot een diens as die SOCKS-opsie. Die bestaan van die opsie is nie bewys dat elke toegelate pakket dit gebruik nie, en dié gaping is waar dekkingsvrae vandaan kom.

Twee aanstuurpaaie binne een app

Die TCP-kant van die implementering bevat SOCKS-verbindingshantering, so ’n toegelate TCP-verbinding kan met die volmag onderhandel word en daardeur gedra word. Die UDP-kant het ’n aparte sokpad, en sy stuur- en ontvangshantering hang nie van daardie TCP-onderhandeling af nie. ’n Datagram wat die filter toelaat, kan dus die gewone netwerk bereik sonder om ooit deur die volmag te gaan. Niks daarvan is ’n fout in die app nie; dit is bloot wat die twee paaie implementeer.

Die onderskeid het ’n gevolg wat mense in beide rigtings verkeerd stel. Om elke UDP-pakket ’n lek te noem, ignoreer die blokkadereëls, want ’n geweierde datagram verlaat nooit die toestel nie. Om die hele reëling ’n VPN te noem, ignoreer die toegelate direkte pad, want sommige verkeer verlaat wel sonder volmag. Wat jy het, is ’n gefiltreerde toestel met gedeeltelike volmag, en die eerlike beskrywing is ’n matriks eerder as ’n etiket.

Om UDP te adverteer is nie om dit te implementeer nie

’n SOCKS-bediener wat UDP-ondersteuning beweer, voeg nie die ooreenstemmende kliëntkant-hantering by die app op jou foon nie. Die protokol se teoretiese kenmerke en die gedrag van die geïnstalleerde bou is verskillende onderwerpe, en net die tweede een beskryf jou verkeer.

Kontroleer die weergawe en konfigurasie wat jy werklik hardloop, toets dan ’n onskadelike datagramvloei en kyk of dit by die volmag verskyn. Enigiets anders is afleiding uit ’n kenmerklys, en kenmerklyste beskryf bedoelings eerder as kodepaaie.

DNS is ’n derde pad, nie ’n detail nie

Naamresolusie voeg sy eie tak by die matriks. ’n Plaaslike DNS-aanstuurder, ’n gewone UDP-soektog, ’n bestemmingsgasheernaam wat die volmag self oplos en ’n geënkripteerde oplosser in die blaaier is vier verskillende reëlings. Hulle verskil in wie die navraag sien en in watter netwerkpad dit dra, en om hulle te vermeng lewer ’n toets wat niks oor die ander bewys nie.

Besluit doelbewus watter een jy wil hê. As die vereiste is dat name deur die tonnel oplos, sal ’n blaaierinstelling alleen dit nie lewer nie, en ’n volmag wat gasheername self oplos, verander die antwoord net vir verbindings wat hy werklik hanteer.

Die volmagvervoer is nie outomaties privaat nie

Gewone SOCKS is nie ’n geënkripteerde skakel van foon na volmag nie. As die eindpunt deur ’n ander beskermde pad bereik word, noem daardie pad en sy foutbeleid, want ’n terugval na die oop netwerk maak ’n private reëling sonder waarskuwing openbaar. Die volmag se eie verifikasie maak ook saak: ’n oop luisteraar op ’n gedeelde toestel is ’n diens waarvoor niemand verantwoording doen nie.

Reëlings oor profiele heen verdien dieselfde ondersoek. ’n Werkprofiel-VPN beskerm net die verkeer wat sy pad gebruik, en die gelyktydige bestaan van ’n persoonlike-profiel-firewall en ’n werktonnel bewys nie dat die firewall se verdere verbinding daardie tonnel bereik nie. Verifieer bereikbaarheid en verifikasie eerder as om aan te neem die twee profiele werk saam.

Oudit dekking met ’n matriks eerder as ’n bladsylading

Vir ’n gemagtigde evaluering, kies onskadelike voorbeelde wat elke klas verteenwoordig waaroor jy sorg: vereiste TCP, toegelate UDP en DNS in beide adresfamilies. Teken vir elkeen aan of dit deur die volmag gegaan het, geblokkeer is of direk gestuur is. Daardie enkele tabel is die lewering, en dit is baie nuttiger as ’n skermkiekie van ’n bladsy wat gelaai het.

As die vereiste is dat alle gekose toepassingsverkeer ’n afgeleë tonnel moet deurkruis, kies ’n implementering met uitdruklik ondersteunde gekombineerde filtering en tonneling. ’n Slegs-TCP-volmasamestelling bly nuttig vir smaller take, mits die ander verkeer doelbewus hanteer word eerder as vergeet.