J’ai testé pour vous : Stateful NAT64 avec DNS64
Mon post qui décrivait mes tests NAT64 ayant suscité beaucoup d’intérêt j’ai poursuivi les tests en ajoutant un DNS64 annoncé en DHCPv6. J’ai ensuite ajouté une borne wifi et me voilà eu bureau dans un environnement 100% IPv6!
Objectif du lab:
Mettre en oeuvre un environnement NAT64 stateful/ DNS64 et DHCPv6 complet et montrer comment il est possible très simplement de créer des ilots v6-only qui continuent d’avoir acès aux ressources sur l’internet IPv4.
Topologie:
La topologie du lab est la même que celle de mon test NAT64 précédent avec simplement l’ajout d’un serveur DNS64 et l’annonce de celui-ci via DHCPv6:
- Le préfixe IPv6 complet du réseau du lab est 2001:db8:cafe::/48
- Le préfixe IPv6 du lien 100% IPv6 est 2001:db8:cafe:100::/64. Les hosts s’auto-configurent via le mécanisme SLAAC.
- Le préfixe spécifique IPv6 (NSP – Network Specific Prefix) associé à NAT64 stateful est 2001:db8:cafe:2::/96. Une adresse IPv4 A.B.C.D est convertie en 2001:db8:cafe:2::A.B.C.D
- Le pool d’adresses IPv4 sur lesquelles sont “NATées” les adresses IPv6 ne compte qu’une seule adresse dans ce lab: 10.151.200.1
- Un serveur DNS64 qui a pour adresse: 2001:db8:cafe:200:20c:29ff:fe08:6b90
- NAT64: Routeur ASR1004
- DNS64: Serveur UCS
- NAT64: IOS-XE 3.4.0S – advanced IP services (asr1000rp1-advipservicesk9.03.04.00.S.151-3.S.bin)
- DNS64: BIND 9.8.1 sous Ubuntu 4.4.1 (pas très récent)
- Configurer le serveur pour écouter en IPv6
- Configurer le préfixe IPv6 associé à NAT64 (sur lesquelles les adresses IPv4 sont automatiquement traduite)
- Configurer un forwarder (10.30.30.30 dans notre cas). Dans le cas le plus classique, on peut imaginer qu’une entreprise ne souhaitera pas initialement faire des modifications sur ses serveurs DNS pour déployer NAT64. Il est très simple de configurer le serveur DNS64 en mode proxy: il se contentera de relayer les requêtes sur le serveur DNS officiel puis de traduire les résultats.
- Cas particulier: dans le lab qui a servi à faire les tests il n’y a pas d’accès internet IPv6. Il faut donc absolument éviter que le DNS64 retourne une adresse IPv6 globale dans le cas où le host recherché existe dans l’internet IPv6! Tout doit être natté64! Cela est fait via la ligne “exclude { ::/0; };” ci-dessous.
options {
listen-on-v6 { any; };
forwarders { 10.30.30.30; };
dns64 2001:db8:cafe:2::/96 {
exclude { ::/0; };
};
allow-query { any; };
recursion yes;
};
Rien de plus simple. Sur l’interface Gi0/0/2 sur laquelle les hosts sont présents:
interface GigabitEthernet0/0/2 description LAN V6 ONLY (NAT64) no ip address negotiation auto ipv6 address 2001:DB8:CAFE:100::1/64 ipv6 dhcp server V6ONLY nat64 enable
Et en global, il suffit de définir le profil V6ONLY:
ipv6 dhcp pool V6ONLY dns-server 2001:DB8:CAFE:200:20C:29FF:FE08:6B90 domain-name test.com
On peut faire un test simple en demandant les enregistrements A et AAAA pour www.test.com (qui n’est pas encore nativement accessible en IPv6, cad qui n’a pas d’adresse IPv6 dans le DNS).
root@dns64:~$ dig +short @127.0.0.1 -t A www.test.com 50.23.225.49 root@dns64:~$ dig +short @127.0.0.1 -t AAAA www.test.com 2001:db8:cafe:2::3217:e131
On observe que l’adresse 50.23.225.49 est bien embarquée dans l’adresse 2001:db8:cafe:2::3217:e131.
Je teste ensuite le comportement du DNS64 pour un host qui existerait dans l’internet IPv6 (www.renater.fr dans l’exemple ci-dessous)
root@dns64:~$ dig +short @10.30.30.30 -t AAAA www.renater.fr 2001:660:3001:4002::10 root@dns64:~$ dig +short @127.0.0.1 -t AAAA www.renater.fr 2001:db8:cafe:2::c131:9f0a
On observe que malgré la présence d’un enregistrement AAAA retourné par le forwarder du DN64 10.30.30.30, c’est bien l’adresse NAT64 qui est retournée grâce à la configuration “exclude { ::/0; }” de bind. Bien sûr dans l’hypothèse où un accès IPv6 existe, il faut supprimer cette exclusion pour privilégier l’accès IPv6 natif à celui NATté.
Malheureusement DHCPv6 n’est pas supporté sur MAC OS! Aussi j’ai du configurer statiquement l’adresse IPv6 du serveur et supprimer toutes les configurations IPv4. Je ne manquerai pas de revenir sur DHCPv6 dans un prochain post.
Que dire si ce n’est que tout fonctionne comme prévu sans constater de dégradation de performance? Après seulement quelques minutes de browsing la table de translation nat64 se remplit:
ASR1#sh nat64 translations
Proto Original IPv4 Translated IPv4
Translated IPv6 Original IPv6
----------------------------------------------------------------------------
tcp 144.254.231.90:993 [2001:db8:cafe:2::90fe:e75a]:993
10.151.20.1:1174 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60213
tcp 72.163.4.70:443 [2001:db8:cafe:2::48a3:446]:443
10.151.20.1:1043 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60052
tcp 74.207.254.18:80 [2001:db8:cafe:2::4acf:fe12]:80
10.151.20.1:1148 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60161
tcp 72.9.238.226:80 [2001:db8:cafe:2::4809:eee2]:80
10.151.20.1:1166 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60190
tcp 74.125.39.103:443 [2001:db8:cafe:2::4a7d:2767]:443
10.151.20.1:1172 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60209
tcp 74.125.39.147:80 [2001:db8:cafe:2::4a7d:2793]:80
10.151.20.1:1134 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60140
tcp 74.125.39.147:80 [2001:db8:cafe:2::4a7d:2793]:80
10.151.20.1:1085 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60115
tcp 72.163.4.70:443 [2001:db8:cafe:2::48a3:446]:443
10.151.20.1:1034 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60037
tcp 173.37.161.166:80 [2001:db8:cafe:2::ad25:a1a6]:80
10.151.20.1:1063 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60081
tcp 69.171.242.53:80 [2001:db8:cafe:2::45ab:f235]:80
10.151.20.1:1054 [2001:db8:cafe:100:e6ce:8fff:fe0e:30e]:60062
…
…
Total number of translations: 155
Un peu de lecture:
Stephane Bortzmeyer a réalisé 2 pages excellentes sur Stateful NAT64 et DNS64 que je vous recommande.
Tags:5 commentaires
bonjour,
Je suis assez convaincu depuis un moment par le NAT64 mais je n’ai jamais eu le temps de tester la version Cisco.
Une des forces pour moi est de pouvoir faire cela complétement à côté, par un routeur qui porterait le /96 virtuel (et des IPv4 virtuelles aussi). Ainsi, il faudrait pouvoir faire ce nat directement sur une loopback, sans faire de modifications sur les interfaces d’interconnexions.
J’ai bien tenté de faire cela et de rajouter des ip route/ipv6 route vers la loopback ensuite, mais le nat ne se fait pas.
J’ai peur que la seule solution soit de déployer du nat on a stick à base de route-map, ce qui n’est pas possible sans impacter les interfaces existantes.
Y-aurait-il une solution plus simple ?
En effet le mécanisme permet de faire le NAT où l’on veut sur le réseau: il suffit de router le /96 qui porte le NAT vers l’équipement qui fera la translation. Je tiens a souligner que l’ASR1k fait la translation en hardware: pas d’impact au niveau performance et donc moins d’intérêt à vouloir délocaliser cette fonction. Mais dans le cadre de tests ou d’un déploiement progressif il reste en effet possible de faire cette fonction sur un router “on a stick”. A priori il pourra être connecté à l’infra existante via une interface physique sur laquelle on aura par exemple configuré 2 VLANs: l’un v6-only et le second v4-v6. On activera le NAT entre les 2 sous-interfaces (pas besoin de route-maps a priori?)
Si je schématise à la IETF ca donnerait ca:
Dual stack network | | gateway IPv4 +------ 2 VLANs (IPv6 only et IPv4 only) | | | v Routeur v4 v6 ------------------ NAT64 ("porte" le /96 et fait la translation entre les 2 VLANs) | | Host v6 onlyC’est la première chose qui m’est venue en tête, il y a certainement d’autres options.
Effectivement, cela est une première solution, mais même ici, ce n’est pas forcément évident sur certains équipements qui ne seraient pas dédiés à cela, surtout durant la phase de montée en charge qui risque de durer un moment.
A vrai dire, je pensais à une architecture permettant de mutualiser la fonctionnalité de NAT64, non pas car le backbone serait en IPv4, mais dans l’optique où il n’y a plus d’IPv4 disponibles. Une sorte CGN64 où les équipements d’extrémités sont peu chers et nombreux (un routeur IPv6 simple), et un routeur en coeur faisant le NAT pour tout le monde derrière quelques IPv4, d’où l’idée d’utiliser des Loopbacks. La fonctionnalité de NAT64 pourrait alors être portée par chaque routeur opérateur de collecte par exemple.
Quelque chose qui ressemblerait à cela :
réseau dual-stack, reste du monde
|
|
gateway dualstack avec NAT64
|
|
Routeur IPv6
|
|
Host v6 only
Pourquoi ne pas utiliser Cisco Network Registar ?
Pour DNS64 ou DHCPv6 ? 🙂