Un ESP sortant sans réponse ne signifie pas que le VPN est mort

Vous avez capturé le trafic sur l’hôte IPsec, vu des paquets ESP partir, rien revenir, et conclu que le côté distant est en panne. La capture ne soutient pas cette conclusion. L’ESP protège un sens d’une conversation et n’acquitte rien au niveau IP, donc l’absence d’ESP retour peut tout aussi bien signifier que l’application n’avait rien à dire que le tunnel est mort. Lisez l’échange interne et l’état du côté récepteur avant d’accuser l’une ou l’autre extrémité.

Le mythe : chaque paquet protégé mérite une réponse

L’ESP n’est pas un protocole requête-réponse. Il chiffre et authentifie ce que la politique sélectionne, et le récepteur valide, déchiffre et remet ce paquet interne sans générer de paquet à lui. Une requête UDP que la destination ignore, ou un écho ICMP que la politique entrante rejette, produisent le silence dans les deux sens comme résultat correct. Traiter ce silence comme une panne de transport vous envoie chercher une panne réseau qui n’a jamais existé.

Ce qu’une capture unidirectionnelle prouve réellement, c’est que la pile de l’émetteur a chiffré quelque chose à ce point d’observation. Rien sur l’arrivée, et rien sur l’intention de répondre. La question utile n’est pas « pourquoi n’y a-t-il pas de réponse » mais « qu’aurait dû produire la conversation interne ».

Deux SA, deux SPI, une conversation

Les associations de sécurité IPsec sont unidirectionnelles, donc un échange protégé normal comporte une association entrante et une association sortante avec des identifiants distincts et un état indépendant. Chercher le trafic retour par le SPI du paquet sortant est donc une erreur de catégorie, car toute réponse circule sous la SA sortante propre du pair avec son propre SPI. Appariez plutôt l’ensemble par sélecteurs de trafic et adresses du pair.

Le renouvellement de clés complique le tableau pendant quelques secondes à la fois, car l’ancien état et l’état de remplacement peuvent se chevaucher. Si le symptôme a commencé autour d’un renouvellement de clés, collectez les identifiants d’association et les horodatages ensemble plutôt que le seul nom de la connexion.

Ce que le récepteur doit faire avant que quoi que ce soit ne réponde

Chaque ligne échoue indépendamment et chaque échec a un propriétaire différent, c’est pourquoi une seule capture ne peut pas les distinguer. Le compteur entrant est la seule preuve directe d’arrivée, car un paquet qui échoue à son authentification ou à son contrôle de rejeu est rejeté sans aucune réponse. Un pair dont le compteur entrant n’a pas bougé ne vous envoie donc aucune information sur sa politique.

La remise est une étape distincte du déchiffrement. L’état peut être valide et le paquet tout de même rejeté ensuite par une politique entrante ou une route qui n’inclut pas la destination interne, donc vérifiez si l’hôte cible a vu du texte en clair plutôt que de supposer qu’un compteur propre signifie que le paquet est allé où vous vouliez.

L’ESP natif n’est pas UDP

L’ESP natif est le protocole IP 50, qui n’est ni TCP ni UDP et n’a aucun port. Une règle de pare-feu autorisant IKE sur UDP 500 ne dit donc rien du chemin de données, et un filtre écrit autour des ports peut laisser un tunnel négocier puis rejeter tout ce qui est transporté à l’intérieur. Testez le chemin de données pour lui-même, dans le mode que vous avez réellement observé.

Derrière un NAT la forme change : la charge protégée circule à l’intérieur d’UDP, généralement sur le port 4500, comme le définit la RFC 3948. Enregistrez le mode actif avant d’écrire la moindre règle, car un équipement sur le chemin peut traiter l’ESP natif et l’ESP encapsulé en UDP de façon totalement différente, et certains middleboxes autorisent l’un tout en rejetant l’autre.

Lisez des compteurs qui appartiennent à cet incident

Sur un hôte strongSwan, swanctl --list-sas rapporte les compteurs de paquets et d’octets par association dans les deux sens, ce qui suffit à séparer « jamais arrivé » de « arrivé et sans réponse ». Sous Linux, /proc/net/xfrm_stat compte les échecs agrégés comme l’état manquant, la politique manquante et les erreurs de protocole. Ces totaux s’accumulent depuis le démarrage et appartiennent à un seul espace de noms réseau, donc un grand nombre n’est pas une attribution.

Prenez deux relevés autour de la fenêtre de l’incident dans le bon espace de noms et comparez les écarts, sinon vous collerez les erreurs de la semaine dernière sur le ticket de cet après-midi. Inscrivez l’espace de noms et les deux horodatages dans le ticket pour que le prochain lecteur puisse reproduire la comparaison au lieu de faire confiance à un total.

Nommez l’étape, pas le suspect

Une conclusion utile dit où le paquet s’est arrêté : jamais reçu, reçu et rejeté, remis mais sans réponse, ou répondu et perdu au retour. Chacun de ces cas désigne un propriétaire différent et une commande suivante différente. « Aucune réponse du serveur VPN » écrase quatre pannes distinctes en une phrase que la capture n’a jamais justifiée.

Gardez les captures étroites et gardez l’état brut du noyau hors des tickets, car il peut porter du matériel de clé qui n’a rien à faire hors de l’hôte. Les écarts de compteurs et les horodatages sont les parties qui valent la peine d’être transmises à la personne suivante.