IPv6-egress sterft na een herstart van OpenVPN: controleer het eigenaarschap van het prefix

IPv6 stopt met het doorgeven van verkeer op het moment dat OpenVPN opnieuw start, en IPv4 blijft werken. De tunnelinterface is opnieuw gemaakt, en iets anders dat de IPv6-status ervan beheerde, is het adres kwijt of de route kwijt die het prefix bereikbaar maakt. Er zijn drie afzonderlijke stukken status in het spel, en elk heeft een andere eigenaar: het gedelegeerde prefix van de provider en de levensduur ervan, de adressen die aan VPN-clients worden gegeven, en de upstreambroute die dat clientprefix terug naar de server stuurt. Identificeer de eigenaar van elk stuk voordat u een daemon aanraakt, want de verkeerde herstarten verbergt het probleem een dag en brengt het terug bij de volgende verbinding.

Drie stukken IPv6-status, drie eigenaren

Een adres met globale scope binnen de tunnel is op zichzelf niet genoeg. Upstreamrouters moeten dat prefix nog steeds terug naar de VPN-server sturen, en ze doen dat niet omdat de server toevallig een adres ervan heeft.

Daarom is het ook riskant om een openbaar /64 in een tunnelpool te kopiëren. Een prefix dat naar de server wordt gerouteerd is niet hetzelfde als een prefix dat de upstream als on-link behandelt, en buurontdekking vult die leemte niet.

Lees de status van de server voordat u iets verandert

Leg de status twee keer vast, één keer terwijl IPv6 werkt en één keer na de herstart, en vergelijk daarna. Alleen-lezen-weergaven zijn genoeg, en ze kosten niets tijdens een onderhoudsvenster:

ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwarding

Let op drie specifieke verschillen: een route die verdwenen is, een adres dat naar een verouderde of ongeldige levensduur is gegaan, en een prefix dat na herdelegatie is veranderd terwijl de VPN-configuratie nog het oude aankondigt.

Als het adres verdwenen is maar het prefix ongewijzigd, is de daemon die het toewijst gestopt met het beheren van de interface. Als het prefix veranderd is maar de adressen niet, is de clientconfiguratie verouderd. De twee storingen zien er in een browser identiek uit en hebben niets gemeen.

Bepaal of dhcpcd de tunnel moet beheren

dhcpcd kan interfaces ontdekken en delen van een DHCPv6-prefix aan downstreaminterfaces delegeren, en de configuratie kan de delegatiedoelen expliciet benoemen. Zonder expliciet doel kan het gedocumenteerde gedrag andere interfaces betrekken, en zo krijgt een tunnel een adres dat niemand had gepland.

Twee voorwaarden zouden u ertoe moeten brengen OpenVPN de statische adressering van de tunnel te laten bezitten: de server duwt vaste adressen in zijn configuratie, en de tunnelsnaam verandert bij het opnieuw verbinden. Als beide gelden, sluit de tunnel dan bewust uit van de delegatiedaemon, met een opmerking die zegt waarom.

Als delegatie naar de tunnel juist opzettelijk is, implementeer dan de afhandeling van prefixwijzigingen. Dat betekent reageren wanneer het gedelegeerde prefix of de levensduur verandert, het door de server aangekondigde clientprefix bijwerken, en de route opnieuw toevoegen. De interface in dat ontwerp uitsluiten verwijdert de enige component die het nieuwe prefix kent.

Een herstart van dhcpcd lijkt misschien dingen te verhelpen omdat het status opnieuw maakt, maar het vernieuwt of trekt ook configuratie in voor interfaces waar u niet aan dacht. Die herstelling maakt het geen vereiste na elke VPN-herstart. Het zet ook de tellers terug die u als bewijs gebruikte. Geef de voorkeur aan een gerichte herlaad van de interface die u werkelijk hebt gewijzigd.

Valideer IPv6 apart van IPv4 NAT

Bevestig dat doorsturen is ingeschakeld en dat de upstreamroute naar het werkelijke clientprefix wijst, en maak dan een nieuwe toegestane IPv6-verbinding. Controleer ook de eigen IPv6-routetabel van de client, want een client die een openbaar adres toont, bewijst niet dat zijn verzoek de tunnel gebruikte.

IPv4-masquerading lost een ander probleem op: de retourweg voor private bronnen. Het doet niets voor een ingetrokken IPv6-prefix, en het toevoegen ervan brengt IPv6 niet terug.

Sluit af met het eigenaarsregister: welke component het prefix delegeert, welke clientadressen toewijst, welke de retourroute houdt, en wat er bij elk gebeurt bij het opnieuw verbinden. Vier regels in een runbook besparen de volgende persoon drie daemons te herstarten om die ene te vinden die ertoe deed.