IPv6-Ausgang stirbt nach einem OpenVPN-Neustart: Präfix-Eigentum prüfen
IPv6 stirbt, sobald der Tunnel neu erzeugt wird. Entscheiden Sie, wem das delegierte Präfix, die Client-Adressen und die Rückroute gehören, bevor Sie irgendetwas neu starten.
IPv6 hört auf, Verkehr durchzuleiten, in dem Moment, in dem OpenVPN neu startet, und IPv4 funktioniert weiter. Die Tunnel-Schnittstelle wurde neu erzeugt, und etwas anderes, das ihren IPv6-Zustand verwaltet hat, hat entweder die Adresse oder die Route verloren, die das Präfix erreichbar macht. Es sind drei getrennte Teile des Zustands beteiligt, und jeder hat einen anderen Eigentümer: das delegierte Präfix des Providers und seine Lebensdauer, die Adressen, die an VPN-Clients ausgegeben werden, und die Upstream-Route, die dieses Client-Präfix zurück zum Server schickt. Bestimmen Sie den Eigentümer jedes Teils, bevor Sie einen Daemon anfassen, denn der Neustart des falschen versteckt das Problem für einen Tag und bringt es beim nächsten Verbindungsaufbau zurück.
Drei Teile IPv6-Zustand, drei Eigentümer
| 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 |
Eine global gültige Adresse innerhalb des Tunnels reicht allein nicht aus. Upstream-Router müssen dieses Präfix trotzdem zurück zum VPN-Server schicken, und sie tun es nicht, weil der Server zufällig eine Adresse daraus hat.
Deshalb ist es auch riskant, ein öffentliches /64 in einen Tunnel-Pool zu kopieren. Ein zum Server geroutetes Präfix ist nicht dasselbe wie ein Präfix, das der Upstream als on-link behandelt, und die Nachbarsuche füllt diese Lücke nicht.
Lesen Sie den Serverzustand, bevor Sie etwas ändern
Erfassen Sie den Zustand zweimal, einmal während IPv6 funktioniert und einmal nach dem Neustart, und vergleichen Sie dann. Schreibgeschützte Ansichten genügen, und sie kosten während eines Wartungsfensters nichts:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingAchten Sie auf drei konkrete Unterschiede: eine Route, die verschwunden ist, eine Adresse, die auf eine veraltete oder ungültige Lebensdauer gewechselt ist, und ein Präfix, das sich nach erneuter Delegierung geändert hat, während die VPN-Konfiguration noch das alte ankündigt.
Ist die Adresse verschwunden, das Präfix aber unverändert, hat der zuweisende Daemon aufgehört, die Schnittstelle zu verwalten. Hat sich das Präfix geändert, die Adressen aber nicht, ist die Client-Konfiguration veraltet. Die beiden Fehler sehen im Browser gleich aus und haben nichts gemeinsam.
Entscheiden Sie, ob dhcpcd den Tunnel verwalten soll
dhcpcd kann Schnittstellen erkennen und Teile eines DHCPv6-Präfixes an nachgelagerte Schnittstellen delegieren, und seine Konfiguration kann die Delegationsziele ausdrücklich benennen. Ohne ausdrückliches Ziel kann sein dokumentiertes Verhalten andere Schnittstellen einbeziehen, und so bekommt ein Tunnel eine Adresse, die niemand geplant hat.
Zwei Bedingungen sollten Sie dazu bringen, OpenVPN die statische Adressierung des Tunnels zu überlassen: Der Server schiebt feste Adressen in seiner Konfiguration durch, und der Tunnelname ändert sich beim Wiederverbinden. Wenn beides zutrifft, schließen Sie den Tunnel bewusst vom Delegations-Daemon aus, mit einem Kommentar, der den Grund nennt.
Wenn die Delegation an den Tunnel stattdessen beabsichtigt ist, implementieren Sie die Behandlung von Präfixwechseln. Das heißt: reagieren, wenn sich das delegierte Präfix oder seine Lebensdauer ändert, das vom Server angekündigte Client-Präfix aktualisieren und die Route erneut hinzufügen. Die Schnittstelle in diesem Entwurf auszuschließen entfernt die einzige Komponente, die das neue Präfix kennt.
Ein Neustart von dhcpcd mag Dinge zu reparieren scheinen, weil er Zustand neu erzeugt, aber er erneuert oder entzieht auch Konfiguration für Schnittstellen, an die Sie nicht gedacht haben. Diese Wiederherstellung macht ihn nicht nach jedem VPN-Neustart erforderlich. Er setzt außerdem die Zähler zurück, die Sie als Beleg verwendet haben. Bevorzugen Sie ein gezieltes Neuladen der Schnittstelle, die Sie tatsächlich geändert haben.
Prüfen Sie IPv6 getrennt vom IPv4-NAT
Bestätigen Sie, dass die Weiterleitung aktiv ist und die Upstream-Route auf das tatsächliche Client-Präfix zeigt, und stellen Sie dann eine neue erlaubte IPv6-Verbindung her. Prüfen Sie auch die IPv6-Routentabelle des Clients selbst, denn ein Client, der eine öffentliche Adresse anzeigt, beweist nicht, dass seine Anfrage den Tunnel benutzt hat.
IPv4-Maskierung löst ein anderes Problem: den Rückweg für private Quellen. Für ein zurückgezogenes IPv6-Präfix bewirkt sie nichts, und ihr Hinzufügen bringt IPv6 nicht zurück.
Schließen Sie mit dem Eigentumsregister: welche Komponente das Präfix delegiert, welche Client-Adressen zuweist, welche die Rückroute hält und was bei jedem bei erneutem Verbindungsaufbau passiert. Vier Zeilen in einem Runbook ersparen der nächsten Person den Neustart von drei Daemons, um den zu finden, auf den es ankam.