The Poulpe.net

Dans cette troisième partie, nous allons voir comment mettre en place une technologie de transition, pour permettre à un réseau uniquement IPv6, d'acceder à un réseau IPv4. Nous utiliserons les protocoles DNS64 et NAT64.

Introduction

Un client IPv6 ne peut accéder directement à un serveur IPv4. Nous devons utiliser un mécanisme de translation entre les deux mondes. Le premier mécanisme, DNS64, permet lors de la résolution du nom DNS, de renvoyer une IPv6 fictive contenant l'IPv4 du serveur. Le second mécanisme, NAT64, permet de faire la correspondance entre l'IPv6 translatée, et l'IPv4 réelle du serveur lors de la connexion du client.

DNS64

DNS64 (RFC 6147), permet aux clients, lors de la résolution de nom, d'obtenir une réponse IPv6, même si le serveur web ne dispose que d'une IPv4. Lorsque le client émet une requête DNS de type AAAA, votre serveur interroge à son tour son serveur DNS. Si il reçoit en réponse une IPv4, il la traduit en IPv6 avec un préfixe prédéfini. Il renvoi ensuite au client cette IPv6 traduite. Si la réponse est déjà une IPv6, elle est transmise sans traduction.

Bind 9

Le célèbre service Bind9 inclus la fonctionnalité de DNS64. Nous allons voir comment l'installer et le configurer.

Dans un premier temps, il faut définir un préfixe IPv6 qui servira à construire la réponse de traduction. Il vous faut pour cela au minimum un /96. Vous pouvez utiliser le préfixe bien connu: 64:ff9b::/96 (RFC 6052) ou un préfixe ULA.

Avec ce préfixe, une adresse IPv4 (ex 217.12.3.11) sera traduite de la façon suivante:

217.12.3.11 - > 64:ff9b::217.12.3.11 -> 64:ff9b::d90c:030b

(217.12.3.11 en décimal = d90c030b en hexa)

Installation

Comme d'habitude, sur Debian c'est relativement simple:

host# aptitude install bind9

Configuration

Cela se passe dans le fichier "/etc/bind/named.conf.options":

options {
	directory "/var/cache/bind";
	dnssec-validation auto;
	auth-nxdomain no;    # conform to RFC1035
	listen-on-v6 { any; };

	dns64 64:ff9b::/96 {
		clients { any; };
	};
};

On redémarre le service:

host# service bind9 restart

On ajuste les règles de firewall IPv6 (et on redémarre le service):

Rules

#ACTION		SOURCE		DEST		PROTO	DEST PORT
?SECTION NEW

ACCEPT	lan:2001:db8:1f13:7c9::/64	$FW		tcp	22
ACCEPT	lan:2001:db8:1f13:7c9::/64	$FW		tcp	53
ACCEPT	lan:2001:db8:1f13:7c9::/64	$FW		udp	53

On test:

client# nslookup
> server 2001:db8:1f13:7c9::1
> set type=AAAA
> www.perdu.com
Server:		2001:db8:1f13:7c9::1
Address:	2001:db8:1f13:7c9::1#53

Non-authoritative answer:
www.perdu.com	has AAAA address 64:ff9b::d061:b17c

Annonce DNS avec RADVD

Nous avons un serveur DNS fonctionnel, qui permet une résolution DNS64. Nous allons maintenant l'ajouter à la configuration de RADVD, afin de permettre aux clients d'utiliser notre serveur.

"/etc/radvd.conf"

interface eth0
{
   AdvSendAdvert on;
   AdvLinkMTU 1480;
   prefix 2001:db8:1f13:7c9::/64
   {
   };
  RDNSS 2001:db8:1f13:7c9::1
   {
   };

};

et on redémarre le service:

host# service radvd restart

NAT64

NAT64 (RFC 6146) est le compagnon de DNS64. Après avoir reçu une IPv6 traduite comme réponse DNS, le client va essayer de se connecter à cette IPv6. Le serveur web ne répondant qu'en IPv4, il faut un mécanisme de translation entre les 2 protocoles. C'est le rôle de NAT64, qui va extraire l'IPv4 de l'IPv6 traduite, et accéder à cette IPv4 à la place du client. Il restransmettra ensuite la réponse du serveur web au client.

Tayga

Tayga est l'implémentation pour linux du service de translation NAT64.

Installation

Sous debian:

host# aptitude install tayga

Configuration

Editez le fichier de configuration "/etc/tayga.conf":

# Nom de l'interface de translation IPv6-IPv4, garder le nom par défaut nat64
tun-device nat64

# Adresse IPv4 du routeur Tayga, c'est une IP spécifique pour Tayga, 
# différente du réseau IP de votre serveur
ipv4-addr 192.168.255.1

# Prefixe pour le mappage IPv6, Cela doit être le même préfixe 
# que pour DNS64
prefix 64:ff9b::/96

# Plage IPv4 utilisée par Tayga pour les translations IPv4, 
# Chaque IPv6 est tranlatée sur une IPv4 de cette plage.
# Si la plage est pleine, les accès vers les nouvelles IPv6 translatées 
# sont rejetées.
dynamic-pool 192.168.255.0/24

# Répertoire de stockage des données, ne pas changer
data-dir /var/spool/tayga

Shorewall

On configure Shorewall, et Shorewall6, pour autoriser le trafic relatif à tayga

Shorewall IPv6

Shorewall6 interfaces

#ZONE	INTERFACE	OPTIONS
net     he-ipv6            tcpflags
lan	eth0		tcpflags
nat64	nat64

Shorewall6 zones

#ZONE	TYPE	OPTIONS
fw	firewall
net	ipv6
lan	ipv6
nat64	ipv6

Shorewall6 rules

ACCEPT  lan:2001:db8:1f13:7c9::/64	nat64

Shorewall IPv4

Shorewall interfaces

#ZONE	INTERFACE	BROADCAST	OPTIONS
net	eth0		detect
nat64	nat64		detect

Shorewall zones

#ZONE	TYPE		OPTIONS
fw	firewall
net	ipv4
nat64	ipv4

Shorewall rules

#ACTION		SOURCE		DEST		PROTO
ACCEPT	nat64		net

Il nous faut également masquer le réseau Tayga derrière l'interface LAN. Pour cela on ajoute une règle de NAT dynamique.

Cela se passe dans le fichier "/etc/shorewall/masq"

#INTERFACE:DEST		SOURCE		ADDRESS
eth0			192.168.255.0/24

Tests

Un test de ping vers un serveur IPv4 uniquement, doit nous retourner une adresse IPv6 lors de la résolution du nom, et doit pinger.

host# ping www.perdu.com
PING www.perdu.com (64:ff9b::d061:b17c) 56(84) bytes of data.
64 bytes from apache2-argon.william-floyd.dreamhost.com (64:ff9b::d061:b17c): icmp
64 bytes from apache2-argon.william-floyd.dreamhost.com (64:ff9b::d061:b17c): icmp