vpn.persistent daŭre provas, sed ne tenas vin konektita

NetworkManager prezentas unu econ, vpn.persistent, kaj homoj petas ĝin respondi kvar malsamajn demandojn samtempe. Ĝia dokumentaro estas zorgema: daŭreco validas kiam la VPN-servo subtenas ĝin kaj la profilo ebligas ĝin, kaj tiam la konekto estas petata postvivi ligajn ŝanĝojn kaj interrompojn ĝis eksplicita malkonekto. La sama dokumentaro ankaŭ montras, ke la eco defaŭlte estas false, kio ne estas tio, kion supozas plej multaj restarigaj planoj. Legu ĝin kiel peton pri provo, ne kiel promeson pri rezulto.

Kion la agordo efektive devigas

Valoro konservita en profilo estas instrukcio al la administranto, kaj la administranto devas transdoni tiun instrukcion al VPN-kromprogramo, kiu scias, kion fari kun ĝi. Se la instalita kromprogramo ignoras la econ, la profilo tamen aktiviĝas kaj la protokolo restas silenta, kio estas la plej malbona el ambaŭ mondoj por iu ajn, kiu poste sencimigos. Nenio en profilo povas devigi kromprogramon efektivigi konduton, kiun ĝi ne havas, do la sola videbla rezulto estas manko.

Tial la kondiĉo en la dokumentaro pli gravas ol la ŝaltilo. Kontrolu, kiun kromprogramon kaj eldonon vi efektive havas, kaj skribu la version apud la priskribo de la konekto, por ke la sekva persono ne devu retrovii ĝin. Restariga politiko konstruita sur neefektivigita flago malsukcesas precize unufoje en produkto kaj ĉiam en la plej maloportuna momento.

Trakti la econ kiel provon ankaŭ starigas la ĝustan atendo por testado. Vi ne kontrolas, ĉu la flago estas agordita; vi kontrolas, ĉu io okazis, kiam la ligo falis. Tiuj estas malsamaj eksperimentoj, kaj nur unu el ili valoras posttagmezon.

Kvar demandoj kunfanditaj en unu

Aktivigo demandas, kio unue levas la VPN-on. NetworkManager-profilo povas esti ligita al baza konekto, aparte administrata OpenVPN-servo posedas sian propran starton, kaj aldoni trian lanĉilon al tiu aranĝo donas al vi du posedantojn kun malsamaj ideoj pri tio, kiu regas. Decidu, kiu komponanto posedas la starton, antaŭ ol aldoni alian ellasilon.

Restarigo demandas, kio okazas, kiam la ligo ŝanĝiĝas aŭ malaperas, kaj tio estas la mallarĝa demando, kiun vpn.persistent traktas. Viveco demandas, ĉu la kliento povas scii, ke la fora fino ĉesis respondi, kaj anstataŭe la keepalive aŭ restartiga konduto de OpenVPN respondas al tio; la du mekanismoj ofte estas priskribitaj per la sama vorto kaj efektivigitaj en malsamaj lokoj. Testu ilin aparte, per malsamaj iloj, aŭ vi atribuos unu konduton al la alia.

Intenco demandas, ĉu rekonekto entute estas dezirata, kaj tio estas la demando, kiun statusa enketado ne povas respondi. Intenca haltigo kaj paneo produktas la saman neaktivan staton, do io ajn, kio rekonektas pro manko, divenas pri homa decido. Divenado estas en ordo ĝis la momento, kiam ĝi preterpasas iun.

Kontrola listo, kiu tenas ilin aparte

Plenumu la okazaĵojn laŭvice anstataŭ legi la agordon kaj rezonadi pri ĝi, kaj registru, kion ĉiu montras, kun tempindiko.

Unue, aktivigu la celitan bazan konekton kaj konfirmu, ke la VPN leviĝis per la ellasilo, kiun vi atendis, kaj ne per mekanismo, kiun vi forgesis esti instalita. Due, dum aprobita interrompo, komparu la VPN-okazaĵojn de la administranto, la restarigan staton de la posedanta kliento kaj novan peton al privata rimedo. Trie, malkonektu intence, atendu, kaj konfirmu, ke nenio restartigas la profilon malantaŭ vi.

La tria paŝo estas tiu, kiun homoj preterlasas, kaj ĝi plej ofte trovas la realan difekton. Gardisto, kiu enketas pri aktiva profilo kaj rekonektas, kiam ĝi mankas, ĝoje nuligos la intencan malkonekton de uzanto. El la seĝo de la uzanto tio ne estas rezistkapablo; ĝi estas maŝino, kiu ne obeos. Demandu ilin antaŭ ol aldoni unu.

Skribu la rezultojn en la saman dokumenton kiel la priskribo de la konekto. Restariga politiko estas nur tiom bona, kiom la lasta fojo, kiam iu vidis ĝin intence malsukcesi. Tempindikoj faras la diferencon videbla por ĉiu, kiu legos la notojn poste.

Aŭtentigo estas parto de la restarigo

Rekonekti ne estas pure reta ago. Se la aprobita fluo bezonas novan defion, unufojan kodon aŭ sekreton, kiun la aktiviga kunteksto ne povas atingi, neniu daŭreca agordo povas produkti ĝin el nenio.

Tio klarigas konatan ŝablonon: la konekto restariĝas sur maŝino kun malŝlosita ŝlosilaro kaj malsukcesas sur la sama maŝino post restarto. La reta tavolo faris precize tion, kio estis petita, kaj la legitimila tavolo havis nenion por proponi.

Riparu la legitimilan laborfluon anstataŭ mallongigi la reprovan intervalon. Pli rapidaj reprovoj kontraŭ instigo, kiun neniu povas respondi, kreas protokolan bruon kaj falsan impreson, ke io estas provata.

Daŭreco ne estas kill switch

La eco provas konservi aŭ restarigi la VPN-rilaton. Ĝi ne decidas, kion rajtas fari aplikaĵoj dum la VPN estas malŝaltita, kaj ĝi mem blokas nenion.

Se la postulo estas, ke neniu trafiko eliru ekster la tunelon, tio estas aparta politiko kun propra mekanismo, propra testado kaj propraj malsukcesaj reĝimoj. Supozi, ke daŭreco kovras tion, transformas sekurecan decidon en akcidenton.

Registru ambaŭ duonojn en la restarigaj notoj: kion la VPN provis, kaj kiu aplikaĵa trafiko estis permesita dum la provo daŭris.