Hvorfor en Azure OpenVPN-tunnel faller omtrent hvert sekstiende sekund

Tunnelen fullfører håndtrykket, bærer trafikk i omtrent ett minutt og kobler deretter til på nytt. Den sekvensen utelukker den vanlige mistenkte, fordi en brannmur som blokkerer porten, ville ha stanset håndtrykket og ikke sesjonen. Det du har, er en uenighet om livlighet: den ene siden bestemte at den andre var blitt stille og rev ned en fungerende tunnel. Logglinjen sier hvilken side, og den velger rettelsen.

Les den linjen før du rører noen timer.

Myten: noe i banen blokkerer tunnelen

Hvis en port var blokkert, ville tilkoblingen feile ved starten og forbli feilet. En gjentatt syklus betyr at kontrollmeldinger flyter, at sesjoner opprettes, og at noe senere i samtalen stadig utløper. Blokkering skaper stillhet, og dette skaper en rytme.

Rytmen er det nyttige sporet. Timere skaper den; pakketap gjør det sjelden.

Les årsaken til frakoblingen før timeren

OpenVPN navngir årsaken sin, og hvert navn peker på et ulikt undersystem. Session invalidated: KEEPALIVE_TIMEOUT er en timer som utløper, så sammenlign ping- og ping-restart-verdier i begge ender. AUTH_FAILED er påloggingsinformasjon eller sertifikatstatus, og ingen timerendring hjelper. En TLS-feil betyr at partene aldri nådde keepalive-fasen.

Noter tilkoblingstiden, frakoblingstiden og om intervallet er stabilt på sekundet. Den ene målingen skiller en konfigurert tidsplan fra en tilfeldighet.

Et stabilt intervall er en timer. Et som driver, er mer sannsynlig et baneproblem eller en forskjøvet sesjon.

To keepalive-timere som aldri ble enige

Profiler eksportert fra portalen har noen ganger fortsatt linjer som keepalive eller ping-restart kopiert fra en mal for fellesskapsserver. Gatewayen kjører sin egen registrering av døde parter og håndhever sine egne forventninger, og de to tidsplanene trenger ikke å stemme. Når de er uenige, starter klienten på nytt etter en tidsplan gatewayen aldri godtok.

De to verdiene er ikke samme kontroll. ping er hvor ofte klienten sender et ekko, og ping-restart er hvor lenge den venter uten å høre noe før den river tunnelen ned. En profil med kort ping-restart og en gateway som svarer tregt, vil starte på nytt i hver stille periode, som er nøyaktig formen på en ettminutterssyklus.

Den minste endringen på klientsiden er å nøytralisere timerne på profilens øverste nivå, utenfor hver inline-blokk:

keepalive 0 0

Lagre, last profilen på nytt, koble til på nytt. En sesjon som allerede ligger i minnet, beholder de gamle verdiene, og derfor ser endringen noen ganger ut som om den ikke gjorde noe.

Sertifikatnavnet kan flytte seg under føttene dine

Azure-sertifikatautentisering avhenger av at klienten stoler på navnet gatewayen presenterer i dag. En verify-x509-name-linje i en eldre nedlasting kan feste et navn som en gjenoppbygging av gatewayen eller en sertifikatfornyelse har endret siden, og avviket viser seg som en gjentilkoblingsløkke i stedet for en klar feil. Å slette linjen gjenoppretter tilkoblingen, noe som gjør den til en god diagnose og en dårlig permanent løsning, fordi den også fjerner verifiseringen. Når tunnelen holder, gjenopprett linjen med navnet gatewayen faktisk presenterer.

Test en andre klientgenerasjon på samme maskin før du redigerer gatewayen. Hvis én klient går i løkke og den andre holder, er ikke profilen problemet.

Hva som skal endres, og i hvilken rekkefølge

Sjekk deretter for en forskjøvet sesjon. To enheter som deler ett sertifikat, kan skyve hverandre ut, og resultatet ser periodisk ut fordi begge sider fortsetter å koble til på nytt. Sammenlign punkt-til-område-sesjonspostene for samme identitet som dukker opp igjen og igjen.

Test deretter den inaktive banen ved å kjøre kontinuerlig trafikk i flere minutter. Hvis fallene stopper mens trafikken flyter, tilhører den viktige timeren en NAT-enhet eller lastbalanserer i banen og ikke OpenVPN.

Gateway-innstillinger bør først endres etter disse fire testene.