La SOCKS-reĝimo de NetGuard kovras TCP, ne ĉiun protokolon
NetGuard filtradas tra la VPN-interfaco de Android kaj povas transdoni subtenatajn konektojn al SOCKS. UDP, DNS kaj atingeblo inter profilon postulas propran revizion.
NetGuard okupas la VPN-interfacon de Android por filtri trafikon, kaj ĝi povas transdoni subtenatajn konektojn al SOCKS-finpunkto. Tiuj du faktoj ofte estas legataj kiel “la telefono estas en VPN”, konkludo, kiun la mekanismo ne subtenas. La filtro vidas pakaĵojn; la prokuro vidas nur la konektojn, kiuj estis efektive transdonitaj al ĝi. Inter tiuj du asertoj kuŝas la tuta demando pri kovrado.
La FAQ de la fonta projekto dokumentas kaj la limigon al unu servo kaj la opcion SOCKS. La ekzisto de la opcio ne estas pruvo, ke ĉiu permesita pakaĵo uzas ĝin, kaj el ĝuste tiu manko venas la demandoj pri kovrado.
Du plusendaj vojoj ene de unu aplikaĵo
La TCP-flanko de la efektivigo enhavas trakton de SOCKS-konektoj, do permesita TCP-konekto povas esti intertraktata kun la prokuro kaj portata tra ĝi. La UDP-flanko havas apartan ingo-vojon, kaj ĝia trakto de sendado kaj ricevado ne dependas de tiu TCP-intertraktado. Datagramo, kiun la filtro permesas, do povas atingi la ordinaran reton sen iam trapasi la prokuron. Nenio en tio estas difekto de la aplikaĵo; ĝi simple estas tio, kion la du vojoj efektivigas.
Tiu distingo havas konsekvencon, kiun homoj misprezentas en ambaŭ direktoj. Nomado de ĉiu UDP-pakaĵo liko ignoras la blokajn regulojn, ĉar rifuzita datagramo neniam foriras. Nomado de la tuta aranĝo VPN ignoras la permesitan rektan vojon, ĉar iom da trafiko ja foriras sen prokuro. Tio, kion vi havas, estas filtrita aparato kun parte prokura, kaj la honesta priskribo estas matrico, ne etikedo.
Anonci UDP ne estas efektivigi ĝin
SOCKS-servilo, kiu asertas subtenon de UDP, ne aldonas la respondan klientflankan trakton al la aplikaĵo en via telefono. La teoriaj trajtoj de la protokolo kaj la konduto de la instalita konstruaĵo estas malsamaj temoj, kaj nur la dua priskribas vian trafikon.
Kontrolu la version kaj agordon, kiujn vi efektive rulas, poste testu sendanĝeran datagramo-fluon kaj observu, ĉu ĝi aperas ĉe la prokuro. Ĉio alia estas konkludo el trajto-listo, kaj trajto-listoj priskribas intencojn, ne kodajn vojojn.
DNS estas tria vojo, ne detalo
Nom-rastrado aldonas sian propran branĉon al la matrico. Loka DNS-plusendilo, ordinara UDP-peto, celloka nomo solvita de la prokuro mem kaj ĉifrita solvilo en la retumilo estas kvar malsamaj aranĝoj. Ili diferencas laŭ tio, kiu vidas la peton kaj laŭ kiu retvojo portas ĝin, kaj miksado de ili produktas teston, kiu pruvas nenion pri la aliaj.
Decidu konscie, kiun vi volas. Se la postulo estas, ke nomoj solviĝu tra la tunelo, sole retumila agordo tion ne donos, kaj prokuro, kiu mem solvas gastigantajn nomojn, ŝanĝas la respondon nur por konektoj, kiujn ĝi efektive pritraktas.
La prokura transporto ne estas aŭtomate privata
Ordinara SOCKS ne estas ĉifrita ligilo de telefono al prokuro. Se la finpunkto estas atingata tra alia protektita vojo, nomu tiun vojon kaj ĝian malsukcesan politikon, ĉar refalo al la malfermita reto igas privatan aranĝon publika sen averto. Ankaŭ la propra aŭtentikigo de la prokuro gravas: malfermita aŭskultanto en kunhava aparato estas servo, pri kiu neniu respondecas.
Aranĝoj trans profilojn meritas la saman ekzamenon. VPN de labora profilo protektas nur la trafikon, kiu uzas ĝian vojon, kaj la kunekzisto de fajroŝirmilo de persona profilo kun labora tunelo ne pruvas, ke la plua konekto de la fajroŝirmilo atingas tiun tunelon. Kontrolu atingeblon kaj aŭtentikigon anstataŭ supozi, ke la du profiloj kunlaboras.
Reviziu kovradon per matrico, ne per paĝa ŝarĝo
Por rajtigita pritakso, elektu sendanĝerajn ekzemplojn, kiuj reprezentas ĉiun klason, kiu gravas al vi: postulata TCP, permesata UDP kaj DNS en ambaŭ adresaj familioj. Por ĉiu registru, ĉu ĝi estis prokurita, blokita aŭ sendita rekte. Tiu sola tabelo estas la liveraĵo, kaj ĝi estas multe pli utila ol ekrankopio de paĝo, kiu ŝargiĝis.
Se la postulo estas, ke la tuta elektita aplikaĵa trafiko trapasu malproksiman tunelon, elektu efektivigon kun eksplicite subtenata kombinita filtrado kaj tunelado. Konsisto nur kun TCP-prokuro restas utila por pli mallarĝaj taskoj, kondiĉe ke la cetera trafiko estas pritraktata intence, ne forgesita.