Ĉiu-aplikaĵa haltŝaltilo kontraŭ tut-aparata ŝloso: kio ŝanĝiĝas
Decidu laŭ la protektata aro, ne laŭ la etikedo: kio haltas por ekskluditaj aplikaĵoj, fonaj helpantoj kaj novaj konektoj, kaj kiel testi ĉiun kazon.
Ĉiu-aplikaĵa haltŝaltilo sonas kiel la singarda elekto: nur la labora kliento perdas sian reton kiam la tunelo falas, kaj ĉio alia daŭre funkcias. Poste iu rimarkas, ke la persona retumilo tamen ŝargis paĝon, ke la sinkroniga helpanto liverita kun la sama pako daŭre reprovis, kaj ke kaŝmemora nomo ankoraŭ solviĝis al adreso, kiu neniam tuŝis la tunelon. La etikedo sur la funkcio kaj la aro de konektoj, kiujn ĝi vere protektas, estas du malsamaj aferoj. Unue difinu la protektatan aron, ĉar tiu aro decidas, ĉu aplikaĵ-nivela plenumo aŭ tut-aparata ŝloso estas la honesta priskribo.
Komencu per la aro, ne per la etikedo
Aplikaĵ-nivela politiko protektas elektitajn aplikaĵojn. Aparata ŝloso celas pli larĝan retan limon, kutime kun dokumentitaj esceptoj por loka printado, administra trafiko aŭ kaptilaj portaloj. Neniu el la du etikedoj estas kompleta ĝis vi povos respondi tri demandojn: kio okazas al ekskluditaj aplikaĵoj, kio okazas al la helpantoj, kiujn tiuj aplikaĵoj startigas, kaj kio okazas al konektoj malfermitaj dum la protekto ne disponeblas.
Skribu tiujn respondojn antaŭ ol tuŝi klientan agordon. Se la postulo estas "ĉi tiu salajra kliento neniam rajtas paroli kun la interreto ekster la tunelo, kaj mia retumilo rajtas", la aro estas malgranda kaj aplikaĵ-nivela plenumo taŭgas. Se la postulo estas "nenio sur ĉi tiu aparato atingas la interreton senprotekta, krom la ĝisdatiga servo", neniu aplikaĵ-nivela politiko produktos tion, ĉar la aplikaĵoj, kiujn vi ne nomis, estas la problemo.
Aplikaĵ-nivela plenumo kongruas identigilojn, ne programajn nomojn
Android malkaŝas aplikaĵ-nivelan VPN per pakaĵoj, kaj ĝia dokumentaro pri VpnService priskribas, kiel tio interagas kun ĉiam-ŝalta funkciado kaj blokado. iOS agordas aplikaĵ-nivelan VPN per administra profilo kaj kongruas laŭ aplikaĵo aŭ laŭ domajno. Windows kaj Linux tute ne havas procesan vojon, do la sama ideo estas proksimumata per fajroŝirma regulo limigita al programo aŭ per regulo, kiu kongruas la posedantan uzanton.
La limo estas la identigilo, kaj identigilojn facilas preterpasi. Aplikaĵo, kiu transdonas URL al la sistema retumilo aŭ malfermas dokumenton en montrilo, transiras en proceson, kiun via politiko neniam nomis. Ankaŭ fini-ĉe-falo opcio ne estas paketa filtro: ĝi mortigas la aplikaĵon, kiun vi agordis, dum infana proceso, atendovica laboranto aŭ retumila langeto povas teni ekzistantan konektilon viva.
Ŝloso kovras tion, kion aplikaĵ-nivela politiko ne povas vidi
Tut-aparata ŝloso forigas la elekton. Ĉiu elira pakaĵo, kiu ne apartenas al la tunelo, estas forĵetata, inkluzive de trafiko de procezoj, pri kiuj via aplikaĵa politiko neniam sciis. En Android tio estas ĉiam-ŝalta VPN kombinita kun la agordo bloki konektojn, kaj la plenumo okazas en la sistemo, ne en la klienta fenestro. Sur labortablo ĝi estas daŭra fajroŝirma regulo aŭ defaŭlta vojo direktita al neatingebla enirejo.
La kosto estas, ke ĉio alia haltas, do la esceptoj fariĝas parto de la dezajno anstataŭ postpenso. Lokaj printiloj, malkovro de servoj, ensaluto al kaptilaj portaloj, administraj agentoj kaj operaciumaj ĝisdatigoj ĉiu bezonas dokumentitan truon, ĉar ĉiu estas vojo, kiu restas malferma kiam la tunelo estas malsupre. La ŝloso estas nur tiom forta kiom la plej mallonga ero sur tiu listo.
DNS, IPv6 kaj fonaj helpantoj kaŝas la likojn
Tio, ke protektata aplikaĵo malsukcesas solvi nomon, ne pruvas, ke kaŝmemoraj respondoj aŭ rekta IP-trafiko estas blokitaj. Se la solvilo ankoraŭ atingeblas ekster la tunelo, la nomo solviĝas kaj la konekto malsukcesas, kio aspektas kiel funkcianta haltŝaltilo kaj ne estas. Pli malbone, kaŝmemora rikordo povas montri al adreso, kiun la tunelo ne portas, do la konekto eliras rekte dum la aplikaĵo raportas VPN-eraron.
IPv6 bezonas sian propran regulon sur ĉiu platformo, kiu uzas ĝin, ĉar forĵeta regulo por v4 ne kovras v6-vojon. Sur poŝtelefono, agordo de privata DNS povas movi la solvadon en ĉifritan kanalon, kiun la aparata politiko ne inspektas. Kaj fonaj helpantoj estas la kutima kaŭzanto sur labortablo: ĝisdatiga aŭ sinkroniga proceseto komenciĝas antaŭ la VPN-kliento kaj tenas sian propran konekton, do ĝi neniam vidas la ŝanĝitan vojon.
Testu tri aplikaĵojn kaj du transirojn
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Rulu ĉiun vicon dufoje, unufoje kun gastigantnomo kaj unufoje kun laŭvorta adreso, kaj ankoraŭ unufoje tra IPv6 se la reto proponas tion. Sukceso signifas, ke la inkluzivita aplikaĵo haltis, la ekskludita kondutis kiel vi skribis, kaj la helpanto ne elglitis. Notu la rektan konduton, kiun vi decidis akceptebla, por ke la sekva administranto povu distingi intencan escepton de paneo.
Poste priskribu la rezulton per unu frazo, kiu nomas la aplikaĵojn kaj la kondiĉojn, ekzemple: la salajra kliento havas neniun vojon ekster la tunelo, la retumilo estas rekta laŭ dezajno, kaj ĉio alia haltas kiam la tunelo estas malsupre. Se tiu frazo estas malfacile skribebla, la politiko ankoraŭ estas du politikoj batalantaj unu kontraŭ la alia.