La mito estas, ke fail-closed estas la sekura agordo kaj fail-open la neglektema. Ambaŭ priskribas, kio okazas al trafiko post kiam la tunelo malaperis, kaj nek unu ŝanĝas kiom bone tiu tunelo ĉifras. Fail-closed-politiko kun longa listo de esceptoj povas liki pli ol fail-open-politiko sur aparato, kiu neniam forlasas la oficejan reton. Elektu la rezulton, kiun vi povas klarigi al la persono, kiu posedas la trafikon.

La etikedo priskribas rezulton, ne forton

La vortprovizo venas el regadsistemoj: fail-open permesas funkciadon kiam komponanto paneas, fail-closed rifuzas ĝin. Aplikite al VPN, la paneanta komponanto estas la tunelo, kaj la demando estas ĉu la trafiko rajtas daŭri per alia vojo. Elekti ĉifron, ŝlosilan longon kaj protokolon estas apartaj decidoj.

La konfuzo restas ĉar ĉesigilo sonas kiel sekureca funkcio, kaj vendistoj merkatas ĝin tiel. Mekanike ĝi estas enkursiga kaj fajroŝirma regulo, kiu blokas trafikon, kiun la tunelo devintus porti, realigita en la kliento, en la operaciumo aŭ sur la enirejo. Kiu ajn tavolo plenumas ĝin, tiu ankaŭ difinas ĝian amplekson, kaj regulo en unu tavolo ne kovras alian. Regulo sur la enirejo ne povas protekti tekkomputilon, kiu jam transiris al alia reto.

Kiel aspektas ĉiu rezulto

La sama politiko povas konduti tre malsame depende de tio, kiun paneon vi trafas, do komparu la okazaĵojn, ne la etikedojn.

EventFail-open resultFail-closed result
Tunnel drops while a transfer runsTransfer continues on the direct pathTransfer stalls until the tunnel returns
Client exits or crashesRules disappear with the processRules persist only if the OS owns them
Device boots before sign-inNormal network accessBlocked until the VPN connects
Captive portal neededPortal loads normallyPortal unreachable without an exception
IPv6 not carried by the tunnelIPv6 traffic leaks directlyLeaks too, unless the block covers IPv6

La lasta vico kaptas tiujn, kiuj supozas, ke ĉesigilo estas unu sola ŝaltilo. Regulo skribita por la IPv4-enkursiga tabelo lasas la defaŭltan IPv6-vojon netuŝita, kaj la aplikaĵo povas ĝoje uzi ĝin.

La amplekso decidas ĉu ĝi likas

Demandu, kion la politiko kovras, antaŭ ol demandi kiun reĝimon ĝi estas. Regulo por unu aplikaĵo protektas unu aplikaĵon kaj nenion alian, regulo por la tuta aparato protektas ĉion krom la esceptoj, kaj regulo sur la enirejo protektas nur trafikon, kiu atingas tiun enirejon. DNS bezonas propran decidon, ĉar peto sendita al loka solvilo povas malkaŝi nomojn eĉ kiam la ŝarĝo estas blokita.

Esceptoj por la loka reto ekzistas por printiloj, elsendado kaj kaptitaj portaloj, kaj ĉiu el ili estas truo en la blokado. Dokumentu ilin apud la politiko, ĉar la persono, kiu heredos la agordon, alie legos fail-closed kiel absolutan.

Rekonektiĝo kaj blokado ankaŭ estas apartaj regiloj. Kliento povas aŭtomate rekonektiĝi sen iam bloki, aŭ bloki sen rekonektiĝi, kaj la kombinaĵo difinas, kion uzanto spertas dum interrompo.

Pruvu ĝin dum transiro

Testi la stabilan staton pruvas nenion. Intence faligu la tunelon kaj provu la aplikaĵon, kiu devus esti protektita, poste kontrolu ĉu ĝi atingis la reton. Komparu la indikilon de la kliento kun la rezulto, ĉar indikilo, kiu ankoraŭ diras konektita, estas ĝuste tiu kazo, por kiu la politiko ekzistas. Se la protektita aplikaĵo sukcesas, la nomo de la reĝimo ne gravas; vi havas likon.

Ripetu de malvarma starto antaŭ ensaluto, dum ŝanĝo de Wi-Fi al poŝtelefona reto kaj kun la protektita aplikaĵo en la fono. Se la blokadon plenumas la klienta procezo, testu ankaŭ kio okazas, kiam tiu procezo estas mortigita anstataŭ ordinare fermita.

Fine, kontrolu la purigan vojon. Se kliento malinstaliĝas dum ĝiaj reguloj estas aktivaj, uzu la dokumentitan forigproceduron de la vendisto anstataŭ malŝalti la fajroŝirmilon de la operaciumo, kiu forigas nerilatan protekton sen respondi, al kiu apartenas la restinta regulo.

Rilataj artikoloj