Le VPN Windows affiche 255.255.255.255 : le masque est-il erroné ?
Sur un tunnel point à point, un masque d’hôte est normal. Confirmez le modèle d’interface, lisez la route de l’hôte qui échoue, puis séparez le DNS de l’accès au service.
Le tunnel se connecte, vous ouvrez les détails de l’adaptateur et le masque affiche 255.255.255.255. Comparé au 255.255.255.0 du LAN du bureau, cela semble cassé, et c’est généralement là que l’erreur commence. Sur une liaison point à point, un masque d’hôte est la description correcte de l’extrémité locale, et les réseaux distants arrivent sous forme de routes plutôt que de sous-réseau attaché. La procédure ci-dessous sépare les deux questions pour que vous ne reconstruisiez pas une étendue DHCP qui fonctionne juste pour corriger une valeur affichée.
Une liaison point à point n’est pas un segment Ethernet
Une interface Ethernet a besoin d’un masque de sous-réseau parce que chaque adresse de cette plage est potentiellement joignable sur le même câble. Un tunnel de type PPP a exactement un pair à l’autre extrémité. Il n’y a ni domaine de diffusion, ni ARP, ni raison pour que l’adresse locale décrive une plage.
La négociation d’adressage pour ce modèle est définie dans la RFC 1332, qui décrit comment les deux extrémités s’accordent sur leurs adresses. Ce qu’elle ne fait pas, c’est remettre au client le LAN du bureau comme réseau directement connecté. Le client apprend où se trouve le bureau en installant des routes via la liaison, et ce sont ces routes qui décident réellement de la joignabilité.
Cela ne signifie pas que tout masque que vous verrez est correct. Un client mal configuré peut aussi produire un adressage étrange. Le point est plus précis : un masque d’hôte sur ce type d’adaptateur est attendu, ce n’est donc pas en soi la preuve d’une panne.
Étape 1 : confirmez le modèle d’interface
Regardez ce qu’est l’adaptateur avant de juger ce qu’il affiche. La chaîne de description identifie le pilote, et la longueur de préfixe de l’adresse attribuée confirme ce que le client a négocié :
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuLa troisième commande est celle qui tranche la plupart des discussions. Une unité de transmission maximale basse est caractéristique d’une liaison encapsulée, alors qu’une valeur proche d’Ethernet suggère un autre modèle d’adaptateur virtuel. Si la description nomme un pilote PPP ou RAS et que le préfixe est 32, vous êtes exactement dans la conception décrite plus haut et pouvez cesser de vous inquiéter du masque.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
Étape 2 : lisez la route de la destination qui échoue
La joignabilité se décide par destination, et une seule interface connectée ne vous dit rien à ce sujet. Interrogez directement la table de routage, pour l’adresse que l’utilisateur cherche réellement à atteindre :
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute est la réponse directe : il nomme l’interface et l’adresse source que le système utiliserait pour cette destination. S’il renvoie le tunnel, le trafic vers cet hôte passe par le tunnel et le masque n’a jamais été le problème.
S’il renvoie l’adaptateur physique, comparez les deux routes candidates et leurs métriques. Une route locale plus spécifique, une entrée restée d’un autre client ou une métrique plus basse sur le chemin physique l’emporteront sur une route de tunnel large. Le résultat visible est une ressource injoignable alors que tout le reste fonctionne. Les préfixes plus longs gagnent toujours, donc le gagnant est souvent une route d’hôte que quelqu’un a ajoutée il y a des mois et oubliée.
Vérifiez aussi les deux sens pendant que vous y êtes. Une route vers le côté serveur est nécessaire mais pas suffisante, car la réponse doit aussi revenir par le tunnel. Quand un hôte interne fonctionne et qu’un autre non, la différence se trouve généralement dans cette table plutôt que dans la configuration de l’adaptateur.
Étape 3 : séparez la résolution de noms de l’accès au service
Une application qui n’ouvre pas un partage peut échouer à l’une de deux étapes très différentes. Résolvez le nom, puis atteignez l’adresse. Si la première échoue et que la seconde fonctionne, le tunnel va bien et le résolveur non :
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445Un test d’adresse réussi associé à un test de nom en échec localise le problème dans la résolution, et la deuxième commande montre si l’interface du tunnel a reçu un serveur. Beaucoup de clients poussent le DNS dans la configuration du tunnel, et un profil qui ignore ces options laissera la machine utiliser un résolveur qui ne voit pas la zone privée.
Ne considérez pas une adresse qui fonctionne comme le correctif définitif. Se connecter par adresse contourne la résolution de noms et peut neutraliser la vérification d’identité du serveur que l’application ferait sinon. C’est une régression de sécurité déguisée en contournement. Utilisez-la pour localiser la panne, puis réparez la résolution.
Retour arrière : ne reconstruisez pas le DHCP pour une valeur affichée
Si vous avez déjà commencé à modifier le service d’adressage, arrêtez-vous et vérifiez si l’un de vos changements est porteur. Recréer une étendue, réémettre des baux ou déplacer le pool modifie un état dont dépendent d’autres clients, et rien de tout cela n’est justifié par un masque d’hôte sur un adaptateur point à point.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445Exécutez ces trois commandes après toute modification ciblée et comparez avec l’exécution précédente. Le résultat utile est un chemin documenté vers la ressource, pas un adaptateur dont le masque ressemble au LAN du bureau.
Notez ensuite ce que le masque signifiait réellement, car la personne suivante ouvrira la même fenêtre et arrivera à la même conclusion erronée. Une phrase dans les notes du profil, indiquant que le tunnel est point à point et que les sous-réseaux distants arrivent sous forme de routes, épargne toute l’enquête la fois suivante.