Hvorfor VPN-en din bruker lengre tid på å komme seg enn utfallet

Wi-Fi kom tilbake for tretti sekunder siden, og VPN-en er fortsatt nede, så klienten ser ødelagt ut. Ofte følger den bare sin egen gjenforsøksplan, og den planen vet ikke at nettverket nettopp kom tilbake. Det gapet er hele historien: gjenopprettingstiden er utfallet pluss all ventingen klienten allerede har forpliktet seg til. Å senke hver timer er ett svar, og å forstå hvilken timer som betyr noe er det andre.

Tre forhold avgjør om justeringen hjelper: hvilket trinn som er tregt, om feilen i det hele tatt kan gjentas, og hvordan klienten får vite at nettverket er tilbake.

Tre ventetider som ser ut som én

Endepunktoppslag, IKE- eller TLS-forhandling, pakkegjenutsending og å starte et nytt forsøk er separate hendelser med separate timere. strongSwan dokumenterer gjenutsendings-backoff for IKE, og OpenVPN har egne gjenforsøkskontroller med en annen semantikk. Å kopiere et tall fra den ene til den andre forutsetter at mekanismene er like, og det er de ikke. Les loggsekvensen før du bestemmer hvilket intervall du ser på.

Et stille minutt i loggen er ikke nødvendigvis en frosset prosess. Det kan være en eksponentiell backoff som gjør nøyaktig det den er satt til.

Hvilket trinn er faktisk tregt?

Hvis loggen viser forsøk som feiler med en autentiseringsfeil, hjelper ingen timerendring, fordi påloggingsinformasjonen er feil. Hvis det ikke gjøres forsøk i det hele tatt, er klienten inne i venteperioden sin, og planen er løsningen. Hvis forsøk gjøres og går ut, er problemet tilgjengelighet eller en manglende lytter, og raskere gjenforsøk fyller bare loggen. Hver av disse tre tilstandene har en annen eier, og bare én av dem er et tidsproblem.

Klassifiser feilen før du rører et tall.

Når senking av en timer hjelper, og når den ikke gjør det

Senk taket for gjenforsøk når den dominerende kostnaden er ventingen etter et kort, hyppig utfall, som en bærbar PC som flytter seg mellom aksesspunkter. La det være når feilene er lange eller sjeldne, fordi aggressiv gjenforsøk legger til belastning akkurat i det øyeblikket konsentratoren er minst i stand til å svare. I begge tilfeller bør du endre én parameter, registrere den og måle neste gjenoppretting i stedet for å anta at den ble bedre.

En svært lav timeout kopiert inn i hver profil er den vanlige sluttilstanden av justering uten måling.

Kontroller beredskapen før du klandrer klienten

Klienten kan ofte ikke se at nettverket er brukbart før noe prøver. En innfanget portal, en DHCP-fornyelse eller en ruteendring kan la den vente på en plan som ble satt før noe av dette skjedde. Se på operativsystemets nettverkstilstandsendring og klientens neste forsøk på samme klokke, og du vil se hvem sin venting det er. Den raske versjonen er å notere tidsstempelet for nettverket-klart-hendelsen og tidsstempelet for det første forsøket etterpå.

Bekreft også at direkte trafikk fortsatt er blokkert under ventingen, fordi en raskere gjenoppkobling som lekker trafikk ikke er en forbedring.

Hva som bør registreres

Skriv ned hvilken timer som ble endret, fra hvilken verdi til hvilken, og hvordan gjenopprettingen så ut etterpå. Noter også klientversjonen, fordi standardverdier flytter seg mellom utgivelser, og en udokumentert svært lav timeout vil forvirre den neste som leser profilen.

Den registreringen gjør neste programvareoppgradering til en sammenligning i stedet for et eksperiment.