Kvifor VPN-en din brukar lengre tid på å kome seg enn utfallet

Wi-Fi kom tilbake for tretti sekund sidan, og VPN-en er framleis nede, så klienten ser øydelagd ut. Ofte følgjer han berre sin eigen gjenforsøksplan, og den planen veit ikkje at nettverket nettopp kom tilbake. Det gapet er heile historia: gjenopprettingstida er utfallet pluss all ventinga klienten allereie har forplikta seg til. Å senke kvar timer er eitt svar, og å forstå kva timer som betyr noko er det andre.

Tre tilhøve avgjer om justeringa hjelper: kva trinn som er tregt, om feilen i det heile kan gjentakast, og korleis klienten får vite at nettverket er tilbake.

Tre ventetider som ser ut som éi

Endepunktoppslag, IKE- eller TLS-forhandling, pakkegjenutsending og å starte eit nytt forsøk er separate hendingar med separate timerar. strongSwan dokumenterer gjenutsendings-backoff for IKE, og OpenVPN har eigne gjenforsøkskontrollar med ei anna semantikk. Å kopiere eit tal frå den eine til den andre føreset at mekanismane er like, og det er dei ikkje. Les loggrekkja før du avgjer kva intervall du ser på.

Eit stille minutt i loggen er ikkje nødvendigvis ein frose prosess. Det kan vere ein eksponentiell backoff som gjer nøyaktig det han er sett til.

Kva trinn er faktisk tregt?

Viss loggen viser forsøk som feilar med ein autentiseringsfeil, hjelper inga timerendring, fordi påloggingsinformasjonen er feil. Viss det ikkje blir gjort forsøk i det heile, er klienten inne i venteperioden sin, og planen er løysinga. Viss forsøk blir gjorde og går ut, er problemet tilgjenge eller ein manglande lyttar, og raskare gjenforsøk fyller berre loggen. Kvar av desse tre tilstandane har ein annan eigar, og berre éin av dei er eit tidsproblem.

Klassifiser feilen før du rører eit tal.

Når senking av ein timer hjelper, og når ho ikkje gjer det

Senk taket for gjenforsøk når den dominerande kostnaden er ventinga etter eit kort, hyppig utfall, som ein berbar PC som flyttar seg mellom aksesspunkt. La det vere når feila er lange eller sjeldne, fordi aggressiv gjenforsøk legg til belastning akkurat i det augneblinken konsentratoren er minst i stand til å svare. I begge tilfelle bør du endre éin parameter, registrere han og måle neste gjenoppretting i staden for å anta at ho vart betre.

Ein særs låg timeout kopiert inn i kvar profil er den vanlege sluttilstanden av justering utan måling.

Kontroller beredskapen før du klandrar klienten

Klienten kan ofte ikkje sjå at nettverket er brukbart før noko prøver. Ein innfanga portal, ei DHCP-fornying eller ei ruteendring kan la han vente på ein plan som vart sett før noko av dette skjedde. Sjå på nettverkstilstandsendringa til operativsystemet og neste forsøk frå klienten på same klokka, og du vil sjå kven si venting det er. Den raske versjonen er å notere tidsstempelet for nettverket-klart-hendinga og tidsstempelet for det første forsøket etterpå.

Stadfest også at direkte trafikk framleis er blokkert under ventinga, fordi ei raskare gjenoppkopling som lekk trafikk ikkje er ei betring.

Kva som bør registrerast

Skriv ned kva timer som vart endra, frå kva verdi til kva, og korleis gjenopprettinga såg ut etterpå. Noter også klientversjonen, fordi standardverdiar flyttar seg mellom utgivingar, og ein udokumentert særs låg timeout vil forvirre den neste som les profilen.

Den registreringa gjer neste programvareoppgradering til ei samanlikning i staden for eit eksperiment.