Connecté à OpenVPN mais aucun ping ni partage SMB ? Vérifiez trois portes

Le tunnel monte, le client obtient une adresse, et rien sur le LAN distant ne répond. Le ping échoue, le partage ne s’ouvre pas, et le journal du VPN paraît propre parce que, de son point de vue, la session est saine. Trois portes indépendantes se dressent entre cette session et un fichier sur un serveur : la politique de transfert, les ports dont le service a besoin et le nom que vous avez saisi à la place d’une adresse.

Chaque porte échoue avec un symptôme différent, et seule la première se trouve sur le serveur VPN.

Le transfert est une politique de la chaîne FORWARD

L’acceptation de l’écouteur OpenVPN a lieu sur INPUT, c’est pourquoi le tunnel peut se connecter alors que chaque paquet destiné au LAN est rejeté. Le trafic qui arrive sur tun0 et sort par l’interface du LAN traverse FORWARD, et un hôte dont la politique par défaut est DROP le jette silencieusement. Vérifiez à la fois le sysctl et la chaîne avant de toucher à quoi que ce soit d’autre : sysctl net.ipv4.ip_forward et iptables -L FORWARD -v -n.

Autorisez la direction que vous voulez et les réponses qui lui appartiennent, par exemple une règle accept de l’interface du tunnel vers l’interface du LAN plus une règle stateful pour le trafic established et related. Si le LAN se trouve derrière un autre routeur, ce routeur a besoin d’une route de retour vers le pool de clients ou d’un source NAT sur le serveur VPN. Confirmez ce chemin avec un seul ping avant d’ajouter d’autres règles, car une règle qu’on ne peut pas atteindre n’apparaît jamais dans un compteur.

SMB a besoin de plus d’un port

Le partage de fichiers n’est pas une seule conversation TCP 445. La découverte utilise UDP 137 et 138, les anciennes sessions NetBIOS utilisent TCP 139 et les sessions SMB modernes utilisent TCP 445. Une règle qui n’ouvre que 445 produit le cas exaspérant où un lecteur mappé fonctionne et la navigation sur le réseau non, ou l’inverse.

Les gros transferts par un tunnel rencontrent aussi des problèmes de MSS qui ressemblent à un partage cassé. Un SYN qui annonce la taille de segment complète du LAN est rejeté par le MTU plus petit du tunnel, et la connexion reste bloquée après la poignée de main. Le bridage du MSS sur le chemin de transfert, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, élimine cette catégorie de blocage. Vérifiez avec une copie de quelques mégaoctets plutôt qu’avec une liste de répertoire, car les petites réponses passent même quand les gros transferts ne passent pas.

L’adaptateur du tunnel arrive comme un nouveau profil réseau

Windows classe chaque adaptateur dans un profil réseau, et un adaptateur de tunnel neuf atterrit généralement dans Public, où les règles de partage de fichiers et d’imprimantes sont bloquées. C’est une décision du pare-feu de l’hôte sur le serveur de fichiers, pas un problème de routage sur le serveur VPN. Changez la catégorie délibérément avec Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private après avoir confirmé que la politique l’autorise, car la catégorie change aussi quelles règles entrantes s’appliquent.

Le même profil explique un ping qui échoue alors que TCP 445 réussit : les requêtes d’écho sont rejetées dans Public par défaut.

Les noms ne traversent pas seuls un tunnel routé

La résolution de noms NetBIOS et la découverte locale reposent sur des diffusions qu’un tunnel routé ne transporte pas. Saisir le nom court du serveur échoue donc alors que son adresse fonctionne, et le partage paraît cassé alors que seule la résolution l’est. Ajoutez un enregistrement DNS pour le serveur sur le résolveur que le tunnel distribue, ou utilisez l’adresse dans le raccourci.

Si le déploiement dépend encore de WINS, configurez-le sur le client plutôt que d’espérer voir apparaître du trafic de diffusion. Testez d’abord par adresse pour qu’une défaillance de nom ne soit pas prise pour une défaillance de pare-feu.

Testez une couche à la fois et lisez la première défaillance

Remontez : faites un ping sur la passerelle du tunnel, un ping sur un hôte du LAN par adresse, puis ouvrez le port du service avec Test-NetConnection -ComputerName 10.8.0.5 -Port 445, et seulement ensuite authentifiez-vous sur le partage. La première étape qui échoue est la couche à corriger, et chaque étape suivante n’est que du bruit jusqu’à ce qu’elle passe. Un ping qui répond alors que le port reste fermé désigne le pare-feu propre au serveur de fichiers, tandis qu’un port qui s’ouvre malgré des pings silencieux désigne un filtrage ICMP. Notez la première étape en échec avant de changer quoi que ce soit, car un second changement masque le résultat du premier.

Si le serveur VPN n’est pas le routeur du LAN, confirmez la route de retour sur ce routeur avant d’ajouter d’autres règles au serveur. Sans elle, les requêtes atteignent l’hôte et les réponses sortent par la route par défaut vers internet, ce qui ressemble exactement, côté client, à un rejet du pare-feu.

Gardez le compte du partage séparé de la connexion VPN dans vos notes, car un tunnel réussi ne dit rien des permissions de fichiers. Exposer SMB à internet pour contourner une règle manquante n’est pas une solution.