ESP est le protocole IP 50, pas le port TCP 50 : ce qu’il faut autoriser
Les numéros de protocole et les numéros de port sont des espaces de noms différents. Une règle pour le port TCP 50 n’autorise rien, et le NAT traversal place ESP dans UDP 4500.
Les formulaires de pare-feu demandent un port TCP, et la saisie évidente est 50. Cette saisie n’autorise rien, car ESP est le protocole IP numéro 50 et les numéros de protocole ne sont pas des ports. Les deux espaces de noms partagent de petits entiers et rien d’autre, et l’erreur reste invisible jusqu’à ce qu’IKE se termine et que le trafic protégé n’arrive jamais.
Deux espaces de noms qui partagent de petits nombres
Un en-tête IP porte un champ de protocole qui nomme ce qui suit : 6 pour TCP, 17 pour UDP, 1 pour ICMP, 50 pour ESP, 51 pour AH. Un en-tête TCP ou UDP porte des numéros de port, qui sélectionnent un processus sur l’hôte de destination. Le protocole 50 et le port TCP 50 sont des valeurs sans rapport qu’une boîte de dialogue peut faire passer pour interchangeables.
C’est pourquoi une règle de redirection de port ne peut pas exprimer ESP natif. Il n’y a pas de port de destination ESP à rediriger, et un appareil qui ne comprend que des règles de port n’a aucun vocabulaire pour ce paquet. La règle correcte nomme le protocole IP. Toute boîte de dialogue de port est le mauvais instrument pour ce paquet.
La confusion a une seconde moitié. Quand le paquet est chiffré, tout ce qu’il contient est opaque, y compris l’en-tête TCP de la connexion d’origine. Un pare-feu qui inspecte les ports de ce paquet regarde l’en-tête externe, qui dans le cas natif n’a aucun port à inspecter.
ESP natif, puis l’alternative encapsulée
L’ESP natif est transporté directement comme protocole IP, ce qui est à la fois efficace et peu pratique. Efficace parce qu’il n’y a pas d’en-tête supplémentaire, et peu pratique parce qu’aucun appareil qui traduit les adresses et les ports ne peut le suivre. Le NAT traversal existe pour résoudre cela, en enveloppant le paquet ESP dans UDP afin que le traducteur ait des ports à réécrire.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
Les deux formes sont des déploiements alternatifs du même canal de données, pas des couches d’un seul. Autoriser ESP natif n’autorise pas la forme encapsulée, et autoriser UDP 4500 n’autorise pas le trafic natif, donc un jeu de règles doit correspondre au déploiement plutôt que couvrir les deux par accident.
La détection compte aussi ici. Les extrémités choisissent entre les formes pendant la négociation, et le basculement se produit généralement lorsqu’un NAT est détecté entre elles. Un chemin qui change après l’établissement du tunnel peut donc déplacer le trafic vers un espace de noms que vos règles n’ont jamais couvert.
Lisez quelle forme la connexion utilise réellement
Interrogez l’extrémité plutôt que de deviner depuis le pare-feu. Sous Linux, l’entrée d’état indique si l’association utilise l’encapsulation UDP et quels ports sont impliqués. Une capture répond à la même question depuis le câble, et les deux sont plus rapides que de lire un jeu de règles en espérant.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'La première commande affiche un type d’encapsulation lorsque le NAT traversal est utilisé et rien lorsqu’il ne l’est pas. La seconde montre laquelle des deux formes traverse réellement l’interface, ce qui tranche les discussions sur une configuration qui semble correcte sur le papier.
La contre-preuve appartient à la même étape. Une règle qui signale zéro correspondance vous dit que le paquet ne l’a jamais atteinte, et c’est une question de routage ou de sélecteur, pas de pare-feu.
Confirmez ensuite le canal de contrôle séparément. IKE a ses propres ports et ses propres journaux, et une négociation terminée sans données est exactement la séparation dont traite cet article.
Écrivez la règle dans le bon espace de noms
Une règle de protocole et une règle de port sont des instructions différentes, donc l’outil doit exprimer celle que vous voulez dire. Dans nftables, la correspondance de protocole est explicite, et l’alternative encapsulée reçoit sa propre règle UDP. Gardez les deux règles adjacentes pour que la paire soit visible en relecture.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptRésistez à l’élargissement de l’une ou l’autre règle pour compenser un mauvais diagnostic. Un tout-autorisé pour le protocole ESP sur chaque interface, ou une autorisation UDP de n’importe où vers n’importe où, corrige un symptôme et supprime le contrôle que vous cherchiez à configurer. Le flux étroit pris en charge suffit presque toujours une fois la forme connue.
Enfin, gardez les couches droites lorsque le tunnel fonctionne et que l’application non. Les paquets qui arrivent à la passerelle ont encore besoin d’un transfert, d’une route de retour et d’une politique qui les admet, et rien de tout cela n’est exprimé par une règle ESP. Le port manquant explique une défaillance précise, pas toutes les défaillances IPsec. Gardez la correction de la règle et la vérification du routage comme deux conclusions distinctes.
Notez la forme observée, la règle de protocole ajoutée et le compteur vu ensuite. Trois lignes, et la personne suivante distingue une erreur d’espace de noms d’une erreur de routage en une minute au lieu d’un après-midi.