Prueba de failover: ¿sobrevive un flujo TCP establecido?

Dos resultados se esconden dentro de la frase de que el respaldo funciona. Una petición nueva tiene éxito, y eso es recuperación. Una transferencia ya en curso continúa, y eso es continuidad. Son promesas distintas, y la mayoría de los diseños de failover entregan la primera mientras la segunda expira en silencio. Decida cuál necesita antes de elegir un mecanismo, y escriba la prueba de modo que pueda distinguirlas.

Dos resultados que parecen un solo éxito

Imagine un cliente en 10.90.0.42 con una conexión a 198.51.100.20:443. La salida primaria lo traduce a una dirección y un puerto públicos, y la salida de respaldo lo traduce a otra. La dirección interna del cliente nunca cambia, y por eso la gente espera que la conexión sobreviva.

El servidor no ve una dirección interna. Ve el extremo traducido, y ese extremo es distinto después del cambio.

Así, el flujo antiguo expira mientras una conexión nueva al mismo servicio funciona de inmediato. Ambas observaciones son ciertas a la vez.

Qué ve el servidor cuando cambia la salida

Una conexión TCP se identifica por su cuádrupla, y cambiar la dirección o el puerto de origen crea una conexión distinta para el host que recibe. Los paquetes que llegan desde un origen nuevo en una conexión que el servidor no conoce se descartan o se responden con un reset. Nada en la dirección del cliente VPN conserva la asociación a través de ese cambio.

El failover con estado existe precisamente para evitarlo, y funciona intercambiando estado de traducción y estado de conexión entre los dispositivos de reenvío. Es una característica del par, no del túnel, y hay que diseñarla y probarla en lugar de darla por supuesta.

Compruebe si el par conserva realmente el estado antes de prometer continuidad a nadie. Los comandos siguientes muestran el estado actual en ambos lados.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Por qué no basta la misma dirección pública

Mantener una dirección pública en ambos caminos es un buen comienzo, porque entonces el servidor ve el mismo extremo de origen. Por sí solo no es suficiente. El dispositivo de reenvío todavía necesita el estado de traducción, el estado del cortafuegos y una ruta de retorno utilizable, y eso tiene que existir en el dispositivo que lleva el tráfico después del cambio.

El RFC 3022 describe la traducción de direcciones y trata el intercambio de estado entre dispositivos que traducen como parte de un diseño de respaldo. Una dirección flotante o un perfil copiado mueve la configuración sin mover el estado.

Por eso una prueba que solo hace ping a través del respaldo demuestra muy poco. El ping no tiene estado de conexión que perder.

Decida cuán fuerte es el requisito

Si los usuarios pueden reconectarse tras un fallo, el diseño es de recuperación y la prueba de aceptación es una petición nueva. Si una transferencia de archivos debe sobrevivir, el diseño necesita sincronización de estado y una prueba mucho más cuidadosa. Si una sesión remota debe sobrevivir, el requisito es aún más fuerte y puede necesitar un mecanismo a nivel de aplicación en lugar de uno de red.

Escriba el requisito como una frase con un resultado medible, por ejemplo que la subida se complete sin reiniciar o que el operador se reconecte en un minuto. Después elija el mecanismo más barato que lo cumpla, y con frecuencia es el diseño de recuperación.

Diga explícitamente qué ocurre cuando vuelve el primario, porque un retorno automático puede interrumpir una conexión que acababa de recuperarse en el respaldo. Ese caso pertenece al plan de pruebas, no a una nota al pie.

Compruebe el flujo antiguo y la petición nueva

Inicie una transferencia larga e inofensiva por el primario y luego una petición nueva separada al mismo servicio. Registre el contexto de la aplicación, la dirección de salida observada y la hora. Rompa el primario de una forma aprobada y siga observando la transferencia original mientras envía la petición nueva por el respaldo.

Informe de tres valores: si el flujo antiguo continuó, se reinició o expiró; cuándo funcionó por primera vez la operación nueva; y si el retorno interrumpió algo. Esas tres líneas son el registro de aceptación.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Si la carga de trabajo escribe datos, no repita a ciegas una operación incierta después de un tiempo de espera. Puede que la escritura llegara antes de que se perdiera la respuesta. Pregunte a la aplicación por el resultado, o reintente solo donde la operación sea idempotente. Después escriba la declaración de aceptación en tres partes: las operaciones nuevas se recuperan bajo la política de salida, los flujos existentes tienen el comportamiento de interrupción documentado, y la aplicación se reanuda con seguridad. Esa declaración es verificable y es honesta sobre lo que el diseño no promete.