Préfixe de branche IPv6 : iroute-ipv6 ou route-ipv6 sur le serveur ?

Deux directives au nom presque identique apparaissent dans chaque exemple qui fonctionne, et copier l’une sans l’autre produit un tunnel qui semble correct et abandonne silencieusement le préfixe de branche. Elles font un travail différent de part et d’autre d’une même frontière : l’une apprend au noyau du serveur où vit un préfixe, et l’autre apprend à OpenVPN quel client authentifié le porte. Si les deux sont correctes, le préfixe circule ; si une seule l’est, les paquets ont une route mais pas de propriétaire.

Deux directives, deux travaux différents

route-ipv6 est une installation de route ordinaire : le serveur ajoute une route de noyau qui pointe le préfixe vers son interface de tunnel. iroute-ipv6 appartient à un contexte propre à un client et déclare une propriété interne, de sorte que le démon sait que le trafic de ce préfixe doit aller vers un client particulier plutôt que vers le pair qu’une route de noyau nomme par hasard.

L’une concerne la table de transfert du noyau, l’autre le modèle de routage interne du démon. Les garder séparées explique pourquoi une configuration qui paraît complète peut encore abandonner le préfixe. Cela explique aussi pourquoi le même réseau apparaît deux fois dans chaque exemple qui fonctionne. Aucune des deux lignes n’est redondante.

Dans l’installation userspace traditionnelle, les deux sont nécessaires et elles se complètent. Une route de noyau seule laisse le démon incapable de choisir un pair. Une iroute seule laisse le noyau sans chemin vers le tunnel. C’est aussi de là que vient l’essentiel de la confusion sur les fichiers par client : le fichier n’est pas une entrée de table de routage, et l’entrée de route n’est pas une déclaration de propriété.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Où chacune va

La route va dans la configuration gérée du serveur, où elle s’applique à ce processus serveur. L’iroute va dans le fichier propre au client, nommé d’après l’identité authentifiée de l’équipement de branche.

Un nom de fichier qui ne correspond pas à l’identité effective n’est jamais lu, et le symptôme est identique à une iroute manquante. Vérifiez l’identité que le serveur a authentifiée, puis vérifiez le nom de fichier caractère par caractère.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Gardez le pool et le préfixe de branche distincts, car les faire se chevaucher crée une énigme qu’aucune directive ne peut résoudre.

Ce dont un autre client a besoin

Un second client qui doit atteindre cette branche a besoin d’une annonce, pas d’une propriété. Poussez le préfixe vers les clients voulus, dans le contexte client ou groupe qui convient à votre configuration.

Ne l’envoyez pas à la branche elle-même, car cet équipement possède déjà le préfixe comme réseau connecté.

L’envoyer à tout le monde est un choix avec des conséquences : chaque client croit alors que la branche est joignable par le tunnel, y compris des clients à qui vous n’avez jamais voulu accorder cet accès. Une annonce est en pratique une décision d’accès, même si la directive ressemble à de la plomberie. La référence des options serveur documente iroute-ipv6 comme une propriété propre au client, et c’est la distinction qu’il vaut la peine de conserver.

Le chemin de retour sur l’équipement de branche

La propriété n’aide que si la branche transmet les paquets et si son LAN sait répondre. Activez le transfert IPv6 sur l’équipement de branche, et confirmez que les hôtes de son LAN renvoient le trafic du pool VPN vers la branche plutôt que vers une route par défaut qui ne connaît pas le pool.

Ce chemin de retour est l’équivalent IPv6 du problème de route manquante que les gens rencontrent avec IPv4.

Vérifiez-le depuis un hôte du LAN avec une résolution de l’adresse du pool VPN, pas depuis la branche elle-même. Une résolution faite sur le routeur répond à une autre question que celle de vos utilisateurs, et les deux sont assez souvent en désaccord pour que la commande supplémentaire en vaille la peine.

Quand le couple ne suffit toujours pas

Certains déploiements n’utilisent pas du tout ce chemin. Le chemin de données du noyau et les serveurs gérés par le produit ont leur propre gestion de routes prise en charge, et un exemple userspace peut ne pas se transposer directement.

Confirmez quel chemin de données votre build utilise avant de copier des directives d’un tutoriel écrit pour l’autre.

Enfin, rappelez-vous la portée des adresses : un préfixe local unique comme fd00:7a::/64 est privé par conception et ne dit rien de la joignabilité IPv6 publique. Traitez-le comme un accès interne, et gardez la sortie internet comme une question distincte avec sa propre politique.