Prueba del kill switch: mida el hueco, no solo la reconexión

Una reconexión que termina en un segundo le dice que el cliente es rápido. No le dice si algo se escapó mientras el túnel estaba caído. Una reconexión que tarda un minuto le dice que el cliente es lento, y sigue sin decirle si se permitió tráfico directo en el hueco. Son dos mediciones, y una prueba de kill switch que solo informa la primera no ha probado el interruptor.

Dos observaciones, dos veredictos separados

La pregunta de disponibilidad es simple: cuándo volvió a ser utilizable el túnel y si la aplicación protegida necesitó una conexión nueva para llegar hasta allí. La pregunta de cumplimiento es distinta: qué paquetes salieron de la máquina entre el momento en que cayó la protección y el momento en que volvió.

Respóndalas con registros separados. Una línea dice que el hueco duró un número determinado de segundos. Otra línea dice si una petición sin protección tuvo éxito durante ese hueco. Fusionarlas en un solo aprueba o falla oculta el caso que más importa: una reconexión rápida con una fuga.

Construya una sonda que pueda cronometrar

Use una petición que sea inocua, barata e independiente del propio canal de control del túnel. El bucle de abajo imprime una marca de tiempo, un estado HTTP y el tiempo transcurrido una vez por segundo, y falla ruidosamente en lugar de colgarse:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Lea los códigos de salida de curl, no solo el estado. Un 28 significa que la petición agotó el tiempo, que es como se ve una ruta bloqueada. Un 6 significa que falló la resolución de nombres, que es un hallazgo distinto y a menudo el más interesante. Un 200 con poco tiempo transcurrido durante el hueco significa que se permitió salir al tráfico.

Escriba la salida en un archivo y guárdelo. El historial del terminal no es una prueba, y la parte interesante suele ser tres líneas en el medio.

Provoque un fallo real, no uno ordenado

Desconectar desde el menú del propio cliente prueba la ruta cooperativa, en la que el cliente tiene tiempo de instalar sus reglas de bloqueo. Mate el proceso o deje caer el enlace subyacente y probará la ruta que toma un fallo real.

Cada disparador ejercita una ruta de código distinta. Una caída del lado del servidor, una pérdida de enlace local y un bloqueo del cliente pueden dejar estados distintos, y uno de ellos es probablemente el caso con el que acabará encontrándose. Ejecute la sonda con al menos dos disparadores y etiquete los resultados por disparador.

Lea el registro para ver cómo es el tráfico permitido

Un 200 o un fallo rápido de conexión durante el hueco es una fuga, mire hacia donde mire. Los tiempos agotados durante todo el hueco son la forma esperada de una política de bloqueo. Que la resolución de nombres tenga éxito mientras las conexiones fallan sugiere que el resolutor sigue siendo alcanzable, lo que es una fuga de otro tipo.

Los sockets existentes requieren cuidado. Un programa puede seguir usando una conexión que abrió antes de la desconexión, así que el tráfico aparentemente vivo puede no probar que se permitió una ruta nueva. La lista de sockets muestra si una conexión es anterior al evento:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Compare la hora de inicio del socket con la marca de tiempo de la desconexión. Una conexión más antigua que la caída es prueba de reutilización del socket, no de una fuga, e informar de ella como fallo envía a la siguiente persona a cazar un error que no existe.

Registre el resultado en una forma que sobreviva a una actualización

Anote el disparador, el hueco en segundos, si alguna petición no bloqueada tuvo éxito, si la resolución de nombres tuvo éxito y las versiones del cliente y del sistema operativo. Ese conjunto de cinco hechos se puede comparar entre versiones, cosa que un párrafo de prosa no puede.

Vuelva a ejecutar la misma prueba tras una actualización del cliente o un cambio de perfil, porque el comportamiento de bloqueo es un detalle de implementación y se mueve. El sentido del registro es notar el movimiento antes de que se convierta en un incidente, no certificar al cliente una vez.