De ce VPN-ul tău se recuperează mai lent decât căderea

Wi-Fi a revenit acum treizeci de secunde, iar VPN-ul este încă picat, așa că clientul pare stricat. Deseori urmează doar propriul program de reîncercări, iar acel program nu știe că rețeaua tocmai a revenit. Această diferență este toată povestea: timpul de recuperare este căderea plus orice așteptare pe care clientul a acceptat-o deja. Să reduci fiecare temporizator este un răspuns, iar să înțelegi care temporizator contează este celălalt.

Trei condiții decid dacă reglajul ajută: care etapă este lentă, dacă eșecul este deloc repetabil și cum află clientul că rețeaua a revenit.

Trei așteptări care par una singură

Rezolvarea punctului final, negocierea IKE sau TLS, retransmiterea pachetelor și începerea unei noi încercări sunt evenimente separate cu temporizatoare separate. strongSwan documentează retragerea retransmiterii pentru IKE, iar OpenVPN are propriile controale de reîncercare cu o semantică diferită. Copierea unui număr de la unul la altul presupune că mecanismele coincid, iar ele nu coincid. Citiți secvența jurnalului înainte de a decide la ce interval vă uitați.

Un minut liniștit în jurnal nu este neapărat un proces înghețat. Poate fi o retragere exponențială care face exact ce a fost configurată să facă.

Care etapă este de fapt lentă?

Dacă jurnalul arată încercări care eșuează cu o eroare de autentificare, nicio schimbare de temporizator nu ajută, pentru că acreditările sunt greșite. Dacă nu se fac deloc încercări, clientul este în fereastra sa de așteptare, iar programul este soluția. Dacă se fac încercări și acestea expiră, problema este accesibilitatea sau un ascultător lipsă, iar reîncercarea mai rapidă doar umple jurnalul. Fiecare dintre aceste trei stări are alt proprietar, și doar una dintre ele este o problemă de sincronizare.

Clasificați eșecul înainte de a atinge un număr.

Când reducerea unui temporizator ajută și când nu

Reduceți plafonul reîncercărilor când costul dominant este așteptarea după o cădere scurtă și frecventă, cum ar fi un laptop care se mută între puncte de acces. Lăsați-l în pace când eșecurile sunt lungi sau rare, pentru că reîncercarea agresivă adaugă sarcină exact în momentul în care concentratorul este cel mai puțin capabil să răspundă. În ambele cazuri, schimbați un parametru, notați-l și măsurați următoarea recuperare în loc să presupuneți că s-a îmbunătățit.

Un timeout foarte mic copiat în fiecare profil este starea finală obișnuită a reglajului fără măsurători.

Verificați disponibilitatea înainte de a da vina pe client

Clientul adesea nu poate vedea că rețeaua este utilizabilă până când ceva nu încearcă. Un portal captiv, o reînnoire DHCP sau o schimbare de rută îl pot lăsa să aștepte un program stabilit înainte ca toate acestea să se întâmple. Urmăriți schimbarea stării rețelei sistemului de operare și următoarea încercare a clientului pe același ceas, și veți vedea a cui este așteptarea. Versiunea rapidă este să notați marca temporală a evenimentului rețea-pregătită și marca temporală a primei încercări după el.

Confirmați și că traficul direct este încă blocat în timpul așteptării, pentru că o reconectare mai rapidă care scurge trafic nu este o îmbunătățire.

Ce să notați

Notați care temporizator s-a schimbat, de la ce valoare la ce valoare, și cum a arătat recuperarea după aceea. Notați și versiunea clientului, pentru că valorile implicite se mută între versiuni și un timeout foarte mic nedocumentat va încurca următoarea persoană care citește profilul.

Acea notă transformă următoarea actualizare de software într-o comparație, nu într-un experiment.