Joindre un client IKEv2 à son IP virtuelle attribuée

Une passerelle doit initier une connexion vers un ordinateur portable qui lui est relié par IKEv2, en utilisant l’adresse virtuelle attribuée à ce client. Le tunnel est monté, le client atteint tout ce qui se trouve derrière la passerelle, et le sens inverse échoue toujours. Cette asymétrie est normale : la politique négociée décrit quelles adresses peuvent parler, pas quel côté peut initier. Trois choses doivent concorder avant qu’une requête lancée par la passerelle ne fonctionne.

Le tunnel ne corrige pas l’adresse source

Une CHILD SA couvre une paire de sélecteurs de trafic, un par côté, et autorise le trafic dans les deux sens de cette paire. Elle ne dit rien sur le pair qui a ouvert l’échange IKE en premier. Une passerelle qui écoutait à l’origine pour le tunnel peut toujours envoyer le premier paquet applicatif, à condition que la source et la destination choisies tombent dans les sélecteurs installés. Quand la requête part de la mauvaise interface, elle n’est tout simplement pas éligible au tunnel.

Le routage vers le client est nécessaire et ne suffit pas. La politique doit admettre la source que vous avez réellement utilisée.

Lisez la politique installée, pas le fichier de configuration

Partez de l’association active et de ses sélecteurs, car l’attribution dynamique change ce qui est installé dans le noyau.

ipsec statusall
ip xfrm policy

La sortie d’état nomme la connexion, l’adresse virtuelle attribuée et les sélecteurs actuellement en vigueur pour ce pair. Le vidage de politique montre les mêmes sélecteurs comme état du noyau, et c’est lui que consulte réellement la sélection des paquets. Comparez le sélecteur du côté passerelle avec la source que votre application utilisera, car un écart explique immédiatement l’échec. Lisez l’adresse actuelle du client plutôt qu’une adresse d’une session précédente, car une VIP réattribuée invalide l’ancienne politique.

Le client doit écouter là où le paquet arrive

Même une politique parfaite atteint un port fermé quand le service ne se lie qu’à loopback. L’écouteur doit être sur l’adresse attribuée ou sur une adresse locale générique.

ss -ltnp 'sport = :9090'
iptables -S INPUT

La liste des sockets indique si le port est lié à l’adresse virtuelle, et les règles du pare-feu indiquent si de nouvelles connexions sont acceptées depuis la source protégée. Une règle écrite pour des connexions établies n’admet pas une connexion que la passerelle initie. Conservez l’authentification propre au service, car arriver par le tunnel établit seulement de quel réseau le paquet vient. Un client derrière son propre NAT n’a toujours pas besoin de redirection de port entrante, car ces requêtes circulent à l’intérieur du tunnel existant.

Testez le nouveau sens à part

Une requête client-serveur qui fonctionne n’emprunte jamais ce chemin. Générez la requête depuis la passerelle et observez les deux extrémités.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

La recherche de route répond quelle source et quelle interface la passerelle utiliserait, et c’est la valeur que la politique doit admettre. La capture devrait montrer la requête sortant à l’intérieur d’ESP plutôt qu’en TCP simple sur l’interface publique. Sur le client, capturez le trafic déchiffré pour confirmer l’arrivée et la réponse du service. Si la requête disparaît sans ESP sur le lien, soupçonnez l’adresse source avant le pare-feu du client.

Répétez le test après un renouvellement de clé ou une reconnexion, car la VIP peut changer. Un chemin qui ne fonctionne que jusqu’à la prochaine session n’est pas un chemin qui fonctionne.