Profil WireGuard pour une passerelle IPsec : ce qu'il faut demander à la place

Les délais d'expiration de la poignée de main avec une passerelle silencieuse signifient généralement deux protocoles qui ne se rencontrent jamais. Un pair WireGuard parle Noise tandis qu'une passerelle IPsec attend IKE. Une adresse et un port corrects n'y changent rien.

Réutiliser le point de terminaison dans un profil ne relie pas les deux. L'étape suivante est une demande à qui exploite la passerelle.

Première demande : la version du protocole

IPsec désigne une famille et non un seul flux de travail. IKEv2 et IKEv1 diffèrent par leurs échanges, leurs options d'authentification et leur comportement lors d'un changement de réseau. Une passerelle qui ne termine qu'IKEv1 se comportera très différemment d'une qui propose IKEv2. La configuration du client change avec elle.

Demandez quelle version le service termine et s'il exécute une implémentation fondée sur des normes ou une variante de fournisseur avec son propre client. Les menus des systèmes d'exploitation cachent souvent cette réponse derrière une seule étiquette. L'étiquette n'est pas le protocole.

Deuxième demande : la méthode d'authentification du client

L'authentification est là où se trouve l'essentiel du travail réel. Le service peut attendre un certificat de machine avec un usage étendu de clé particulier, un certificat d'utilisateur, une méthode EAP sur IKEv2 ou une clé prépartagée liée à une identité. Laquelle s'applique décide de ce dont le client a besoin.

Une clé privée WireGuard n'est rien de tout cela. C'est une clé Curve25519 utilisée dans une poignée de main précise. Aucune conversion ne la transforme en certificat ni en identifiant EAP. Un outil qui prétend le contraire renomme le fichier ou génère quelque chose sans rapport.

La spécification d'IKEv2 dans la RFC 7296 décrit ce qu'une implémentation de cette version doit prendre en charge. C'est une référence pour une réponse vague de l'exploitant, pas un guide de configuration du client.

Troisième demande : l'identité de confiance et les destinations

Demandez l'identité de la passerelle telle que le client doit la voir, ainsi que l'ancre de confiance qui la valide. Demandez ensuite quelles plages privées et quels résolveurs le service pousse. Ces deux réponses décident de ce que le tunnel transporte réellement.

Sans elles, une connexion fonctionnelle peut encore échouer à la tâche. Un tunnel monté sans résolveur poussé laisse les noms internes sans réponse. Un sélecteur de trafic absent laisse la destination hors du tunnel alors même que la poignée de main a réussi.

Une sonde du point de terminaison répond à une autre question que l'erreur du client. Un port joignable sans association indique l'authentification, tandis qu'un port injoignable indique le chemin.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Exécutez cette sonde avant de modifier quoi que ce soit dans le client. Si les ports répondent et que l'association échoue toujours, le problème vient des identifiants ou de la politique. S'ils ne répondent pas du tout, aucune modification du profil n'aidera.

Quand les deux protocoles doivent coexister

Administrer les deux réseaux est une raison légitime de conserver les deux protocoles. La conception habituelle termine WireGuard et IPsec sur des interfaces distinctes ou des passerelles distinctes. Le trafic approuvé est alors routé entre elles.

Cette conception introduit une frontière de confiance et d'autorisation, et elle devrait être consignée comme telle. Quels pairs peuvent franchir, dans quel sens et sous la politique de qui relève d'une décision de routage et de pare-feu. Aucun des deux protocoles ne la fournit.

Ce que ce n'est pas, c'est une conversion transparente. Le trafic qui arrive par WireGuard est réorigonné dans le tunnel IPsec, et chaque politique intermédiaire s'y applique.

Clarifiez d'abord les exigences du serveur en matière de protocole et d'authentification. Utilisez ensuite le client et le parcours d'enrôlement que l'exploitant prend en charge, et gardez les clés privées hors des convertisseurs web pendant ce temps.