Kial via VPN bezonas pli da tempo por resaniĝi ol la interrompo

La Wi-Fi revenis antaŭ tridek sekundoj kaj la VPN ankoraŭ ne funkcias, do la kliento ŝajnas difektita. Ofte ĝi simple sekvas sian propran reklopodan horaron, kaj tiu horaro ne scias, ke la reto ĵus revenis. Tiu breĉo estas la tuta historio: la resaniĝa tempo estas la interrompo plus ajna atendo, kiun la kliento jam akceptis. Malaltigi ĉiun templimigilon estas unu respondo, kaj kompreni, kiu templimigilo gravas, estas la alia.

Tri kondiĉoj decidas ĉu la agordado helpas: kiu stadio estas malrapida, ĉu la fiasko entute ripeteblas, kaj kiel la kliento ekscias, ke la reto revenis.

Tri atendoj, kiuj aspektas kiel unu

Finpunkta solvado, IKE aŭ TLS intertraktado, paketa resendo kaj komenci novan provon estas apartaj eventoj kun apartaj templimigiloj. strongSwan dokumentas resendan malantaŭiĝon por IKE, kaj OpenVPN havas siajn proprajn ripetajn regilojn kun malsama signifo. Kopii nombron de unu al la alia supozas, ke la mekanismoj kongruas, kaj ili ne kongruas. Legu la protokolan sinsekvon antaŭ ol decidi, kiun intervalon vi rigardas.

Silenta minuto en la protokolo ne nepre estas frostigita procezo. Ĝi povas esti eksponenta malantaŭiĝo faranta ĝuste tion, por kio ĝi estis agordita.

Kiu stadio fakte estas malrapida?

Se la protokolo montras provojn malsukcesantajn pro aŭtentiga eraro, neniu templimigila ŝanĝo helpas, ĉar la akreditaĵo estas malĝusta. Se provoj tute ne estas farataj, la kliento estas en sia atendfenestro kaj la horaro estas la solvo. Se provoj estas farataj kaj tempolimas, la problemo estas atingeblo aŭ mankanta aŭskultanto, kaj pli rapida ripetado nur plenigas la protokolon. Ĉiu el tiuj tri statoj havas alian posedanton, kaj nur unu el ili estas tempiga problemo.

Klasifiku la fiaskon antaŭ ol tuŝi nombron.

Kiam malaltigi templimigilon helpas, kaj kiam ne

Malaltigu la ripetan plafonon kiam la domina kosto estas atendo post mallonga, ofta interrompo, ekzemple tekkomputilo moviĝanta inter alirpunktoj. Lasu ĝin trankvila kiam la fiaskoj estas longaj aŭ maloftaj, ĉar agresema ripetado aldonas ŝarĝon ĝuste en la momento, kiam la koncentrilo plej malmulte kapablas respondi. En ambaŭ kazoj ŝanĝu unu parametron, registru ĝin, kaj mezuru la sekvan resaniĝon anstataŭ supozi, ke ĝi pliboniĝis.

Tre malalta tempolimo kopiita en ĉiun profilon estas la kutima fina stato de agordado sen mezurado.

Kontrolu pretecon antaŭ ol kulpi la klienton

La kliento ofte ne povas vidi, ke la reto estas uzebla, ĝis io provas. Kaptita portalo, DHCP-renovigo aŭ voja ŝanĝo povas lasi ĝin atendi horaron fiksitan antaŭ ol io el tio okazis. Observu la ŝanĝon de reta stato de la operaciumo kaj la sekvan provon de la kliento sur la sama horloĝo, kaj vi vidos, kies atendo ĝi estas. La rapida versio estas noti la tempostampon de la rete-prepariĝa evento kaj la tempostampon de la unua provo post ĝi.

Konfirmu ankaŭ, ke rekta trafiko ankoraŭ estas blokata dum la atendo, ĉar pli rapida rekonekto, kiu likas trafikon, ne estas plibonigo.

Kion registri

Notu, kiu templimigilo ŝanĝiĝis, de kiu valoro al kiu, kaj kiel la resaniĝo aspektis poste. Notu ankaŭ la klientan version, ĉar defaŭltoj moviĝas inter eldonoj kaj nedokumentita tre malalta tempolimo konfuzos la sekvan personon, kiu legos la profilon.

Tiu registro igas la sekvan softvaran ĝisdatigon komparo anstataŭ eksperimento.