IPv6-utgången dör efter en omstart av OpenVPN: kontrollera vem som äger prefixet
IPv6 dör när tunneln återskapas. Bestäm vem som äger det delegerade prefixet, klientadresserna och returvägen innan du startar om något.
IPv6 slutar föra trafik i samma ögonblick som OpenVPN startar om, och IPv4 fortsätter att fungera. Tunnelns gränssnitt återskapades, och något annat som hanterade dess IPv6-tillstånd förlorade antingen adressen eller rutten som gör prefixet nåbart. Tre separata delar av tillståndet är inblandade, och var och en har en annan ägare: leverantörens delegerade prefix och dess livslängd, adresserna som ges till VPN-klienter, och den uppströms rutt som skickar klientprefixet tillbaka till servern. Identifiera ägaren till varje del innan du rör någon daemon, för att starta om fel en döljer problemet i en dag och tar tillbaka det vid nästa anslutning.
Tre delar IPv6-tillstånd, tre ägare
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
En adress med global omfattning inne i tunneln räcker inte i sig. Uppströms routrar måste fortfarande skicka prefixet tillbaka mot VPN-servern, och de gör det inte bara för att servern råkar ha en adress från det.
Därför är det också riskabelt att kopiera ett publikt /64 till en tunnelpool. Ett prefix som routas till servern är inte samma sak som ett prefix som uppströmssidan behandlar som on-link, och grannupptäckt fyller inte igen den luckan.
Läs serverns tillstånd innan du ändrar något
Fånga tillståndet två gånger, en gång medan IPv6 fungerar och en gång efter omstarten, och jämför sedan. Skrivskyddade vyer räcker, och de kostar ingenting under ett underhållsfönster:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingLeta efter tre konkreta skillnader: en rutt som försvann, en adress som flyttades till en föråldrad eller ogiltig livslängd, och ett prefix som ändrades efter ny delegering medan VPN-konfigurationen fortfarande annonserar det gamla.
Om adressen försvann men prefixet är oförändrat har daemonen som tilldelar den slutat hantera gränssnittet. Om prefixet ändrades men inte adresserna är klientkonfigurationen föråldrad. De två felen ser identiska ut från en webbläsare och har ingenting gemensamt.
Bestäm om dhcpcd ska hantera tunneln
dhcpcd kan upptäcka gränssnitt och delegera delar av ett DHCPv6-prefix till nedströms gränssnitt, och dess konfiguration kan namnge delegeringsmålen explicit. Utan ett explicit mål kan dess dokumenterade beteende involvera andra gränssnitt, och det är så en tunnel hamnar med en adress som ingen hade planerat.
Två villkor bör driva dig mot att låta OpenVPN äga tunnelns statiska adressering: servern skjuter in fasta adresser i sin konfiguration, och tunnelnamnet ändras vid återanslutning. Om båda gäller, uteslut tunneln från delegeringsdaemonen med avsikt, med en kommentar som säger varför.
Om delegering till tunneln i stället är avsiktlig, implementera hanteringen av prefixändringar. Det innebär att reagera när det delegerade prefixet eller dess livslängd ändras, uppdatera serverns annonserade klientprefix och lägga tillbaka rutten. Att utesluta gränssnittet i den designen tar bort den enda komponent som känner till det nya prefixet.
En omstart av dhcpcd kan se ut att fixa saker eftersom den återskapar tillstånd, men den förnyar eller drar också tillbaka konfiguration för gränssnitt du inte tänkte på. Den återställningen gör det inte till ett krav efter varje VPN-omstart. Den nollställer också räknarna du använde som bevis. Föredra en riktad omladdning av det gränssnitt du faktiskt ändrade.
Validera IPv6 separat från IPv4 NAT
Bekräfta att vidarebefordran är aktiverad och att uppströmsrutten pekar på det faktiska klientprefixet, och gör sedan en ny tillåten IPv6-anslutning. Kontrollera också klientens egen IPv6-routingtabell, eftersom en klient som visar en offentlig adress inte bevisar att dess begäran använde tunneln.
IPv4-maskering löser ett annat problem: returvägen för privata källor. Den gör ingenting för ett återkallat IPv6-prefix, och att lägga till den tar inte tillbaka IPv6.
Avsluta med ägarregistret: vilken komponent som delegerar prefixet, vilken som tilldelar klientadresser, vilken som håller returvägen, och vad som händer med var och en vid återanslutning. Fyra rader i en runbook sparar nästa person från att starta om tre daemoner för att hitta den som spelade roll.