viernes, 10 de abril de 2015

Notas sobre la forma de hacer nateo respecto a rutas

Este post será dentro de poco algo obsoleto, en cuanto el nateo será una técnica inútil cuando IPv6 termine su despliegue, sin embargo, aprovecho a subir estas notas porque en ningún lugar hacen bien excepto aquí
De este esquema hablo
¿Podría este esquema acceder a un FTP en Sucursal?
Totalmente, siempre y cuando entre el Firewall y y Sucursal no se este nateando el tráfico desde LAN, ya que estamos nateando el tráfico de LAN en Firewall, lo que haría un segundo nateo (Nadie en sus cabales lo haría, pero yo no estaba en mis cabales el día que jugué con una configuración de ese tipo )

Rutas
En una configuración de primer o segundo caso completas, es necesario configurar rutas para especificar cual es el gateway que deben usar para llegar a tal ruta, y en consecuencia, que interfaz física han de buscar para salir. (Si bien se haya configurado la ip en una interfaz virtual, lo importante es la física sobre la que esa interfaz virtual trabaja)

Las interfaces virtuales son un chiste dentro de la configuración de iptables
Es bastante común que se configure la interfaz hacia DMZ (Central + Sucursal) como una interfaz virtual respecto a la interfaz hacia internet.

En ese caso, iptables toma en cuenta la interfaz fisica debido a que es lo que la configuración de rutas toma en cuenta.

Para ejemplo: Habiendo configurado como rutas adicionales
route add -net  192.168.10.0 gw 172.16.2.1
route add -net  192.168.83.0 gw 172.16.2.1
route add -net  192.168.85.0 gw 172.16.2.1
route add -net  192.168.87.0 gw 172.16.2.1
Y estando configurada 172.16.2.1 sobre una interfaz virtual eth0:1, las rutas para el sistema deberían aparecer de la siguiente forma
root@firewall:~# route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.25   0.0.0.0         UG    0      0        0 eth0
10.10.20.0      172.16.2.1      255.255.255.0   UG    0      0        0 eth0
10.20.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.30.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth2
172.16.2.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.83.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0
192.168.85.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0
192.168.87.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0
Hice un experimento para demostrarme lo anterior, y no es del todo complicado una vez que se entiende lo hasta ahora expuesto, pero como yo no lo entendía casi me mata
 Imagínemos que hemos configurado firewall, y que tenemos acceso a nebula, que es un equipo que se encuentra entre Firewall y DMZ (Central + Sucursal). En la vida real, este es un proveedor de enlaces, pero el experimento va de configurar un equipo cualquiera como nebula con apenas forwarding de paquetes y un par de reglas en la cadena POSTROUTING en la tabla nat de iptables

Cuando Firewall muestra esto:
root@firewall:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    3   189 ACCEPT     all  --  *      eth0    10.20.20.0/24        10.10.20.0/24        /* Vamos hacia DMZ */
    3   180 MASQUERADE  all  --  *      eth0    10.20.20.0/24        0.0.0.0/0            match-set rwa dst /* Vamos hacia RWA */
    0     0 MASQUERADE  all  --  *      eth0    10.20.20.0/24        0.0.0.0/0            /* Vamos hacia Internet */
Nebula nebula dice estar nateando de esta manera:
root@nebula:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 5 packets, 1058 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    3   189 MASQUERADE  all  --  *      br0     10.20.20.0/24        0.0.0.0/0          
    3   180 MASQUERADE  all  --  *      br0     172.16.2.0/24        0.0.0.0/0  
Cuando el destino desde la red $LAN era 10.10.20.0, #firewall no lo natea en realidad, por tanto llega a #nebula con su ip original como se puede ver, y hace coincidencia en la regla esperada para tal fin, en el ejemplo la primera
Luego, cuando el destino eran los grupos en rwa, (que de hecho incluyen a 10.10.20.0/24, pero al anteponer la regla anterior en el orden de iptables nunca llegará a este punto) #firewall nateo con salida en la interfaz eth0, pero hay que fijarse en eth0
root@firewall:~# ip addr show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:de:78:a8 brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.15/24 brd 172.16.2.255 scope global eth0:1
    inet 192.168.10.15/27 brd 192.168.10.31 scope global eth0
    inet6 fe80::5054:ff:fede:78a8/64 scope link
       valid_lft forever preferred_lft forever 
Si bien se especifica la interfaz eth0 en su totalidad, iptables en #firewall natea la salida con la ip 172.16.2.15/24, (Puede observarse que pertenece a eth0:1 porque fue creada con ifconfig). La prueba de dicho nateo esta en que en #nebula se ha hecho coincidencia en la regla para nateo de 172.16.2.0/24, no de 192.168.10.0/27 (Regla que de hecho no existe en #nebula), porque en la tabla de ruteo mostrada arriba se especifica que hacia las redes en el grupo ipset #rwa es a traves de  172.16.2.1

Es obvio que llegando a este punto mi explicación podría ser insuficiente para entender, confió en que las tablas que he colocado sean de hecho más explicativas por si mismas

Para arrancar un nebula como el que use para revisar todo la teoría

Nebula debe conocer esas redes que natea, para que cuando le devuelvan las peticiones el sepa a donde putas debe enviarlas:
root@nebula:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 br0
10.20.20.0      172.16.2.15     255.255.255.0   UG    0      0        0 br1
10.30.20.0      0.0.0.0         255.255.255.0   U     0      0        0 virbr2
172.16.2.0      0.0.0.0         255.255.255.224 U     0      0        0 br1
172.16.3.0      0.0.0.0         255.255.255.0   U     0      0        0 br1
192.168.10.0    0.0.0.0         255.255.255.224 U     0      0        0 br0
Nateamos
iptables -t nat -D POSTROUTING -o br0 -s 192.168.10.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o br0 -s 172.16.2.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o br0 -s 172.16.3.0/24 -j MASQUERADE

Otros apuntes interesantes

Otros apuntes interesantes