Wêrom jo VPN langer duorret om te herstellen as de útfal

De Wi-Fi kaam tritich sekonden lyn werom en de VPN leit noch del, sadat de klient stikken liket. Faak folget er gewoan syn eigen werpogingsskema, en dat skema wit net dat it netwurk krekt weromkaam. Dat gat is it hiele ferhaal: hersteltiid is de útfal plus alle wachttiid dêr't de klient him al oan ferbûn hat. Elk timer ferleegje is ien antwurd, en begripe hokker timer fan belang is it oare.

Trije betingsten beslute oft it ôfstimmen helpt: hokker faze stadich is, oft de flater oerhaadlik werhelle wurde kin, en hoe't de klient leart dat it netwurk werom is.

Trije wachttiden dy't op ien lykje

Einpuntresolúsje, IKE- of TLS-ûnderhanneling, pakketwerstjoering en in nije poging begjinne binne aparte barrens mei aparte timers. strongSwan dokumintearret werstjoeringsweromfal foar IKE, en OpenVPN hat syn eigen werpogingskontrôles mei oare semantyk. In getal fan de iene nei de oare kopiearje ferûnderstelt dat de meganismen oerienkomme, en dat dogge se net. Lês de logsekwinsje foardat jo beslute hokker interval jo sjogge.

In stille minút yn 'e log is net needsaaklik in beferzen proses. It kin in eksponinsjele weromfal wêze dy't krekt docht wêr't er foar ynsteld is.

Hokker faze is eins stadich?

As de log pogingen sjen lit dy't mislearje mei in autentikaasjeflater, helpt gjin timerwiksel, want de oanmeldgevens binne ferkeard. As der hielendal gjin pogingen dien wurde, sit de klient yn syn wachtfinster en is it skema de oplossing. As der pogingen dien wurde en se rinne ôf, is it probleem berikberens of in ûntbrekkende listener, en flugger werpogje makket allinnich de log fol. Elk fan dy trije tastannen hat in oare eigner, en mar ien fan har is in timingprobleem.

Klassifisearje de flater foardat jo in getal oanreitsje.

Wannear't it ferleegjen fan in timer helpt, en wannear't net

Ferleegje it werpogingsplafond as de dominante kosten it wachtsjen binne nei in koarte, faak foarkommende útfal, lykas in laptop dy't tusken tagongspunten beweecht. Lit it gewurde as flaters lang of selden binne, want agressyf werpogje foeget lading ta krekt op it stuit dat de konsintrator it minst by steat is te antwurdzjen. Fertochtsje yn beide gefallen ien parameter, registrearje dy, en mjit de folgjende herstelling ynstee fan oan te nimmen dat it better wurden is.

In tige lege tiidlimit dy't yn elk profyl kopyeare is, is de wenstige einstân fan ôfstimmen sûnder mjitting.

Kontrolearje de gereedheid foardat jo de klient de skuld jouwe

De klient kin faak net sjen dat it netwurk brûkber is oant der wat besiket. In finzen portal, in DHCP-ferfanging of in rûtewiziging kinne him wachtsje litte op in skema dat fêststeld is foardat dat alles barde. Besjoch de netwurksteastânferoaring fan it bestjoeringssysteem en de folgjende poging fan de klient op deselde klok, en jo sjogge waans wachttiid it is. De snelle ferzje is it tiidstempel fan 'e netwurk-gereed-barrens en it tiidstempel fan 'e earste poging dêrnei op te skriuwen.

Befêstigje ek dat direkte ferkear by it wachtsjen noch hieltyd blokkearre is, want in fluggere werferbining dy't ferkear lekket is gjin ferbettering.

Wat te registrearjen

Skriuw op hokker timer feroare, fan hokker wearde nei hokker, en hoe't de herstelling dernei like. Registrearje ek de ferzje fan de klient, want standertwearden ferskowe tusken útjefte en in ûndokumintearre tige lege tiidlimit sil de folgjende persoan dy't it profyl lêst yn 'e war bringe.

Dat ferslach makket de folgjende software-upgrade in ferliking ynstee fan in eksperimint.