The LACNIC Labs Blog

Introducción

El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT

Topología

Que se necesita

Del lado del cliente:

Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)

y del lado del servidor:

Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales

Configuraciones

Del lado del cliente:

En lineas generales no es necesario configurar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;

nameserver 2001:13c7:100:f101::1

IMPORTANTE: Del lado del cliente lo único que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:

#unzip clatd-master
#cd clatd-master
#./clatd

Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.

Del lado del servidor (6 pasos):

El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:

interface eth0 {
 AdvSendAdvert on;
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 prefix 2001:13c7:0100:f101::/64 { _
     AdvOnLink on;
     AdvAutonomous on;
     AdvRouterAddr on;
 };
};

Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:

En /usr/local/etc/tayga.conf:

tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1

Las interfaces del lado del servidor deben quedar así:

/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64

Levantar tayga: /usr/local/sbin/tayga -d &

Hacer NAT de la red IPv4:

_/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE_

El DNS Server debe quedar con la siguiente directiva dentro de /etc/bind/named.conf.options:
```
dns64 64:ff9b::/96 {
 clients {
     any; 
 };
};  // End of DNS64 Section
```

Un poco mas de como quedas las interfaces. La salida de ifconfig del lado del servidor

eth10      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:cc
          inet addr:10.0.3.15  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9cc/64 Scope:Link
          inet6 addr: 2001:13c7:7001:500::21/64 Scope:Global   ---> HACIA WAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42282238 errors:0 dropped:307 overruns:0 frame:0
          TX packets:11377224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5706072894 (5.7 GB)  TX bytes:2226397897 (2.2 GB)


eth9      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:d6
          inet addr:10.64.0.1  Bcast:10.64.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9d6/64 Scope:Link
          inet6 addr: 2001:13c7:100:f101::1/64 Scope:Global  --- HACIA LAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:652093 errors:0 dropped:72 overruns:0 frame:0
          TX packets:2662969 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:84197892 (84.1 MB)  TX bytes:1461857730 (1.4 GB)


nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.3.15 P-t-P:10.0.3.15  Mask:255.255.255.255
          inet6 addr: 64:ff9b::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1135938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1074859 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:939693414 (939.6 MB)  TX bytes:931853538 (931.8 MB)

Explicando todo lo anterior

Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño :-). El routing es 100% IPv6, no hay NAT, todo normal.
En el supuesto que el cliente quiera acceder a una dirección IPv4:
1. a) El cliente clatd otorgará un socket IPv4 a la aplicación
2. b) El paquete que construya el cliente será 100% IPv6. Será su dirección IPv6 origen y el destino será 64:ff9b::/96 + 32 bits de la dirección IPv4 destino. Recordemos que no hay IPv4 en el core de la red.
3. c) El PLAT (Tayga del lado del servidor) al recibir un paquete con destino 64:ff9b::/96 lo enruta por la interfaz TUN NAT64 (interfaz lógica) donde tayga remueve los primeros 96 bits del destino dejando unicamente los 32 bits menos significativos (la dirección IPv4). Al origen (IPv6) se le hace una mapeo stateless con una direccion IPv4 (del pool en el archivo de configuración (192.168.64.0/24).
4. d) Cuando el paquete con el origen 192.168.64.0/24 del servidor desee salir del equipo será nateado con iptables al IPv4 que tenga eth10 (/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE)