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 configuar 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 unico 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):
1) 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;
};
};
2) 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
3) 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
4) Levantar tayga:
/usr/local/sbin/tayga -d &
5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE
6) 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:
1) Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño :-). El routing es 100% IPv6, no hay NAT, todo normal.
2) En el supuesto que el cliente quiera acceder a una dirección IPv4:
a) El cliente clatd otorgará un socket IPv4 a la aplicación
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.
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).
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)
Anexo:
a) ping a un destino IPv4 desde el cliente:
b) Clatd ejecutándose:
c) Captura en Wireshark de un ping desde el cliente (IPv6 only) a un destino IPv4:
