Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)

El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación

Construyendo una topología de red 464XLAT (mecanismo de transicion)

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: