☰

La puerta de enlace VPN en la tabla de rutas personalizada falla

tag-icon • tag-icon iptables vpn routing linux-networking iproute2
La puerta de enlace VPN en la tabla de rutas personalizada falla

Mi objetivo es configurar un contenedor que se comporte como un enrutador que equilibre la carga en varias conexiones VPN.

Para hacer esto, estoy marcando probabilísticamente los paquetes de inicio con:

iptables -I PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m statistic --mode random --probability .50 -j MARK --set-mark 200 -m mark --mark 0
iptables -A PREROUTING -t mangle -j MARK --set-mark 201 -m mark --mark 0
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

Que selecciona una de dos tablas de enrutamiento:

echo "200     tun0" >> /etc/iproute2/rt_tables
echo "201     tun1" >> /etc/iproute2/rt_tables 
ip rule add fwmark 200 table tun0
ip rule add fwmark 201 table tun1

Creo que la tabla de enrutamiento se está seleccionando correctamente, porque cuando configuro cualquiera de las tablas tun0/1 para usar la puerta de enlace VPN, el tráfico parece no regresar. A tcpdumpmuestra el tráfico saliendo pero cualquier comando falla.

ip route add default 10.7.7.1 dev tun0 table tun0
ip route add default 10.7.7.1 dev tun1 table tun1

Si las tablas tun0/1 utilizan el tráfico de la puerta de enlace que no es VPN 10.10.10.1se comporta como se esperaba. También puedo seleccionar entre puertas de enlace VPN configurando la ruta predeterminada en la tabla principal:

ip route add default 10.7.7.1 dev tun0/1

Entonces, el problema parece ser cuando la puerta de enlace VPN se selecciona a través de una de las tablas personalizadas en lugar de la tabla principal. ¡Cualquier pista/diagnóstico/consejo bienvenido!

NB, he configurado las opciones necesarias:

echo 0 > /proc/sys/net/ipv4/conf/**/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
sysctl -w net.ipv4.fwmark_reflect=1
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

RESPUESTA:

La respuesta de @AB proporciona la solución. Necesito agregar una ruta para el tráfico que regresa a la red local en las tablas tun0/1:

ip r a 10.10.10.0/24 via 10.10.10.1 table tun0
ip r a 10.10.10.0/24 via 10.10.10.1 table tun1

Como dijo @AB, sin estos paquetes marcados se devuelven al canal en el que fueron recibidos.

Respuesta1

Sigamos lo que sucede.

  • Un paquete (el primero de un nuevo flujo) llega desde una interfaz que no es de túnel
  • conectarcrear una nueva entrada para este paquete iniciando un nuevo flujo
  • El paquete recibe (aleatoriamente, esta vez:) la marca 200 antes de la decisión de enrutamiento.
  • El paquete se enruta usando la tabla 200.
  • La tabla 200 tiene una única posibilidad: el paquete se enviará a travéstun0
  • La marca del paquete se guarda para todo el flujo en suconectarentrada (es decir: lamarca de connmark).

Hasta ahora todo bien, el paquete (y su flujo) ha sido equilibrado en carga a través detun0.

Ahora bien, ¿qué pasa cuando unresponder¿El paquete en este flujo regresa?

  • El paquete de respuesta llega desdetun0

  • El paquete de respuesta se identifica porconectarcomo parte de un flujo existente

  • El paquete hereda la marca 200 de sumarca de connmarkasociado al flujo existente antes de la decisión de enrutamiento

  • El paquete se enruta usando la tabla 200.

  • La tabla 200 tiene una única posibilidad: el paquete se enviará a travéstun0

    Oups: el paquete de respuesta se enruta desde donde vino: la interfaz del túnel, en lugar de desde donde vino el paquete inicial del flujo.

  • dependiendo de que el enrutador del siguiente salto (el punto final remoto del túnel) también haya desactivado el reenvío de ruta inversa estricto ( rp_filter=0) o no, el paquete se descarta o se enruta nuevamente creando un bucle hasta que su TTL decreciente llega a 0.

Entonces, el problema parece ser cuando la puerta de enlace VPN se selecciona a través de una de las tablas personalizadas en lugar de la tabla principal.

De hecho, elprincipalLa tabla de enrutamiento tiene más de una ruta predeterminada. Normalmente incluye una o más rutas LAN. Entonces, cuando no hay ninguna marca involucrada, la respuesta se envía correctamente después de una evaluación detodode las entradas principales de la tabla de enrutamiento, no solo siguiendo su ruta predeterminada.

Estas rutas LAN adicionales: rutas que utilizaneth0yeth1o al menos el que involucra solicitudes de clientes, si no ambos, también debe copiarse en las tablas de enrutamiento adicionales 200 y 201.

Observación adicional (que no se aplica al caso de OP): en una configuración que funciona en la dirección opuesta: flujos originales desde nodos separados que usan la misma dirección IP de origen (privada) hacia el mismo servicio, podría haber dos flujos distintos buscando idénticos (mismo protocolo de 5 unidades, saddr, sport, daddr, dport) excepto por su interfaz de túnel. Por defectoconectarvería un solo flujo. Para evitar esto, se puede utilizarzonas de seguimiento, (con un valor elegido para representar la interfaz) para tenerconectarmanejarlos por separado.

información relacionada