Zakaj se vaš VPN obnavlja dlje od izpada

Wi-Fi se je vrnil pred tridesetimi sekundami, VPN pa še vedno ne deluje, zato je odjemalec videti pokvarjen. Pogosto le sledi svojemu urniku ponovitev, ta urnik pa ne ve, da se je omrežje pravkar vrnilo. Ta vrzel je cela zgodba: čas obnovitve je izpad plus kakršno koli čakanje, na katero se je odjemalec že zavezal. Znižati vsak časovnik je en odgovor, razumeti, kateri časovnik je pomemben, pa drugi.

Trije pogoji odločajo, ali prilagajanje pomaga: katera stopnja je počasna, ali je napako sploh mogoče ponoviti in kako odjemalec izve, da je omrežje nazaj.

Tri čakanja, ki so videti kot eno

Razreševanje končne točke, pogajanje IKE ali TLS, ponovno pošiljanje paketov in začetek novega poskusa so ločeni dogodki z ločenimi časovniki. strongSwan dokumentira umikanje pri ponovnem pošiljanju za IKE, in OpenVPN ima lastne kontrole ponovitev z drugačno semantiko. Kopiranje števila z enega na drugo predpostavlja, da se mehanizmi ujemajo, pa se ne. Preberite zaporedje v dnevniku, preden se odločite, na kateri interval gledate.

Tiha minuta v dnevniku ni nujno zamrznjen proces. To je lahko eksponentno umikanje, ki dela točno to, za kar je bilo nastavljeno.

Katera stopnja je v resnici počasna?

Če dnevnik kaže poskuse, ki spodletijo zaradi napake pri preverjanju pristnosti, nobena sprememba časovnika ne pomaga, ker so poverilnice napačne. Če poskusi sploh niso izvedeni, je odjemalec znotraj svojega okna čakanja in urnik je rešitev. Če so poskusi izvedeni in potečejo, je težava dosegljivost ali manjkajoči poslušalec, hitrejše ponavljanje pa le polni dnevnik. Vsako od teh treh stanj ima drugega lastnika in le eno od njih je težava s časom.

Razvrstite napako, preden se dotaknete števila.

Kdaj znižanje časovnika pomaga in kdaj ne

Znižajte zgornjo mejo ponovitev, ko so prevladujoči strošek čakanje po kratkem, pogostem izpadu, na primer pri prenosniku, ki se giblje med dostopovnimi točkami. Pustite jo pri miru, ko so napake dolge ali redke, ker agresivno ponavljanje doda obremenitev ravno v trenutku, ko koncentrator najmanj zmore odgovoriti. V obeh primerih spremenite en parameter, ga zabeležite in izmerite naslednjo obnovitev, namesto da bi domnevali, da se je izboljšala.

Zelo nizek časovni limit, kopiran v vsak profil, je običajno končno stanje prilagajanja brez merjenja.

Preverite pripravljenost, preden okrivite odjemalca

Odjemalec pogosto ne vidi, da je omrežje uporabno, dokler nekaj ne poskusi. Ujeti portal, obnovitev DHCP ali sprememba poti ga lahko pustijo čakati po urniku, nastavljenem pred vsem tem. Opazujte spremembo omrežnega stanja operacijskega sistema in naslednji poskus odjemalca na isti uri, in videli boste, čigavo je čakanje. Hitra različica je zabeležiti časovni žig dogodka omrežje-pripravljeno in časovni žig prvega poskusa za njim.

Potrdite tudi, da je neposreden promet med čakanjem še vedno blokiran, ker hitrejša ponovna povezava, ki pušča promet, ni izboljšava.

Kaj zabeležiti

Zapišite, kateri časovnik se je spremenil, s katere vrednosti na katero, in kako je bila videti obnovitev zatem. Zabeležite tudi različico odjemalca, ker se privzete vrednosti premikajo med izdajami in nedokumentiran zelo nizek časovni limit bo zmedel naslednjo osebo, ki bo prebrala profil.

Ta zapis spremeni naslednjo posodobitev programske opreme v primerjavo, ne v poskus.