Varför en Azure OpenVPN-tunnel faller ungefär var sextionde sekund

Tunneln slutför handskakningen, bär trafik i ungefär en minut och ansluter sedan igen. Den sekvensen utesluter den vanliga misstänkta, eftersom en brandvägg som blockerar porten skulle ha stoppat handskakningen och inte sessionen. Det du har är en oenighet om livskraft: ena sidan beslutade att den andra hade tystnat och rev ner en fungerande tunnel. Loggraden säger vilken sida, och den väljer åtgärden.

Läs den raden innan du rör någon timer.

Myten: något i vägen blockerar tunneln

Om en port var blockerad skulle anslutningen misslyckas i början och förbli misslyckad. En återkommande cykel betyder att kontrollmeddelanden flödar, att sessioner upprättas och att något senare i samtalet ständigt löper ut. Blockering skapar tystnad, och detta skapar en rytm.

Rytmen är den användbara ledtråden. Timers skapar den; paketförlust sällan.

Läs orsaken till frånkopplingen före timern

OpenVPN namnger sin orsak, och varje namn pekar på ett annat delsystem. Session invalidated: KEEPALIVE_TIMEOUT är en timer som löper ut, så jämför ping- och ping-restart-värdena i båda ändarna. AUTH_FAILED är inloggningsuppgifter eller certifikatstatus, och ingen timerändring hjälper. Ett TLS-fel betyder att parterna aldrig nådde keepalive-fasen.

Anteckna anslutningstiden, frånkopplingstiden och om intervallet är stabilt på sekunden. Den enda mätningen skiljer ett konfigurerat schema från en tillfällighet.

Ett stabilt intervall är en timer. Ett som driver är mer sannolikt ett vägproblem eller en förskjuten session.

Två keepalive-timers som aldrig kom överens

Profiler som exporterats från portalen innehåller ibland fortfarande rader som keepalive eller ping-restart kopierade från en mall för gemenskapsserver. Gatewayen kör sin egen identifiering av döda partners och genomdriver sina egna förväntningar, och de två schemana behöver inte stämma överens. När de är oense startar klienten om enligt ett schema som gatewayen aldrig godkände.

De två värdena är inte samma styrning. ping är hur ofta klienten skickar ett eko, och ping-restart är hur länge den väntar utan att höra något innan den river tunneln. En profil med kort ping-restart och en gateway som svarar långsamt startar om i varje tyst period, vilket är exakt formen på en enminutscykel.

Den minsta ändringen på klientsidan är att neutralisera timrarna på profilens högsta nivå, utanför varje inline-block:

keepalive 0 0

Spara, ladda om profilen, anslut igen. En session som redan ligger i minnet behåller de gamla värdena, och därför ser ändringen ibland ut som om den inte gjorde något.

Certifikatnamnet kan flytta sig under fötterna på dig

Azure-certifikatautentisering beror på att klienten litar på det namn som gatewayen presenterar i dag. En verify-x509-name-rad i en äldre nedladdning kan fästa ett namn som en ombyggnad av gatewayen eller en certifikatförnyelse har ändrat sedan dess, och avvikelsen visar sig som en återanslutningsloop i stället för ett tydligt fel. Att ta bort raden återställer anslutningen, vilket gör den till en bra diagnos och en dålig permanent åtgärd, eftersom den också tar bort verifieringen. När tunneln håller, återställ raden med det namn som gatewayen faktiskt presenterar.

Testa en andra klientgeneration på samma maskin innan du redigerar gatewayen. Om en klient loopar och den andra håller är profilen inte problemet.

Vad som ska ändras, och i vilken ordning

Kontrollera sedan en förskjuten session. Två enheter som delar ett certifikat kan knuffa ut varandra, och resultatet ser periodiskt ut eftersom båda sidor fortsätter att återansluta. Jämför punkt-till-plats-sessionsposterna för samma identitet som dyker upp igen och igen.

Testa sedan den inaktiva vägen genom att köra kontinuerlig trafik i flera minuter. Om fallen upphör medan trafiken flödar tillhör den viktiga timern en NAT-enhet eller lastbalanserare i vägen och inte OpenVPN.

Gateway-inställningar bör ändras först efter dessa fyra tester.