Le pare-feu bloque-t-il le VPN ? Une vérification étape par étape

Un seul délai dépassé de VPN prouve qu’aucune réponse utilisable n’est arrivée, et ne prouve rien sur la cause. Le profil peut indiquer le mauvais port, le serveur peut être hors service, ou la requête peut arriver sans chemin de retour fonctionnel. Chacun de ces cas laisse une trace différente, et c’est la trace qui vous dit quelle règle toucher. Parcourez les quatre étapes ci-dessous dans l’ordre. Arrêtez-vous dès que l’une d’elles explique le symptôme.

Étape 1 : confirmer le serveur et le transport

Lisez le nom du serveur, le transport et le port dans le profil actuel de l’opérateur, et non dans une modification locale. Un port modifié sur votre ordinateur portable ne peut pas créer d’écouteur sur un serveur public, et cette incohérence produit un délai identique à un blocage. Si le profil propose un transport alternatif pris en charge, notez-le comme solution de repli et non comme correctif. Résolvez le nom et comparez la réponse à l’adresse que l’opérateur a publiée.

Un enregistrement DNS obsolète envoie le client vers un hôte qui n’a jamais répondu. C’est un autre défaut qui imite un filtre, et il coûte une seule requête à écarter.

Écrivez les deux valeurs dans le ticket. Toutes les comparaisons ultérieures les utilisent, et un ticket sans elles relance l’enquête.

Étape 2 : prouver le chemin par une seule comparaison contrôlée

Laissez l’appareil et le profil inchangés et essayez un autre réseau d’accès de confiance. Si le tunnel monte là-bas, la différence est le chemin d’origine ou sa politique. Si un second appareil approuvé fonctionne sur le réseau d’origine, la différence est le premier appareil. L’une de ces deux comparaisons est presque toujours décisive.

Terminez d’abord toute connexion réseau légitime, car un portail captif ressemble à un blocage tant qu’il n’est pas terminé.

Testez le port que vous utilisez réellement, et traitez un résultat TCP comme une information sur TCP uniquement.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Une poignée de main TCP réussie sur le port 443 indique qu’un écouteur y a répondu. Elle ne dit rien sur un écouteur UDP sur le port 51820, ni sur la fin de la négociation.

Étape 3 : lire les événements de sécurité au moment de la panne

Les événements du pare-feu sont la preuve la plus solide disponible, et ils portent une réserve qu’il vaut la peine d’énoncer d’abord. La journalisation est désactivée dans de nombreux profils par défaut, vérifiez donc si le profil concerné journalise les rejets avant de lire un journal vide comme preuve d’innocence. Quand la journalisation est active, l’événement nomme la règle, la direction et les adresses, ce qui est exactement ce dont un changement de règle a besoin. Les règles d’application et les règles de port sont des objets distincts, et une politique gérée peut supplanter un réglage local. Confirmez quel client et quel service une règle couvre réellement.

Recueillez l’état du profil et les événements récents sur la machine qui a échoué, pas sur un hôte voisin.

Comparez l’heure de l’événement à l’heure de votre tentative de test, car un nom de règle identique avec un horodatage différent est une coïncidence.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Sur un serveur que vous administrez, demandez si la requête a seulement atteint l’écouteur. Un paquet qui arrive sans réponse est un problème de redirection ou de route de retour. Une requête qui n’apparaît jamais est un problème de filtrage ou d’adressage.

Étape 4 : tester la redirection une fois le tunnel monté

Un pare-feu peut autoriser la session et refuser tout ce que la session veut atteindre. Les sysctl de redirection, les règles NAT et les routes de retour se situent tous après l’authentification, et une exemption large pour le port du VPN n’en répare aucune. Testez une destination interne et une destination internet séparément, car elles échouent généralement pour des raisons différentes. Si les noms internes échouent mais que les adresses fonctionnent, regardez le DNS poussé avant toute règle.

Exécutez les trois contrôles ci-dessous sur le serveur pendant qu’un client est connecté et tente la requête qui échoue.

Les compteurs de l’interface du tunnel sont le point clé, car ils montrent si des paquets sont entrés et si quelque chose est sorti.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Quand des paquets arrivent sur le tunnel et que rien ne sort vers la destination, le suspect est la redirection ou le NAT. Quand rien n’arrive, la session est montée mais le client n’envoie pas, et l’endroit à regarder est la table de routage du client.

Vérifier le correctif et retirer ce qui n’a pas aidé

Après une correction approuvée, répétez exactement le test qui a échoué et consignez le résultat pour le même profil et le même appareil. Retirez ensuite toute exception temporaire qui n’a pas changé le résultat, car les exceptions inutilisées s’accumulent et chacune est une décision dont personne ne se souvient. Gardez ce qui reste étroit : une destination, un port, une direction, un responsable.

Réexécutez les trois mêmes commandes et comparez-les aux sorties que vous avez enregistrées avant le changement.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Quand le réseau de comparaison fonctionne, que le réseau d’origine échoue encore et que les événements restent vides, le suspect restant est le chemin et non l’hôte. Transmettez-le au responsable réseau comme une affirmation précise, avec les deux résultats de comparaison joints. C’est un meilleur point d’arrêt qu’un profil de pare-feu désactivé.