Hvorfor din VPN tager længere tid om at komme sig end afbrydelsen

Wi-Fi'et kom tilbage for tredive sekunder siden, og VPN'en er stadig nede, så klienten ser ødelagt ud. Ofte følger den bare sin egen genforsøgsplan, og den plan ved ikke, at netværket lige er kommet tilbage. Det hul er hele historien: genopretningstid er afbrydelsen plus den ventetid, klienten allerede har forpligtet sig til. At sænke hver timer er ét svar, og at forstå, hvilken timer der betyder noget, er det andet.

Tre forhold afgør, om justering hjælper: hvilket trin der er langsomt, om fejlen overhovedet kan gentages, og hvordan klienten finder ud af, at netværket er tilbage.

Tre ventetider, der ligner én

Endepunktsopløsning, IKE- eller TLS-forhandling, pakkegenafsendelse og at starte et nyt forsøg er separate hændelser med separate timere. strongSwan dokumenterer genafsendelses-backoff for IKE, og OpenVPN har sine egne gentagelsesindstillinger med en anden semantik. At kopiere et tal fra den ene til den anden forudsætter, at mekanismerne er ens, og det er de ikke. Læs logsekvensen, før du beslutter, hvilket interval du ser på.

Et stille minut i loggen er ikke nødvendigvis en fastfrosset proces. Det kan være en eksponentiel backoff, der gør præcis det, den er sat til.

Hvilket trin er faktisk langsomt?

Hvis loggen viser forsøg, der fejler med en godkendelsesfejl, hjælper ingen timerændring, fordi legitimationsoplysningerne er forkerte. Hvis der slet ikke gøres forsøg, er klienten inde i sit ventevindue, og planen er løsningen. Hvis der gøres forsøg, og de udløber, er problemet nåbarhed eller en manglende lytter, og hurtigere genforsøg fylder bare loggen. Hver af disse tre tilstande har en anden ejer, og kun én af dem er et timingproblem.

Klassificér fejlen, før du rører ved et tal.

Hvornår sænkning af en timer hjælper, og hvornår den ikke gør

Sænk loftet for genforsøg, når den dominerende omkostning er ventetiden efter en kort, hyppig afbrydelse, f.eks. en bærbar computer, der flytter sig mellem adgangspunkter. Lad det være, når fejlene er lange eller sjældne, fordi aggressiv gentagelse tilføjer belastning på præcis det tidspunkt, hvor koncentratoren er mindst i stand til at svare. I begge tilfælde skal du ændre én parameter, registrere den og måle den næste genopretning i stedet for at antage, at den blev bedre.

En meget lav timeout kopieret ind i hver profil er den sædvanlige sluttilstand af justering uden måling.

Kontrollér paratheden, før du bebrejder klienten

Klienten kan ofte ikke se, at netværket er brugbart, før noget prøver. En captive portal, en DHCP-fornyelse eller en ruteændring kan efterlade den ventende på en plan, der blev sat, før noget af det skete. Hold øje med styresystemets netværkstilstand og klientens næste forsøg på samme ur, og du vil se, hvis ventetid det er. Den hurtige version er at notere tidspunktet for netværk-parat-begivenheden og tidspunktet for det første forsøg efter den.

Bekræft også, at direkte trafik stadig er blokeret under ventetiden, fordi en hurtigere genopkobling, der lækker trafik, ikke er en forbedring.

Hvad skal registreres

Skriv ned, hvilken timer der blev ændret, fra hvilken værdi til hvilken, og hvordan genopretningen så ud bagefter. Notér også klientversionen, fordi standardværdier flytter sig mellem udgivelser, og en udokumenteret meget lav timeout vil forvirre den næste person, der læser profilen.

Den registrering gør den næste softwareopgradering til en sammenligning i stedet for et eksperiment.