VPN connecté mais le pare-feu bloque encore : comment savoir lequel

Le client dit connecté, la ressource refuse toujours, et l'étape suivante habituelle consiste à désactiver quelque chose. Les deux contrôles de cette phrase font des tâches différentes : le VPN construit un chemin pour le trafic couvert, et un pare-feu décide par connexion si le trafic peut passer. Un tunnel qui fonctionne avec une politique qui refuse ressemble exactement à un tunnel cassé depuis la chaise de l'utilisateur, donc le travail consiste à trouver quelle couche répond. Voici l'ordre que je suis, avec la lecture qui vous dit de vous arrêter.

Séparez le chemin de la politique

Commencez par la forme de la panne, car c'est de l'information gratuite. Une chute de paquet produit un délai d'attente : le client réessaie, rien ne revient et la commande reste bloquée jusqu'à abandonner. Un refus produit une négation ou une réinitialisation : quelque chose a répondu et dit non. Un service qui n'écoute pas refuse sur l'hôte lui-même, sans aucun pare-feu.

Ces trois issues pointent vers des couches différentes. Le délai signifie qu'une politique quelque part écarte en silence, ou que la route ne quitte jamais la machine. Refusé signifie que vous avez atteint l'hôte et que sa pile ou son pare-feu local a décliné. Un silence total, avec l'interface du tunnel active et aucune route vers la destination, signifie que le chemin est faux et qu'aucune règle de pare-feu n'y remédiera.

Lisez le chemin en une passe

Confirmez que le tunnel couvre la destination avant de regarder une seule règle. Un tunnel divisé qui ne porte que le sous-réseau du bureau ne routra pas une requête vers une autre plage, et la panne ressemble alors à un blocage du pare-feu qui n'en est pas un :

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

La sortie de la route nomme l'interface par laquelle le paquet sortira et l'adresse source qu'il portera. Si cette interface est votre carte réseau physique et non le tunnel, le problème tient au routage ou aux plages autorisées du tunnel, et il relève de la configuration du VPN et non du pare-feu.

Un piège propre au VPN mérite sa propre vérification. Dans WireGuard, AllowedIPs d'un pair est à la fois une route et un filtre cryptographique : un paquet dont l'adresse source n'appartient pas à l'ensemble autorisé du pair est écarté avant que la moindre règle de pare-feu soit consultée. Un pare-feu local parfaitement correct peut donc se trouver derrière un rejet silencieux qui ressemble à une politique, et le correctif est une ligne de configuration de clé, pas une règle.

Lisez la politique à la couche qui répond

Une fois le chemin correct, parcourez la politique de l'hôte vers l'extérieur et surveillez l'unique couche dont les compteurs bougent :

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

La socket en écoute répond à une autre question que les règles. Si rien n'écoute sur le port, le noyau refuse la connexion et aucune règle entrante n'est pertinente. Si la socket existe et que la connexion depuis un client distant expire, un rejet se produit quelque part sur le chemin, et les compteurs des règles vous disent s'il se produit ici.

Activez la journalisation pour le profil ou la chaîne que vous soupçonnez au lieu de deviner de l'extérieur. Un seul rejet journalisé qui nomme la source, la destination et le port identifie la couche et la règle, et il prouve aussi que le paquet est arrivé, ce qu'aucun test côté client ne peut établir.

Lisez la décision de la passerelle quand le tunnel y aboutit

Sur une passerelle site à site ou d'accès distant, le VPN authentifie un utilisateur et la politique autorise une ressource, et ce sont des octrois distincts. Un utilisateur admis dans le tunnel n'est pas admis automatiquement sur chaque hôte interne, et le refus vient souvent d'une règle de transfert alors que le tunnel lui-même est sain. La même séparation apparaît dans IPsec, où la politique de sécurité qui sélectionne le trafic diffère du filtre qui l'admet, et c'est pourquoi les deux sont documentés comme des mécanismes différents dans RFC 4301.

Vérifiez le chemin de retour aussi soigneusement que celui d'aller. Le filtrage à état doit voir la réponse, donc un routage asymétrique par le tunnel dans un sens et autour de lui dans l'autre produit des rejets qui semblent aléatoires et ne se reproduisent que depuis certains clients. Si le trafic atteint la passerelle et s'arrête, lisez la règle de transfert et la route de retour ensemble avant d'élargir quoi que ce soit.

La passerelle est aussi l'endroit où une règle de NAT ou de masquage peut cacher la vraie source. Si les hôtes internes voient l'adresse de la passerelle au lieu du client, leurs règles de pare-feu local qui doivent correspondre au pool de clients ne correspondront jamais, et le correctif relève de la passerelle et non de chaque serveur.

Changez la couche la plus étroite, puis vérifiez

Résistez à la réparation large. Désactiver le pare-feu local, ajouter une règle qui autorise tout ou forcer chaque interface dans un profil de confiance supprime à chaque fois le contrôle qui faisait son travail, et le changement survit à l'incident. Une règle limitée à la plage source et au port concerné est plus facile à relire, plus facile à retirer, et laisse le reste de la politique de la machine intact.

Vérifiez avec le même test qui a échoué, depuis le même client, puis encore une fois après une reconnexion, car une règle qui correspond avant que le tunnel renégocie peut cesser de correspondre ensuite :

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Avant de clore :

• La route vers la destination sort par l'interface du tunnel, et l'adresse source correspond à ce que la politique attend.
• Quelque chose écoute sur le port, et le refus ou le délai est attribué à une règle nommée plutôt que supposé.
• La passerelle transfère dans les deux sens, et la destination voit la source pour laquelle vos règles ont été écrites.
• Aucun contrôle n'a été désactivé pour faire passer le test, et le changement que vous avez fait nomme une seule plage source et un seul port.