Proba do kill switch: mida o oco, non só a reconexión

Unha reconexión que remata nun segundo dinos que o cliente é rápido. Non dinos se algo escapou mentres o túnel estaba caído. Unha reconexión que tarda un minuto dinos que o cliente é lento, e segue sen dicirnos se se permitiu tráfico directo no oco. Son dúas medicións, e unha proba de kill switch que só informa da primeira non probou o interruptor.

Dúas observacións, dous veredictos separados

A pregunta de dispoñibilidade é simple: cando volveu ser utilizable o túnel, e se a aplicación protexida necesitou unha conexión nova para chegar alí. A pregunta de cumprimento é distinta: que paquetes saíron da máquina entre o momento en que caeu a protección e o momento en que volveu.

Respóndallas con rexistros separados. Unha liña di que o oco durou un número determinado de segundos. Outra liña di se unha petición sen protección tivo éxito durante ese oco. Fundilas nun só aprobado ou fallado agocha o caso que máis importa: unha reconexión rápida cunha fuga.

Construír unha sonda que poida cronometrar

Use unha petición que sexa inocua, barata e independente da propia canle de control do túnel. O bucle de abaixo imprime unha marca de tempo, un estado HTTP e o tempo transcorrido unha vez por segundo, e falla ruidosamente en vez 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 os códigos de saída de curl, non só o estado. Un 28 significa que a petición esgotou o tempo, que é como se ve unha ruta bloqueada. Un 6 significa que fallou a resolución de nomes, que é un achado distinto e a miúdo o máis interesante. Un 200 con pouco tempo transcorrido durante o oco significa que se permitiu saír ao tráfico.

Escriba a saída nun ficheiro e gárdeo. O historial do terminal non é unha proba, e a parte interesante adoita ser tres liñas no medio.

Provoque un fallo real, non un ordenado

Desconectar desde o menú do propio cliente proba a ruta cooperativa, na que o cliente ten tempo de instalar as súas regras de bloqueo. Mate o proceso ou deixe caer a ligazón subxacente e probará a ruta que toma un fallo real.

Cada disparador exercita unha ruta de código distinta. Unha caída do lado do servidor, unha perda de ligazón local e un fallo do cliente poden deixar estados distintos, e un deles é probablemente o caso co que acabará atopándose. Execute a sonda con polo menos dous disparadores e etiquete os resultados por disparador.

Lea o rexistro para ver como é o tráfico permitido

Un 200 ou un fallo rápido de conexión durante o oco é unha fuga, mire cara a onde mire. Os tempos esgotados durante todo o oco son a forma esperada dunha política de bloqueo. Que a resolución de nomes teña éxito mentres as conexións fallan suxire que o resolutor segue sendo alcanzable, o que é unha fuga doutro tipo.

Os sockets existentes requiren coidado. Un programa pode seguir usando unha conexión que abriu antes da desconexión, así que o tráfico aparentemente vivo pode non probar que se permitiu unha ruta nova. A lista de sockets mostra se unha conexión é anterior ao evento:

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

Compare a hora de inicio do socket coa marca de tempo da desconexión. Unha conexión máis antiga que a caída é proba de reutilización do socket, non dunha fuga, e informar dela como fallo envía á seguinte persoa a cazar un erro que non existe.

Rexistre o resultado nunha forma que sobreviva a unha actualización

Anote o disparador, o oco en segundos, se algunha petición non bloqueada tivo éxito, se a resolución de nomes tivo éxito e as versións do cliente e do sistema operativo. Ese conxunto de cinco feitos pódese comparar entre versións, cousa que un parágrafo de prosa non pode.

Volva executar a mesma proba tras unha actualización do cliente ou un cambio de perfil, porque o comportamento de bloqueo é un detalle de implementación e móvese. O sentido do rexistro é notar o movemento antes de que se converta nun incidente, non certificar o cliente unha vez.