Ajouter de l'IPv6 privé à un labo OpenVPN, un point de contrôle à la fois

Gardez le transport extérieur en IPv4 et étendez le plan intérieur. Cinq points de contrôle : préfixes, assistant, poussée de route, transfert et un test côté client.

Vous avez déjà un client qui se connecte en IPv4 et atteint une charge de travail IPv4 privée derrière le serveur. L'objectif est d'atteindre une charge de travail IPv6 privée par le même tunnel sans toucher au transport extérieur. Cet ordre compte : le chemin extérieur reste en IPv4, et seuls le plan d'adressage intérieur, la route du client et le chemin de retour du serveur vers le LAN changent. Cinq points de contrôle, chacun avec quelque chose de concret à regarder avant d'avancer.

Point de contrôle un : la connexion qui fonctionne déjà

Connectez le client et confirmez le chemin IPv4 avant d'ajouter quoi que ce soit. Un tunnel qui fonctionne vous donne une base qui sépare une nouvelle erreur IPv6 d'un ancien problème de connectivité. Il vous dit aussi quelle instance de serveur vous modifiez réellement.

Notez le pool, la topologie et les routes poussées sur lesquelles vous comptez déjà. Le travail IPv6 étend cette configuration ; il ne la remplace pas.

Point de contrôle deux : choisissez les préfixes intérieurs

Choisissez une ULA /48 pour le site et découpez-y deux /64 : une pour les clients du tunnel, une pour le segment LAN qui porte la charge IPv6. Générez l'ID global de 40 bits plutôt que de copier un préfixe d'exemple, et vérifiez les deux sous-réseaux contre chaque réseau que le site route déjà :

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Deux /64 indépendants empêchent le pool de clients d'être découpé dans le segment LAN, ce qui comptera plus tard quand vous écrirez la route de retour. Les valeurs ci-dessus sont un exemple travaillé, pas un préfixe à réutiliser.

Point de contrôle trois : ajoutez l'assistant et la poussée de route

Lisez la configuration actuelle du serveur avant d'ajouter quoi que ce soit. Une seconde copie d'une directive existante ne fusionne pas avec la première, et l'erreur qui en résulte nomme la directive, pas IPv6. Avec l'assistant IPv4 existant, deux lignes l'étendent. Chacune répond à une question différente :

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

La première est un assistant commode qui configure l'interface et le pool de clients. La seconde nomme la destination LAN que le client doit atteindre. Attribuer une adresse IPv6 à un client ne lui dit pas quels réseaux existent derrière le serveur, donc les deux lignes sont nécessaires.

L'assistant ne coexiste pas avec un pool IPv6 statique ni avec nopool. Si le déploiement alloue délibérément des adresses de façon statique, conservez cette politique et concevez l'équivalent IPv6 explicitement au lieu de supprimer la politique pour coller à un exemple.

Point de contrôle quatre : transfert et route de réponse

Activez le transfert IPv6 sur le serveur via le propriétaire de configuration du système, pas avec une écriture d'exécution unique que vous oublierez. La forme d'exécution est utile pour un test rapide. La configuration persistante va dans un fichier drop-in que lit le propriétaire réseau de la distribution :

sysctl -w net.ipv6.conf.all.forwarding=1

Le transfert change le comportement IPv6 de l'hôte au-delà du routage des paquets. Un hôte qui acceptait les annonces de routeur comme client cesse de le faire de la même manière dès qu'il transfère. Une machine dont le lien montant IPv6 dépend des RA a donc besoin d'un plan explicite pour ce lien.

Donnez ensuite au LAN une route de retour vers le pool du tunnel. La passerelle IPv6 de la charge est le routeur du LAN, pas le serveur VPN, donc la route va sur ce routeur et pointe vers l'adresse LAN du serveur :

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Conservez les types ICMPv6 dont le lien a besoin, y compris le retour MTU de chemin. Une règle de pare-feu IPv4 n'implique pas une règle IPv6, et un blocage total d'IPv6 casse la découverte de voisins d'une manière qui ressemble à une panne de routage.

Point de contrôle cinq : lisez le client, puis testez

Reconnectez le client et lisez les adresses qu'il a réellement reçues au lieu de les déduire de l'adresse d'assistant du serveur. La liste d'interfaces montre les deux familles sur le même périphérique :

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Une route qui sélectionne le tunnel prouve que le client sait où envoyer le paquet. Elle ne prouve pas que le serveur le transfère, que le routeur du LAN a la route de retour, ni que l'application a le droit de répondre.

Testez l'application elle-même sur chaque famille tour à tour, puis répétez après une reconnexion et après un redémarrage de l'hôte. Une route ou un sysctl qui ne survit que jusqu'au redémarrage est un test, pas une conception.

Ne publiez un enregistrement AAAA que lorsque le chemin IPv6 répond de bout en bout. Un DNS interrogé en IPv4 peut encore renvoyer une adresse IPv6, donc un nom résolvable n'est pas la preuve que quelque chose écoute. Le guide RFC 4193 pour les ULA couvre la génération de l'ID global qui rend ces préfixes vôtres plutôt qu'une copie.

Articles similaires