Estoy intentando resolver un problema extraño en el enrutamiento. Tengo mi enrutador configurado (Turris, ejecutando OpenWRT personalizado), con conexión ipv6 de túnel Strongswan. Esto funciona bien para el enrutador en sí, ya que su conectividad ipv6 funciona bien (a través del túnel, mi proveedor no ofrece ipv6 nativo).
TL;DR: Las rutas no se eligen como esperaba, ya que la más genérica, ::/0 parece ser siempre la preferida, aunque hay una coincidencia /64 disponible.
Pero cuando intenté extender esto a mi red doméstica, me encontré con un problema y no puedo encontrar la causa.
Aunque el ipsec funciona, obtengo una interfaz ipsec0 y estas rutas:
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 :: U 1024 0 2 ipsec0
2a01:490:19:42::/64 :: U 1024 0 0 br-lan
Aquí, 2a01:490:19:42::/64 es un rango que dediqué para mi red local, 2a01:490:19:42::1 es la dirección IP del enrutador en esa red.
He aquí algunas observaciones:
1) Cuando hago ping a 2a01:490:19:42::1 desde una computadora en mi red local, el enrutador responde, pero envía la respuesta a la interfaz ipsec0. No tengo ni idea de porqué. ¿No debería preferirse el prefijo más específico, 2a01:490:19:42::/64, en br-lan? Parece elegir correctamente la dirección IP de origen 2a01:490:19:42::1.
2) Sucede lo mismo cuando intento enviar un paquete desde mi red local a algún otro sitio, digamos ping6 stackexchange.com. Los paquetes llegan al enrutador, se reenvían, el servidor envía una respuesta, el enrutador los recibe... y los envía de regreso a la interfaz ipsec0.
3) No existen políticas xfrm. ip xfrm polno devuelve nada. Pero Strongswan se está postulando y tenía la impresión de que Strongswan siempre crea algunas políticas. En mi configuración anterior, tuve que agregar algunas para permitir el paso de paquetes al túnel, pero estoy un poco confundido acerca de que la lista de políticas esté vacía.
Muy bien, entonces ¿qué pasa? ¿Por qué se prefiere la ruta más genérica, ::/0, para mis paquetes ipv6?
¡Gracias!
Respuesta1
El problema fue que ipsec insertó sus reglas en una tabla de enrutamiento diferente (tabla 220) y creó una política para dirigir el tráfico allí:
root@turris:/etc/config# ip rule list
0: from all lookup local
220: from all lookup 220
32766: from all lookup main
32767: from all lookup default
Pero la tabla 220solo contenía la ruta predeterminada hacia el túnel ipsec, y no la red local:
root@turris:/etc/config# ip -6 r show table 220
default dev ipsec0 proto static src 2a01:490:19:42::1 metric 1024
Lo que inevitablemente provocó que todos los paquetes se reenviaran al túnel.
La red del enrutador funcionó solo porque fueron aceptadas y no enrutadas.
Solucioné este problema indicándole a strongswan que insertara reglas de enrutamiento en la tabla principal, configurando charon.routing_table = 254(la identificación de main, como se ve en /etc/iproute2/rt_tables). Mi strongswan.confahora se ve así:
charon {
# load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
routing_table = 254 # main
}