vpn.persistent probeer aanhou, dit hou jou nie verbind nie

NetworkManager bied een eienskap, vpn.persistent, en mense vra dit om vier verskillende vrae gelyktydig te beantwoord. Die opstroom-dokumentasie is versigtig: volharding geld wanneer die VPN-diens dit ondersteun en die profiel dit aktiveer, en die verbinding word dan gevra om skakelveranderinge en onderbrekings te oorleef tot 'n uitdruklike ontkoppeling. Dieselfde dokumentasie wys ook dat die eienskap by verstek op false staan, wat nie is wat die meeste herstelplanne aanvaar nie. Lees dit as 'n versoek om 'n poging eerder as 'n belofte van 'n resultaat.

Waartoe die instelling werklik verbind

'n Waarde wat in 'n profiel gestoor word, is 'n opdrag aan die bestuurder, en die bestuurder moet daardie opdrag aan 'n VPN-inprop gee wat weet wat om daarmee te doen. As die geïnstalleerde inprop die eienskap ignoreer, aktiveer die profiel steeds en bly die log stil, wat die ergste van beide wêrelde is vir enigiemand wat later ontfout. Niks in 'n profiel kan 'n inprop dwing om gedrag te implementeer wat dit nie het nie, so die enigste sigbare resultaat is 'n afwesigheid.

Dit is waarom die voorwaarde in die dokumentasie belangriker is as die skakelaar. Kyk watter inprop en weergawe jy werklik het, en skryf die weergawe langs die verbindingsbeskrywing sodat die volgende persoon dit nie hoef te herontdek nie. 'n Herstelbeleid wat op 'n ongeïmplementeerde vlag gebou is, misluk presies een keer in produksie en altyd op die ongerieflikste oomblik.

Om die eienskap as 'n poging te behandel, stel ook die regte verwagting vir toetsing. Jy kyk nie of die vlag gestel is nie; jy kyk of iets gebeur het toe die skakel geval het. Dit is verskillende eksperimente, en net een van hulle is 'n middag werd.

Vier vrae wat in een saamgesmelt word

Aktivering vra wat die VPN in die eerste plek opbring. 'n NetworkManager-profiel kan aan 'n basisverbinding gekoppel word, 'n apart bestuurde OpenVPN-diens besit sy eie opstart, en om 'n derde lanseerder by daardie reëling te voeg, gee jou twee eienaars met verskillende idees oor wie in beheer is. Besluit watter komponent die opstart besit voordat jy nog 'n sneller byvoeg.

Herstel vra wat gebeur wanneer die skakel verander of verdwyn, wat die eng vraag is wat vpn.persistent aanspreek. Lewendigheid vra of die kliënt kan sien dat die ander kant opgehou antwoord het, en OpenVPN se keepalive- of herbegin-gedrag beantwoord daardie een eerder; die twee meganismes word dikwels met dieselfde woord beskryf en op verskillende plekke geïmplementeer. Toets hulle apart, met verskillende gereedskap, of jy sal een gedrag aan die ander toeskryf.

Bedoeling vra of herverbinding hoegenaamd verlang word, en dit is die vraag wat statuspeiling nie kan beantwoord nie. 'n Doelbewuste stop en 'n onderbreking lewer dieselfde onaktiewe toestand, so enigiets wat op afwesigheid herverbind, raai oor 'n menslike besluit. Raai is goed tot op die oomblik dat dit iemand oorheers.

'n Kontrolelys wat hulle apart hou

Voer die gebeure in volgorde uit eerder as om die konfigurasie te lees en daaroor te redeneer, en teken op wat elkeen wys met 'n tydstempel.

Eerstens, aktiveer die beoogde basisverbinding en bevestig dat die VPN opgekom het deur die sneller wat jy verwag het eerder as deur 'n meganisme wat jy vergeet het geïnstalleer is. Tweedens, tydens 'n goedgekeurde onderbreking, vergelyk die bestuurder se VPN-gebeurtenisse, die eienaar-kliënt se hersteltoestand en 'n nuwe versoek na 'n privaat hulpbron. Derdens, ontkoppel doelbewus, wag, en bevestig dat niks die profiel agter jou rug herbegin nie.

Die derde stap is die een wat mense oorslaan, en dit is die een wat die werklike fout die meeste vind. 'n Waghonde wat vir 'n aktiewe profiel peil en herverbind wanneer dit afwesig is, sal 'n gebruiker se opsetlike ontkoppeling vrolik ongedaan maak. Vanuit die gebruiker se stoel is dit nie veerkrag nie; dit is 'n masjien wat nie sal gehoorsaam nie. Vra hulle voordat jy een byvoeg.

Skryf die resultate in dieselfde dokument as die verbindingsbeskrywing. 'n Herstelbeleid is net so goed soos die laaste keer wat iemand dit doelbewus sien misluk het. Tydstempels maak die verskil sigbaar vir wie die notas volgende lees.

Verifikasie is deel van herstel

Herverbinding is nie suiwer 'n netwerkhandeling nie. As die goedgekeurde vloei 'n nuwe uitdaging, 'n eenmalige kode, of 'n geheim wat die aktiveringskonteks nie kan bereik nie nodig het, kan geen volhardingsinstelling dit uit niks voortbring nie.

Dit verduidelik 'n bekende patroon: die verbinding herstel op 'n masjien met 'n ontslote sleutelring en misluk op dieselfde masjien na 'n herbegin. Die netwerklaag het presies gedoen wat gevra is en die geloofsbrieflaag het niks gehad om te bied nie.

Maak die geloofsbrief-werkvloei reg in plaas daarvan om die herprobeer-interval te verkort. Vinniger herprobeerpogings teen 'n opdrag wat niemand kan beantwoord nie, skep loggeraas en 'n valse indruk dat iets probeer word.

Volharding is nie 'n doodskakelaar nie

Die eienskap probeer die VPN-verhouding behou of herstel. Dit besluit nie wat toepassings mag doen terwyl die VPN af is nie, en dit blokkeer niks op sigself nie.

As die vereiste is dat geen verkeer buite die tonnel mag uitgaan nie, is dit 'n aparte beleid met sy eie meganisme, sy eie toetsing en sy eie foutmodusse. Om te aanvaar dat volharding dit dek, verander 'n veiligheidsbesluit in 'n ongeluk.

Teken albei helftes in die herstelnotas aan: wat die VPN probeer het, en watter toepassingverkeer toegelaat is terwyl die poging aan die gang was.