OpenVPN valt weg na een DHCP-vernieuwing: houd de eindpuntroute

De tunnel verbindt, dan doodt een lease-vernieuwing op de toegangslink hem, en het logboek geeft een time-out de schuld in plaats van een route. Niets in de VPN-configuratie is veranderd, en dat is de aanwijzing: iets buiten de configuratie is veranderd. Een DHCP-gebeurtenis heeft het adres of de gateway herschreven, en de hostroute die het eindpunt van de tunnel bereikbaar hield, wijst nu naar een volgende hop die niet meer bestaat. Dit is een eigendomsprobleem voordat het een routeringsprobleem is.

Vergelijk het symptoom met de half-standaardroutes

Met redirect-gateway def1 installeert OpenVPN 0.0.0.0/1 en 128.0.0.0/1 in plaats van de standaardroute te vervangen. Samen dekken die twee de hele adresruimte, en ze verslaan 0.0.0.0/0 al op prefixlengte alleen. Daarom gaat elke bestemming zonder specifiekere match de tunnel in.

Het eindpunt heeft een uitzondering nodig. OpenVPN voegt een hostroute naar het serveradres toe via de oorspronkelijke toegangsgateway voordat de half-standaards erin gaan, zodat ingekapselde pakketten eruit kunnen. Wanneer die uitzondering verdwijnt, of een volgende hop behoudt die niet meer bestaat, matchen de eigen buitenste pakketten van de tunnel een half-standaard en worden ze terug de tunnel in gestuurd. Het resultaat is een verbinding die sterft bij de volgende keepalive of handdruk, zonder iets in het logboek dat op een routeringsfout lijkt.

Bevestig de vorm van de tabel voordat je iets anders aanraakt. ip route show hoort beide helften plus een hostroute voor het serveradres te tonen; ontbreekt de hostroute, dan heeft de rest van het onderzoek een voor de hand liggend startpunt.

Waarom de half-standaards winnen zonder metriekwijziging

Een lagere metriek verslaat geen langer prefix. De /1-routes winnen omdat de kernel eerst de meest specifieke route matcht, dus een hogere metriek op de standaardroute verandert niets aan waar verkeer richting de tunnel naartoe gaat. Metrieken najagen is de meest voorkomende verkeerde afslag in deze diagnose.

Controleer de selectie met ip route get 203.0.113.10, met het echte serveradres ingevuld. Het antwoord noemt de interface en de volgende hop die de kernel werkelijk zou gebruiken, wat informatiever is dan een tabel lezen en erover redeneren.

Voer die opdracht uit voordat de tunnel start, terwijl hij draait en na de lease-gebeurtenis. Drie antwoorden uit één opdracht, en het punt van afwijking wordt zichtbaar.

Neem drie momentopnamen, niet één

Verzamel het toegangsadres, de toegangsgateway, de bestemming van het eindpunt, de gekozen route en eventuele beleidsregels op drie momenten: nadat de toegangslink is geconfigureerd, nadat de VPN verbindt en na de lease- of providergebeurtenis. Elke momentopname is een handvol opdrachten, en ze betekenen alleen samen iets. Een enkele momentopname na de storing legt de toestand vast, niet de overgang. Schrijf de opdrachten in een klein script zodat elke momentopname op dezelfde manier wordt genomen.

Houd de momentopnamen in één bestand met tijdstempels, want de interessante vraag is later de volgorde. Kwam de DHCP-gebeurtenis voordat of nadat OpenVPN zijn route vernieuwde? Het antwoord bepaalt wie het moet repareren. Een tijdstempel van een verkeerde klok is erger dan geen, dus neem hem van de host die de routeringstabel bezit.

Wanneer het eindpunt als naam in plaats van adres is geconfigureerd, los het dan ook in elke momentopname op. Een DNS-wijziging op de toegangslink kan het eindpunt verplaatsen zonder dat er een route wordt aangeraakt.

Bepaal welke component de uitzondering vernieuwt

Op een dhcpcd-systeem draaien hooks vanuit de hook-map en vanuit de exit-hook, en de beheerdersmodus verschilt in bereik van de modus per interface. Wat de hook ook doet, hij moet idempotent zijn, want vernieuwingen kunnen in golven binnenkomen.

De betrouwbare eigenaar is de integratie die beide kanten al kent: een netwerkbeheerder die de VPN-verbinding beheert, of een unit die na het opkomen van de toegangslink is geordend. Een statische route die een hook toevoegt, werkt tot de volgende gatewaywijziging en faalt daarna op precies dezelfde manier. Als je toch een hook gebruikt, laat hem dan tijdens runtime de huidige gateway lezen in plaats van degene die je vandaag zag hard te coderen.

Leg de eigenaar vast in de configuratie. De volgende persoon die een herverbinding debugt, moet weten dat een hook, niet de VPN, verantwoordelijk is voor de uitzonderingroute.

Test de levenscyclus, niet alleen de herverbinding

Forceer een vernieuwing met dhcpcd -n eth0 of door de lease vrij te geven en opnieuw te nemen, en controleer daarna ip route get opnieuw voor het eindpunt. Doe het twee keer, want de tweede ronde vangt hooks die dubbele routes toevoegen. Herstart daarna, want persistentie is een andere eigenschap dan correctheid.

Een tunnel die een vernieuwing en een herstart overleeft, heeft een eigenaar en een werkende uitzondering. Een die alleen een handmatige herstart overleeft, heeft geen van beide, en zal falen bij de volgende gebeurtenis die je niet kunt plannen.