Conexiones nuevas en una salida VPN nueva, los flujos antiguos se quedan como están

Un drenaje planificado solo mueve flujos sin clasificar. Compárelo con un cambio de ruta y vea las marcas, las tablas y el estado de conntrack que lo sostienen.

Dos salidas VPN sanas, una subida larga ya en marcha y el requisito de que la siguiente conexión use el otro túnel. Hay dos formas de cumplirlo, y solo una es segura en una puerta de enlace en producción. Cambiar la ruta por defecto mueve cada paquete, incluidos los que pertenecen a la subida. Un drenaje planificado cambia la elección para las conexiones nuevas y deja los flujos rastreados en la ruta en la que empezaron.

Dos formas de cambiar una salida

El cambio de ruta es un solo comando y se revierte en segundos, por eso se usa durante los incidentes. También es indiscriminado: los paquetes de la subida existente salen de repente por otro túnel, con otra dirección de origen pública y un estado de traducción aparte.

Si el extremo remoto rastrea los flujos por dirección de origen, la subida puede sencillamente dejar de reconocerse. El drenaje lo evita tomando la decisión una vez por conexión y guardándola, así la subida antigua conserva su salida hasta que termina. Ese es todo el valor del ejercicio: el extremo remoto no ve ningún cambio que tenga que interpretar. Sigue recibiendo paquetes que coinciden con la conexión que ya conoce.

El coste es la complejidad: dos tablas de enrutamiento, un clasificador que se ejecuta en el gancho correcto y unas marcas que deben coordinarse con todo lo demás de la máquina que las use.

Dé a cada salida su propia tabla

Reserve una tabla de enrutamiento por salida y valores de marca o bits distintos para las dos opciones. Cada tabla necesita las rutas adecuadas a su papel, no solo un nombre, y necesita un resultado de fallo deliberado para el caso ausente. Una tabla vacía que cae en silencio a la tabla principal es como sale el tráfico por una salida que nadie eligió.

ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102

Añada una ruta blackhole al final de cada tabla para que una búsqueda sin coincidencia falle ruidosamente en lugar de escaparse a un valor por defecto que usted no eligió.

Elija una vez, en el primer paquete

Clasifique después de que exista el seguimiento de conexiones y antes de la búsqueda de ruta que importa. Para una conexión LAN nueva y sin clasificar, elija la salida y guárdela en el estado de la conexión. En los paquetes posteriores, recupere el valor guardado en la marca de paquete que lee el enrutamiento por políticas.

La parte sutil es qué significa nuevo. Conntrack todavía puede informar de NEW para paquetes tempranos y retransmisiones antes de ver una respuesta, así que un clasificador que solo se fije en ese estado puede sobrescribir una elección que ya había hecho. Compruebe que no haya ninguna salida guardada para la conexión antes de asignar una.

nftables mantiene separadas las marcas de paquete y de conexión, y la guía de metainformación documenta la copia explícita entre ellas. Una marca de conexión no se convierte por sí sola en la marca de paquete con la que coincide su regla, y esa es la razón más habitual de que un clasificador bien escrito no tenga efecto.

Limite la restauración a la dirección y el tráfico que pretende. Aplicar una marca de salida a internet a los paquetes que vuelven puede enviar las respuestas hacia la salida en lugar de hacia la LAN, y el síntoma es una conexión unidireccional que parece un problema de cortafuegos. Lea la ruta de respuesta antes de tocar una regla de cortafuegos, porque el paquete se está enrutando, solo que no de vuelta al remitente.

Cuatro fases de un drenaje

  1. Prepare B sin tocar A: enrutamiento, reenvío, autorización, NAT y la ruta de vuelta. Instale su tabla y su política de selección a través del propietario de configuración existente de la puerta de enlace.

  2. Cambie el clasificador para que las conexiones nuevas y sin clasificar elijan B, conservando las elecciones guardadas. Una transacción nftables atómica evita una ventana en la que haya que limpiar el estado antiguo.

  3. Deje A encendido mientras terminan sus flujos. Su interfaz, tabla, salida remota y mapas NAT siguen formando parte de esos flujos, y editar una regla NAT no reconstruye las vinculaciones que ya existen.

  4. Retire A cuando se cumpla la condición de drenaje, juzgada por el estado de las conexiones y el comportamiento de la aplicación, no por un solo intervalo tranquilo.

Lo que un drenaje no puede prometer

Una petición del navegador no es una conexión de transporte nueva; la agrupación sigue enviando peticiones por la antigua. A la inversa, un flujo UDP puede envejecer fuera de conntrack y un paquete posterior se clasifica de nuevo. El drenaje sigue los flujos rastreados, no la idea que una aplicación tiene de una sesión.

Si A falla antes de que terminen sus flujos, la marca guardada no los salva. Se reconectan por B, o no se reconectan en absoluto. Un drenaje planificado compra continuidad mientras la ruta original está sana; no es una replicación de estado entre salidas independientes.

Verifique ambas mitades

Inicie una conexión permitida de larga duración antes del cambio y otra genuinamente nueva después. Confirme qué túnel usa cada una y qué dirección de origen pública ve el extremo remoto, y luego compruebe que vuelve el tráfico de retorno.

No vacíe la tabla de conntrack para hacer aparecer la nueva elección. Eso destruye exactamente el estado que el drenaje debe preservar, y convierte una migración controlada en una interrupción con una prueba de aspecto limpio.

Artículos relacionados