La sortie IPv6 tombe après un redémarrage d’OpenVPN : vérifiez à qui appartient le préfixe

IPv6 cesse de faire passer le trafic à l’instant où OpenVPN redémarre, et IPv4 continue de fonctionner. L’interface du tunnel a été recréée, et autre chose qui gérait son état IPv6 a perdu soit l’adresse, soit la route qui rend le préfixe joignable. Trois morceaux d’état distincts sont en jeu, et chacun a un propriétaire différent : le préfixe délégué du fournisseur et sa durée de vie, les adresses remises aux clients VPN, et la route amont qui renvoie ce préfixe client vers le serveur. Identifiez le propriétaire de chacun avant de toucher à un démon, car redémarrer le mauvais masque le problème pendant un jour et le fait revenir à la prochaine reconnexion.

Trois morceaux d’état IPv6, trois propriétaires

Une adresse de portée globale à l’intérieur du tunnel ne suffit pas à elle seule. Les routeurs amont doivent toujours renvoyer ce préfixe vers le serveur VPN, et ils ne le feront pas parce que le serveur détient par hasard une adresse qui en provient.

C’est aussi pourquoi copier un /64 public dans un pool de tunnel est risqué. Un préfixe routé vers le serveur n’est pas la même chose qu’un préfixe que l’amont traite comme on-link, et la découverte de voisins ne comblera pas cet écart.

Lisez l’état du serveur avant de changer quoi que ce soit

Capturez l’état deux fois, une fois pendant qu’IPv6 fonctionne et une fois après le redémarrage, puis comparez. Les vues en lecture seule suffisent, et elles ne coûtent rien pendant une fenêtre de maintenance :

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

Cherchez trois différences précises : une route qui a disparu, une adresse passée à une durée de vie obsolète ou invalide, et un préfixe qui a changé après une redélégation alors que la configuration VPN annonce encore l’ancien.

Si l’adresse a disparu mais que le préfixe est inchangé, le démon qui l’attribue a cessé de gérer l’interface. Si le préfixe a changé mais pas les adresses, la configuration du client est périmée. Les deux pannes se ressemblent depuis un navigateur et n’ont rien en commun.

Décidez si dhcpcd doit gérer le tunnel

dhcpcd peut découvrir des interfaces et déléguer des parties d’un préfixe DHCPv6 à des interfaces aval, et sa configuration peut nommer explicitement les cibles de délégation. Sans cible explicite, son comportement documenté peut impliquer d’autres interfaces, et c’est ainsi qu’un tunnel finit avec une adresse que personne n’avait prévue.

Deux conditions devraient vous pousser à laisser OpenVPN posséder l’adressage statique du tunnel : le serveur pousse des adresses fixes dans sa configuration, et le nom du tunnel change à la reconnexion. Si les deux se vérifient, excluez le tunnel du démon de délégation délibérément, avec un commentaire qui explique pourquoi.

Si la délégation vers le tunnel est au contraire délibérée, mettez en œuvre la gestion du changement de préfixe. Cela signifie réagir quand le préfixe délégué ou sa durée de vie change, mettre à jour le préfixe client annoncé par le serveur, et rajouter la route. Exclure l’interface dans cette conception supprime le seul composant qui connaît le nouveau préfixe.

Redémarrer dhcpcd peut sembler arranger les choses parce que cela recrée l’état, mais cela renouvelle aussi ou retire la configuration d’interfaces auxquelles vous ne pensiez pas. Ce rétablissement n’en fait pas une obligation après chaque redémarrage de VPN. Cela remet aussi à zéro les compteurs que vous utilisiez comme preuve. Préférez un rechargement ciblé de l’interface que vous avez réellement modifiée.

Validez IPv6 séparément du NAT IPv4

Confirmez que le transfert est activé et que la route amont pointe vers le préfixe client réel, puis établissez une nouvelle connexion IPv6 autorisée. Vérifiez aussi la table de routage IPv6 du client lui-même, car un client qui affiche une adresse publique ne prouve pas que sa requête a utilisé le tunnel.

Le masquage IPv4 résout un autre problème : le chemin de retour pour les sources privées. Il ne fait rien pour un préfixe IPv6 retiré, et l’ajouter ne fera pas revenir IPv6.

Terminez par le registre de propriété : quel composant délègue le préfixe, lequel attribue les adresses des clients, lequel détient la route de retour, et ce qui arrive à chacun à la reconnexion. Quatre lignes dans un runbook évitent à la personne suivante de redémarrer trois démons pour trouver celui qui comptait.