IKE sur TCP 4500 : vérifier les deux extrémités avant la règle de port
L'encapsulation TCP se négocie entre les deux extrémités, elle n'est pas accordée par une règle de pare-feu. Exécutez la vérification de l'écouteur, la capture et les quatre étapes d'acceptation dans l'ordre.
Les tickets de support arrivent souvent avec la modification de pare-feu déjà approuvée et le tunnel qui refuse encore de monter. C'est le résultat attendu quand une seule extrémité possède la fonction : l'encapsulation TCP selon la RFC 9329 doit être implémentée et configurée aux deux extrémités, et l'accord se fait à l'intérieur de la connexion avant que le moindre trafic protégé puisse circuler. Ouvrir un port annonce un écouteur qui n'existe peut-être pas, et un écouteur sans configuration correspondante de l'autre côté accepte une connexion puis se tait. La séquence ci-dessous place les vérifications bon marché en premier.
Savoir ce que l'option ajoute réellement
L'IPsec natif transporte les charges chiffrées comme protocole IP 50, sans numéro de port à autoriser. Le NAT traversal enveloppe ces paquets dans de l'UDP vers le port 4500, et c'est pourquoi tant de règles de pare-feu mentionnent ce port. La RFC 9329 ajoute une représentation en flux : les paquets IKE et IPsec voyagent tous deux dans une seule connexion TCP, normalement vers le port 4500.
Le flux n'est pas un service web. Une connexion TCP vers 4500 ne dit rien sur HTTP, TLS ou l'amabilité avec un mandataire, et un mandataire HTTP sur le chemin cassera généralement le cadrage au lieu de le transporter.
Vérification préalable avant de toucher au pare-feu
La norme place TCP comme solution de repli pour les réseaux qui écartent le chemin UDP, et non comme son remplacement. Obtenez deux faits de chaque fournisseur : le nom exact de la fonction et la version qui implémente la RFC 9329 plutôt qu'une variante propriétaire. Des libellés comme IPsec over TCP ont servi à des conceptions sans rapport, demandez donc la référence du document et la clé de configuration qui l'active. Sans les deux réponses, ne supposez rien sur la compatibilité sur le fil.
Prouvez-le dans un laboratoire où les deux extrémités sont à vous. Une passerelle qui répond sur TCP 4500 mais ne termine jamais IKE est la signature d'un écouteur sans l'encapsulation correspondante de l'autre côté, et le découvrir là-bas coûte bien moins cher qu'en pleine fenêtre de changement.
Côté répondeur : quelque chose écoute-t-il
Commencez par la socket. ss -ltnp | grep 4500 indique si un écouteur TCP existe et quel processus le possède. L'absence de ligne termine l'enquête au niveau de la configuration de la passerelle, et non du réseau.
Si la socket est là, observez la poignée de main au lieu de deviner depuis le côté client : tcpdump -ni any 'tcp port 4500'. Une poignée de main en trois temps terminée suivie de silence signifie que le flux a été accepté et que l'échange IKE à l'intérieur a échoué, tandis qu'un SYN sans réponse pointe le filtrage ou la mauvaise adresse.
Comparez avec le chemin UDP dans la même fenêtre de capture pour que les deux ne se confondent pas : tcpdump -ni any 'udp port 4500 or proto 50'. Du trafic sur le protocole 50 ou le port UDP 4500 alors que vous croyez TCP en usage signifie que les extrémités ne se sont jamais accordées sur le repli. Capturez aussi sur la passerelle si vous pouvez, car une capture côté client ne peut pas montrer ce que l'extrémité distante a envoyé.
Acceptez en quatre étapes distinctes
Traitez le montage comme quatre résultats. Chacun peut échouer pour une raison différente, et un seul réussi ou échoué cache lequel c'était, donc arrêtez-vous à la première étape qui échoue et reprenez depuis le début.
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
La quatrième étape est celle que l'on saute. Une session existante peut continuer à fonctionner sur un état mis en cache, ouvrez donc une connexion neuve vers un hôte derrière la passerelle avant de clore le changement. Si la deuxième étape échoue alors que la première passe, le désaccord se situe dans la proposition ou dans le réglage d'encapsulation, pas dans le pare-feu.
Retour arrière, et le coût de le laisser activé
Planifiez l'annulation avant le changement : désactivez l'option d'encapsulation aux deux extrémités et confirmez que le tunnel revient en UDP. Gardez la règle TCP pendant un cycle de revue au cas où le repli redeviendrait nécessaire, puis retirez-la. Un écouteur inutilisé sur 4500 est une surface sans aucune valeur opérationnelle.
Surveillez la signature de performance dès qu'il portera du vrai travail. TCP dans TCP ajoute des couches d'acquittement qui calent sur une seule perte, et les flux qui partagent une connexion peuvent se bloquer mutuellement, mesurez donc l'application qui utilisera le tunnel plutôt qu'un ping.
Liste d'acceptation
Confirmez le nom et la version de la fonction aux deux extrémités, l'écouteur côté répondeur, la capture montrant une poignée de main terminée et les quatre étapes consignées avec des horodatages. Ajoutez la raison du repli au registre de changement pour que l'ingénieur suivant sache pourquoi TCP est là. Répétez le retour arrière avant d'en avoir besoin.
Si une étape échoue, ne réparez que cette étape. Changer la suite de chiffrement ou les réglages d'identité pour traquer un problème de transport ajoute généralement une seconde panne sans rapport par-dessus la première.