Escenario
Para controlar mejor una red casera se implementa el cortafuegos y/o proxy en un equipo que está en el medio del router del ISP y de la LAN, ese equipo ha de tener al menos dos tarjetas de red (WAN-LAN). Para aprovechar la infraestructura típica de una red de hogar (en mi caso Movistar, con toda la complicación adicional de TV y Teléfono), y evitar tener que comprar o adaptar nuevos equipos, puntos de acceso wifi, etc, se trata de implementar el Cortafuegos/proxy en un equipo dentro de la misma subnet, haciéndolo funcionar como puerta de enlace para el resto de equipos y redirigiendo después todo al router:
(Nota, en mi caso, la Raspberry Pi actúa como servidor DNS, gracias al muy útil y recomendable Pi Hole https://pi-hole.net/)
El proceso tiene que ser el siguiente:
- Configurar en los equipos conectados por WiFi la nueva puerta de enlace (podremos hacerlo por dhcp)
- Configurar la nueva puerta de enlace con ip forwarding (y quitando ICMP Redirect, como veremos, para evitar que los equipos usen el router principal)
- Añadir ruta estática en el router principal para que todo el tráfico destinado a los equipos wifi pase por la nueva puerta de enlace
- Instalar en la nueva puerta de enlace un proxy web, IDS/IPS, cortafuegos, etc.
- Aplicar reglas (iptables) en el router principal para permitir sólo tráfico desde la nueva puerta de enlace.
Pruebas con máquina virtual como Puerta Enlace
Antes de implementar todo, he hecho pruebas con una máquina virtual como Puerta de Enlace y el host como equipo conectado.
Tras las pruebas, necesariamente la máquina virtual tiene que tener una interfaz de red física propia, es decir, todo el montaje no funciona usando las tarjetas de redes virutales (modos NAT o bridge), así que para la prueba voy a usar un portátil con Windows 10, conectado por WiFi al Router, que ejecuta en VMWare una máquina virtual (Ubuntu) conectada a la WiFi mediante un adaptador Wifi USB, que captura VMWare para ella.
Es un poco lioso, pero válido para la prueba. La Máquina Virtual (VM, Ubuntu), se conecta a la WiFi mediante un adaptador usb wifi, conectado exclusivamente para ella (nada funciona con tarjetas virtuales), mientras que el portátil lo hace mediante su propia tarjeta de red wifi integrada.
El adaptador usb que he usado es el edimax ew-7711usn (muy antiguo) para que funcine en ubuntu hay que poner en el blacklist (/etc/modprobe.d/blacklist.conf) los módulos rt2x00usb y r2x00lib, el módulo con el que funciona es el rt2800usb.
Una vez conectados a la wifi el portátil y la máquina virtual procedemos a la configuración:
Configurar Portátil y Máquina Virtual
La máquina virtual tiene la siguiente conexión (ip 192.168.1.43):
Habilitamos Ip Forwarding (como root)
# echo 1 > /proc/sys/net/ipv4/ip_forward
Cambiamos la ip en el portátil, le ponemos una ip fija y como puerta de enlace la ip de la VM (el servidor DNS uso el de mi Raspberry Pi) (ip 192.168.1.44, puerta de enlace 192.168.1.43)
Capturas de paquetes de red
Una prueba previa para comprobar que el enrutamiento en el portátil es correcto:
Comprobamos que el tráfico externo (ping a google) pasa por la máquina virtual, que es la puerta de enlace, sin embargo el tráfico local LAN es directo (como es de esperar, es capa de enlace, nivel 2 de OSI).
En este momento podemos hacer pruebas, arrancamos sendos WireShark en el portátil y en la máquina virtual, ambos con el filtro de la ip de nuestro portátil (192.168.1.44) para ver qué es lo que va ocurriendo.
Y lo que ocurre es que no funciona la cosa como queremos, pues la máquina virtual (puerta de enlace) está enviando ICMP Redirects para decirle al portátil que mande el tráfico externo a través del router principal.
En las siguientes capturas de wireshark en ambas máquinas vemos el proceso:
Primero el envío del ICMP redirect para una determinada conexión (incluye ip’s y puertos)
En el portátil se reciben multitud de paquetes de este tipo,
(nota: la mac de la máquina virtual la identifica Wireshark como EdimaxTE y la del portátil como LiteonTe)
Una muestra del tráfico al solicitar este blog mediante el portátil muestra que la primera conexión TCP SYN (handshake de tres etapas) la realiza a la puerta de enlace nueva (src: Liteon, dst: Edimax), pero la respuesta del servidor web TCP SYN ACK viene ya del router de movistar (src: mitrastar)
TCP SYN
TCP SYN ACK
Por último, para verificar todo, comprobamos que la máquina virtual, puerta de enlace, sólo captura el tráfico de ida del portátil, pero no el de vuelta (lógico, ya que nos falta decirle al router principal que el tráfico a nuestro portátil ha de redirigirlo por la nueva puerta de enlace, lo haremos después )
Desactivar ICMP Redirect en la Máquina Virtual, nueva puerta de enlace
Escribir los dos como root:
#echo 0> /proc/sys/net/ipv4/conf/wlan0/send_redirects #echo 0> /proc/sys/net/ipv4/conf/all/send_redirects
Si volvemos a realizar las capturas con wireshark, ahora todo el tráfico icmp desaparece, aunque tenemos red e internet porque seguimos en la LAN y el router principal nos responde.
Ruta estática en el router principal
Añadimos ahora la ruta estática en el router principal para que todo el tráfico dirigido al portátil pase por la máquina virtual, su nueva puerta de enlace:
Añadimos en este caso sólo la ip del portátil (máscara 255.255.255.255 o bien /32)
(Nota, la otra ruta estática que tengo para la subred 192.168.2.0/24 es para el decodificador TV de movistar, que lo tengo por wifi, explicado en otro post)
Ahora ya nos aseguramos de que todo el tráfico externo de nuestro portátil de ida y vuelta va a pasar por la máquina virtual. Realizando las capturas con wireshark se comprueba esto, es decir ahora sí vemos en la máquina virtual el tráfico de vuelta, aunque vemos el tráfico duplicado (tráfico de vuelta) y retransmitido (tráfico de ida), para atravesar la máquina virtual en ambos sentidos, es decir vemos los paquetes en los dos saltos:
portátil <--> máquina virtual (puerta de enlace) <--> router principal
Primer tramo: portátil a máquina virtual (src Liteon, dst: edimax)
Segundo tramo (TCP Retransmision) (src Edimax, dst: Mitrastar)
Esto, que parece un poco raro es normal (en un cortafuegos típico, esta retransmisión y duplicación de paquetes se hace entre las dos interfaces de red WAN<->LAN. Realizando alguna búsqueda por internet, puede encontrarse casos similares:
https://osqa-ask.wireshark.org/questions/17859/router-retransmitting-packets
Conclusiones
De esta manera todo funciona correctamente, y el tráfico SSL no se rompe. Sólo he encontrado un inconveniente, originado por el hecho de realizar la prueba usando sólo WiFi: es que se ralentiza muchísimo la navegación en el portátil, de los 100Mbps de bajada de mi internet, en la máquina virtual obtengo unos 25-30Mbps (el adaptador Edimax es WiFi bgn, se conecta a la de 2.4GHz, y estos son valores normales), y en el portátil la velocidad se ralentiza hasta unos 2-3Mbps, ridículo, ocasionado seguro por el trasiego WiFi entre los equipos router principal, puerta de enlace y portátil.
Un paso siguiente que he dado ha sidousar una máquina real a modo de Puerta de Enlace en lugar de la máquina virtual, (un ubuntu live en otro portátil conectado también por WiFi), el mismo hecho se repite, la velocidad de bajada se degrada bastante (ahora obtengo unos 10-15Mbps)
Router ppal ) ) ) ) ( ( ( ( ( Puerta de enlace ) ) ) ) ( ( ( ( Portátil
100Mbps WiFi 70-80 Mbps WiFi 10 Mbps
Por último, la prueba usando el mini PC, conectado esta vez al router principal por cable (repitiendo exactamente los mismos pasos), evita todos los problemas y por fin obtengo en el portátil la velocidad de descarga de 100Mbps, como tiene que ser…
Router ppal ———- Puerta de enlace ( ( ( ( Portátil
100Mbps eth 100 Mbps WiFi 100 Mbps
Una vez comprobado que es posible esta configuración, en la parte 2, trataré de extenderlo a toda la red local (todos los dispositivos que se conecten por WiFi), modificando el router principal para añadir las rutas estáticas para un segmento de red y el dhcp para indicar la nueva puerta de enlace. Y en la puerta de enlace instalar un IDS/IPS y un web proxy.
