Test du kill switch : mesurez l’écart, pas seulement la reconnexion

Une reconnexion rapide prouve que le client est rapide. Notez ce qui a quitté la machine pendant l’écart, avec le déclencheur utilisé, sinon le test n’a mesuré que la moitié.

Une reconnexion qui se termine en une seconde vous dit que le client est rapide. Elle ne vous dit pas si quelque chose s’est échappé pendant que le tunnel était coupé. Une reconnexion qui prend une minute vous dit que le client est lent, et toujours pas si le trafic direct était autorisé pendant l’écart. Ce sont deux mesures, et un test de kill switch qui ne rapporte que la première n’a pas testé l’interrupteur.

Deux observations, deux verdicts distincts

La question de disponibilité est simple : quand le tunnel est-il redevenu utilisable, et l’application protégée a-t-elle eu besoin d’une nouvelle connexion pour y arriver. La question d’application est différente : quels paquets ont quitté la machine entre le moment où la protection est tombée et le moment où elle est revenue.

Répondez-y par des relevés séparés. Une ligne dit que l’écart a duré un certain nombre de secondes. Une autre ligne dit si une requête non protégée a réussi pendant cet écart. Les fondre en un seul réussi ou échoué cache le cas qui compte le plus : une reconnexion rapide avec une fuite.

Construisez une sonde que vous pouvez chronométrer

Utilisez une requête inoffensive, bon marché et indépendante du canal de contrôle propre au tunnel. La boucle ci-dessous imprime un horodatage, un statut HTTP et le temps écoulé une fois par seconde, et elle échoue bruyamment au lieu de rester bloquée :

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

Lisez les codes de sortie de curl, pas seulement le statut. Un 28 signifie que la requête a expiré, c’est à quoi ressemble un chemin bloqué. Un 6 signifie que la résolution de noms a échoué, ce qui est une autre constatation et souvent la plus intéressante. Un 200 avec un temps écoulé court pendant l’écart signifie que le trafic a été autorisé à sortir.

Écrivez la sortie dans un fichier et conservez-le. L’historique du terminal n’est pas une preuve, et la partie intéressante est généralement trois lignes au milieu.

Provoquez une vraie panne, pas une panne propre

Se déconnecter depuis le menu du client teste le chemin coopératif, où le client a le temps d’installer ses règles de blocage. Tuez plutôt le processus, ou coupez la liaison sous-jacente, et vous testez le chemin que prend une panne réelle.

Chaque déclencheur exerce un chemin de code différent. Une panne côté serveur, une perte de liaison locale et un plantage du client peuvent chacun laisser un état différent, et l’un d’eux est probablement le cas que vous finirez par rencontrer. Exécutez la sonde avec au moins deux déclencheurs et étiquetez les résultats par déclencheur.

Lisez le journal pour voir à quoi ressemble le trafic autorisé

Un 200 ou un échec de connexion rapide pendant l’écart est une fuite, dans quelque direction qu’elle pointe. Des expirations tout au long de l’écart sont la forme attendue d’une politique de blocage. Une résolution de noms qui réussit pendant que les connexions échouent suggère que le résolveur est encore joignable, ce qui est une fuite d’un autre genre.

Les sockets existants demandent du soin. Un programme peut continuer à utiliser une connexion ouverte avant la déconnexion, si bien qu’un trafic apparemment vivant peut ne pas prouver qu’un nouveau chemin a été autorisé. La liste des sockets indique si une connexion précède l’événement :

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

Comparez l’heure de début du socket avec l’horodatage de la déconnexion. Une connexion plus ancienne que la panne est la preuve d’une réutilisation de socket, pas d’une fuite, et la signaler comme un échec envoie la personne suivante chasser un bug qui n’existe pas.

Consignez le résultat sous une forme qui survit à une mise à jour

Notez le déclencheur, l’écart en secondes, si une requête non bloquée a réussi, si la résolution de noms a réussi, et les versions du client et du système d’exploitation. Cet ensemble de cinq faits se compare entre versions, ce qu’un paragraphe de prose ne peut pas faire.

Relancez le même test après une mise à jour du client ou un changement de profil, car le comportement de blocage est un détail d’implémentation et il évolue. Le but du relevé est de remarquer le changement avant qu’il ne devienne un incident, pas de certifier le client une fois pour toutes.

Articles similaires