Test del kill switch: mesureu el buit, no només la reconnexió

Una reconnexió que acaba en un segon us diu que el client és ràpid. No us diu si alguna cosa es va escapar mentre el túnel estava caigut. Una reconnexió que triga un minut us diu que el client és lent, i encara no us diu si es va permetre trànsit directe durant el buit. Són dues mesures, i un test de kill switch que només informa de la primera no ha provat l’interruptor.

Dues observacions, dos veredictes separats

La pregunta de disponibilitat és simple: quan va tornar a ser utilitzable el túnel i si l’aplicació protegida va necessitar una connexió nova per arribar-hi. La pregunta de compliment és diferent: quins paquets van sortir de la màquina entre el moment en què la protecció va caure i el moment en què va tornar.

Responeu-les amb registres separats. Una línia diu que el buit va durar un nombre determinat de segons. Una altra línia diu si una petició no protegida va tenir èxit durant aquell buit. Fusionar-les en un sol passa o falla amaga el cas que més importa: una reconnexió ràpida amb una fuita.

Construïu una sonda que pugueu cronometrar

Feu servir una petició que sigui innòcua, barata i independent del canal de control propi del túnel. El bucle següent imprimeix una marca de temps, un estat HTTP i el temps transcorregut un cop per segon, i falla sorollosament en lloc de penjar-se:

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

Llegiu els codis de sortida de curl, no només l’estat. Un 28 vol dir que la petició ha esgotat el temps, que és com es veu un camí bloquejat. Un 6 vol dir que la resolució de noms ha fallat, que és una troballa diferent i sovint la més interesant. Un 200 amb poc temps transcorregut durant el buit vol dir que es va permetre sortir el trànsit.

Escriviu la sortida en un fitxer i guardeu-lo. L’historial del terminal no és una prova, i la part interessant solen ser tres línies al mig.

Provoqueu una fallada real, no una d’ordenada

Desconnectar des del menú del propi client prova el camí cooperatiu, on el client té temps d’instal·lar les seves regles de bloqueig. Mateu el procés o deixeu caure l’enllaç subjacent i provareu el camí que segueix una fallada real.

Cada disparador exerceix un camí de codi diferent. Una caiguda al costat del servidor, una pèrdua d’enllaç local i un error del client poden deixar estats diferents, i un d’ells és probablement el cas que acabarà trobant. Executeu la sonda amb almenys dos disparadors i etiqueteu els resultats per disparador.

Llegiu el registre per veure com és el trànsit permès

Un 200 o un fracàs ràpid de connexió durant el buit és una fuita, miri on miri. Els temps esgotats durant tot el buit són la forma esperada d’una política de bloqueig. Una resolució de noms que té èxit mentre les connexions fallen suggereix que el resolutor encara és abastable, que és una fuita d’un altre tipus.

Els sockets existents necessiten cura. Un programa pot continuar usant una connexió que va obrir abans de la desconnexió, així que el trànsit aparentment viu potser no prova que es permetés un camí nou. La llista de sockets mostra si una connexió és anterior a l’esdeveniment:

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

Compareu l’hora d’inici del socket amb la marca de temps de la desconnexió. Una connexió més antiga que la caiguda és prova de reutilització del socket, no d’una fuita, i informar-ne com a fallada envia la persona següent a caçar un error que no existeix.

Registreu el resultat en una forma que sobrevisqui una actualització

Anoteu el disparador, el buit en segons, si alguna petició no bloquejada va tenir èxit, si la resolució de noms va tenir èxit i les versions del client i del sistema operatiu. Aquest conjunt de cinc fets es pot comparar entre versions, cosa que un paràgraf de prosa no pot.

Torneu a executar el mateix test després d’una actualització del client o d’un canvi de perfil, perquè el comportament de bloqueig és un detall d’implementació i es mou. El sentit del registre és adonar-se del moviment abans que esdevingui un incident, no certificar el client una vegada.