Waarom een Azure OpenVPN-tunnel ongeveer elke zestig seconden wegvalt
Een tunnel die elke zestig seconden wegvalt, heeft zijn handshake voltooid, dus niets blokkeert hem. Lees eerst de reden van de verbreking en vergelijk daarna beide keepalive-timers.
De tunnel voltooit zijn handshake, draagt ongeveer een minuut verkeer en verbindt daarna opnieuw. Die volgorde sluit de gebruikelijke verdachte uit, want een firewall die de poort blokkeert, zou de handshake hebben gestopt en niet de sessie. Wat je hebt, is een meningsverschil over levendigheid: de ene kant besloot dat de andere stil was geworden en brak een werkende tunnel af. De logregel zegt welke kant, en die bepaalt de oplossing.
Lees die regel voordat je een timer aanraakt.
De mythe: iets in het pad blokkeert de tunnel
Als een poort geblokkeerd was, zou de verbinding aan het begin mislukken en mislukt blijven. Een zich herhalende cyclus betekent dat controleboodschappen stromen, dat sessies tot stand komen en dat iets later in het gesprek steeds verloopt. Blokkering veroorzaakt stilte, en dit veroorzaakt een ritme.
Het ritme is de nuttige aanwijzing. Timers veroorzaken het; pakketverlies zelden.
Lees de reden van de verbreking voor de timer
OpenVPN noemt zijn reden, en elke naam wijst naar een ander subsysteem. Session invalidated: KEEPALIVE_TIMEOUT is een timer die verloopt, dus vergelijk de ping- en ping-restart-waarden aan beide kanten. AUTH_FAILED is inloggegevens of certificaatstatus, en geen enkele timerwijziging helpt. Een TLS-fout betekent dat de peers de keepalive-fase helemaal niet hebben bereikt.
Noteer de verbindingstijd, de verbrekingstijd en of het interval tot op de seconde stabiel is. Die ene meting scheidt een geconfigureerd schema van een toeval.
Een stabiel interval is een timer. Een wegdrijvend interval is eerder een padprobleem of een verschoven sessie.
Twee keepalive-timers die het nooit eens werden
Profielen die uit de portal zijn geëxporteerd bevatten soms nog regels zoals keepalive of ping-restart die uit een communityserver-sjabloon zijn gekopieerd. De gateway voert zijn eigen detectie van dode peers uit en legt zijn eigen verwachtingen op, en de twee schema's hoeven niet overeen te komen. Als ze van elkaar afwijken, start de client opnieuw volgens een schema waarmee de gateway nooit heeft ingestemd.
De twee waarden zijn niet dezelfde besturing. ping is hoe vaak de client een echo stuurt, en ping-restart is hoe lang hij wacht zonder iets te horen voordat hij de tunnel afbreekt. Een profiel met een korte ping-restart en een gateway die langzaam antwoordt, starten in elke stille periode opnieuw, wat precies de vorm van een cyclus van één minuut is.
De kleinste wijziging aan de clientkant is de timers neutraliseren op het hoogste niveau van het profiel, buiten elk inline-blok:
keepalive 0 0Opslaan, het profiel opnieuw laden, opnieuw verbinden. Een sessie die al in het geheugen zit, houdt de oude waarden, waardoor de bewerking soms lijkt alsof ze niets heeft gedaan.
De certificaatnaam kan onder je voeten wegschuiven
Azure-certificaatverificatie hangt ervan af of de client de naam vertrouwt die de gateway vandaag presenteert. Een verify-x509-name-regel in een oudere download kan een naam vastzetten die een herbouw van de gateway of een certificaatvernieuwing sindsdien heeft gewijzigd, en de mismatch verschijnt als een herverbindingslus in plaats van een duidelijke fout. De regel verwijderen herstelt de connectiviteit, wat er een goede diagnose en een slechte permanente oplossing van maakt, omdat ook de verificatie verdwijnt. Zodra de tunnel houdt, zet je de regel terug met de naam die de gateway werkelijk presenteert.
Test een tweede clientgeneratie op dezelfde machine voordat je de gateway bewerkt. Als de ene client in een lus zit en de andere houdt, is het profiel niet het probleem.
Wat je moet wijzigen, en in welke volgorde
Controleer daarna op een verschoven sessie. Twee apparaten die één certificaat delen, kunnen elkaar eruit duwen, en het resultaat lijkt periodiek omdat beide kanten opnieuw blijven verbinden. Vergelijk de punt-naar-site-sessieregistraties voor dezelfde identiteit die steeds weer opduikt.
Test daarna het inactieve pad door enkele minuten continu verkeer te laten lopen. Als de onderbrekingen stoppen terwijl het verkeer stroomt, hoort de belangrijke timer bij een NAT-apparaat of loadbalancer in het pad en niet bij OpenVPN.
Gateway-instellingen zouden pas na deze vier tests moeten veranderen.