Le VPN de site à site ne fonctionne que dans un sens : deux pannes différentes

Le site A joint B, B ne joint pas A, et le tunnel semble correct dans les deux sens. Avant de toucher au tunnel, déterminez quelle panne vous avez réellement. Une nouvelle connexion lancée depuis B et refusée, et une réponse à une connexion lancée depuis A qui n’arrive jamais, produisent des plaintes similaires et des diagnostics complètement différents. L’une est un problème de stratégie ou de route sur le chemin ; l’autre est un problème de chemin de retour ou d’état pour un trafic déjà autorisé.

Cette distinction décide quelles commandes valent la peine d’être exécutées.

Deux pannes qui semblent identiques

Dans le premier cas, l’hôte de B envoie un SYN à A, et rien ne revient. Dans le second, l’hôte de A ouvre une session avec succès et la réponse disparaît au retour. Les deux utilisateurs disent que la liaison est unidirectionnelle, et les deux décrivent un paquet qui a disparu, donc la description seule ne peut pas les séparer.

Demandez quel côté a lancé la tentative qui a échoué. Ce seul fait élimine la moitié des causes possibles.

Vérifiez ensuite que le test a utilisé les mêmes hôtes et le même service du début à la fin. Un ping d’un côté et une connexion à un dossier partagé de l’autre testent deux choses différentes, et un diagnostic fait depuis la passerelle peut choisir une adresse de tunnel qu’aucun trafic utilisateur n’utilise.

Cas un : le chemin de retour manque

Un serveur distant qui répond par une autre passerelle par défaut peut recevoir la requête et router la réponse ailleurs. Les pare-feu à suivi d’état rejettent alors la réponse asymétrique parce qu’elle ne correspond à aucun flux établi, ce qui ressemble exactement à un sens qui n’a jamais fonctionné. La traduction ajoute une autre version : la destination voit une source traduite et répond à celle-ci, donc une règle écrite pour l’adresse d’origine ne correspond jamais.

Vérifiez l’adresse que la destination observe réellement après traduction, et la route de retour pour cette adresse plutôt que pour le sous-réseau d’origine.

Cas deux : la stratégie ne l’a jamais autorisé

Le cas inverse est plus simple et plus fréquent qu’il n’y paraît : un bureau doit consommer un service central et ne jamais lancer de connexions vers le centre. Cette asymétrie est une décision d’accès délibérée, et le tunnel fonctionne comme prévu. Lisez la stratégie d’accès avant de modifier le moindre réglage du tunnel. Le document, et non la capture de paquets, indique quel sens était prévu. Une capture ne peut montrer que ce qui s’est passé, pas ce qui était autorisé.

Si l’initiation bidirectionnelle est réellement nécessaire, ajoutez l’autorisation du service concerné via le jeu de règles pris en charge par la plateforme. Rendre tous les sous-réseaux mutuellement de confiance pour corriger une application transforme une exigence étroite en autorisation large, et cet échange est rarement réexaminé ensuite.

Comparez avant et après sur les mêmes hôtes

Observez les deux extrémités d’une même tentative, pas deux tentatives séparées. Capturez sur la passerelle de l’hôte qui initie et sur la destination, puis comparez ce qui est entré, ce qui est sorti et quelle adresse le côté distant a vue.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Si la capture sur la destination montre la requête avec une adresse source inattendue, la réponse se trouve dans la traduction ou le routage, pas dans la stratégie de sécurité du tunnel. Si la destination ne montre aucune requête, le paquet n’a jamais traversé le chemin protégé.

Après une correction, répétez le test identique depuis l’hôte identique et confirmez que l’accès non lié est toujours refusé. Un état de tunnel « established » ne soutient à lui seul aucune des deux conclusions.