Votre question m'a vraiment captivé, car je pourrais utiliser la même solution dans un autre réseau que je gère. J'ai expérimenté avec cela et c'est effectivement possible! (J'adore Linux...).
J'ai créé un laboratoire Netkit qui modélise votre situation. Vous pouvez télécharger le laboratoire ici (1.8 Ko).
Vous n'avez pas besoin d'installer Netkit si vous n'êtes pas intéressé par le tester sur votre machine. Vous pouvez simplement obtenir le package ci-dessus et consulter les fichiers .startup pour les différentes machines. Si vous voulez tester le laboratoire, il a besoin d'un système de fichiers avec "radvd" installé, qui n'est pas inclus dans le système de fichiers standard de Netkit. Consultez le README du package de système de fichiers pour voir comment le monter sur votre machine, puis utilisez apt-get update && apt-get install radvd.
Le laboratoire contient 6 machines: v6site (un site Internet V6 auquel vous voulez accéder), v6isp (votre Fournisseur d'Accès Internet), r1 (votre premier routeur avec connectivité V4 et V6), r2 (votre deuxième routeur qui se connecte à r1 via OpenVPN), pc1 et pc2 (machines connectées et desservies en IPv6 par r2).
J'ai utilisé la documentation du RFC 3849 comme préfixe dans l'exemple, au lieu des adresses d'exemple aléatoires que vous avez utilisées. De plus, j'ai utilisé FEC0::/96 pour les points d'extrémité OpenVPN, qui est obsolète. Dans votre déploiement, il est recommandé d'utiliser un petit préfixe de votre Adresse Unique Locale à la place.
Clarification: RFC 3849 définit le préfixe 2001:DB8::/32 à utiliser à des fins d'exemple et de documentation (pour les unicast globaux). Au lieu de choisir une adresse IPv6 aléatoire, les gens sont encouragés à utiliser des adresses dans le préfixe 2001:DB8::/32 comme un caractère générique dans des exemples qui seront remplacés par autre chose dans le déploiement réel. Dans cette question, d'abord 2001:acb:132:acb::/64, puis 2001:123:123:11a1::/64. Dans la réponse, j'ai simplement remplacé les deux par des adresses dans le préfixe de documentation. Lorsque vous appliquez la réponse à votre scénario réel, recherchez simplement chaque occurrence d'adresses 2001:DB8:: et remplacez-les par vos adresses réelles.
Les points d'extrémité des tunnels ont également besoin d'adresses. Les adresses utilisées dans les points d'extrémité des tunnels n'ont pas besoin d'être routables extérieurement, car elles ne sont utilisées qu'en interne. Vous avez utilisé des adresses commençant par FED1:: et FED2::, tandis que j'ai utilisé les adresses commençant par FECO::. Ces adresses ont été initialement définies dans RFC 3513. Elles sont l'équivalent des adresses d'utilisation privée IPv4 10.0.0.0/8, 192.168.0.0/16 et 172.16.0.0/12. En raison de problèmes, elles ont été ultérieurement abandonnées dans RFC 3879 en faveur des Adresses Uniques Locales (ULA) dans RFC 4193. Les ULA ont un préfixe "aléatoire" unique pour chaque utilisateur final. Le bénéfice est que si pour une raison quelconque vous routez entre ces réseaux, en utilisant des tunnels par exemple, ils pourront se parler sans traduction d'adresse (alors que des conflits peuvent se produire en utilisant par exemple 192.168.0.0/16). La page liée avant cette clarification vous aidera à créer votre propre préfixe ULA (et éventuellement à le enregistrer, mais ce n'est pas nécessaire de l'enregistrer).
Il n'y a pas de réel problème à utiliser des adresses locales de site comme FECx ou FEDx dans les points d'extrémité des tunnels. Ils sont obsolètes, mais cela ne les rend pas incorrects. Il est simplement recommandé d'utiliser les ULA.
La configuration globale de votre premier routeur (r1) est ci-dessous. Suivez les commentaires pour une meilleure compréhension.
# Activer le transfert pour IPv6 (entre eth0 <-> tun0)
sysctl -w net.ipv6.conf.all.forwarding=1
## Réseau interne V6 du FAI
# Comme il n'y a pas d'adresse spécifique à l'hôte, nous choisissons une adresse dans le /64
# préfixe. Notez que cette adresse est la même dans deux préfixes différents:
# ...11a1::/64 et ...11a0::/59. Cela nécessite une astuce d'interproxing dans R2.
# Idéalement, vous auriez une adresse dans le préfixe /59 à utiliser ici,
# en dehors du préfixe délégué /64.
ip link set eth0 up
ip addr add 2001:db8:1:11a1::1/59 dev eth0
ip route add default via 2001:db8:1:11a0::1 dev eth0
## Internet V4
ip link set eth1 up
ip addr add 192.168.1.1/24 dev eth1
## Tunnel OpenVPN via Internet IPv4 vers R2
# C'est la configuration la plus basique d'OpenVPN. Pas de chiffrement, pas de sécurité,
# rien du tout. NE PAS UTILISER CELA EN DEHORS DE CE LABORATOIRE.
openvpn --dev tun --tun-ipv6 --daemon
while ! ip link show tun0 2>/dev/null
do
echo "En attente de la connexion OpenVPN..."
sleep 1
done
# Configurer les points d'extrêmité OpenVPN. Choisissez un préfixe petit distinct pour les points d'extrémité
# et utilisez-le pour router le préfixe /64 vers R2.
ip link set tun0 up
ip addr add fec0::1/96 dev tun0
ip route add 2001:db8:1:11a1::/64 via fec0::2 dev tun0
La configuration globale pour le deuxième routeur (r2):
# Activer le transfert pour IPv6 (entre eth0 <-> tun0)
sysctl -w net.ipv6.conf.all.forwarding=1
## Réseau interne IPv6 de la Société
# L'adresse du routeur est arbitraire.
ip link set eth0 up
ip addr add 2001:db8:1:11a1::ffff/64 dev eth0
## Internet V4
ip link set eth1 up
ip addr add 192.168.1.2/24 dev eth1
## Tunnel OpenVPN via Internet IPv4 vers R1
# C'est la configuration la plus basique d'OpenVPN. Pas de chiffrement, pas de sécurité,
# rien du tout. NE PAS UTILISER CELA EN DEHORS DE CE LABORATOIRE.
openvpn --remote 192.168.1.1 --dev tun --tun-ipv6 --daemon
# Attendre OpenVPN...
while ! ip link show tun0 2>/dev/null
do
echo "En attente de la connexion OpenVPN..."
sleep 1
done
# Configurer les points d'extrémité OpenVPN. Voir les commentaires pour R1 ci-dessus.
# Notez que nous routons TOUT le trafic IPv6 à travers le tunnel.
ip link set tun0 up
ip addr add fec0::2/96 dev tun0
ip route add default via fec0::1 dev tun0
# L'adresse de R1 est dans notre réseau privé (eth0, voir ci-dessus), mais de l'autre
# côté du tunnel. Nous avons besoin d'une route plus spécifique spécifiquement pour cela.
# De plus, faites en sorte que ce routeur (R2) agisse comme un proxy voisin afin que d'autres
# machines sur le réseau privé puissent voir R1 à travers le tunnel.
# C'est un hack qui serait évité si nous avions un préfixe plus grand que
# /64, ou si R1 avait une adresse spécifique à l'hôte en dehors du /64.
ip route add 2001:db8:1:11a1::1/128 via fec0::1 dev tun0
ip neigh add proxy 2001:db8:1:11a1::1 dev eth0
## Démon d'annonces de routage
# REMARQUE: Le système de fichiers standard de Netkit n'a pas radvd, il doit être
# installé manuellement avec `apt-get update && apt-get install radvd` dans
# le modèle fs.
chmod 644 /etc/radvd.conf
radvd
La configuration des PC connectés à r1 (eth0) est extrêmement simple, grâce à radvd:
sysctl -w net.ipv6.conf.all.autoconf=1
ip link set eth0 up
C'est la configuration la plus importante. Les autres détails (y compris une copie de /etc/radvd.conf de r2) se trouvent dans le package de laboratoire ci-dessus.
