L’adaptateur VPN affiche /32 : ce n’est pas une seule destination

Les adaptateurs affichent 255.255.255.255, et la conclusion est souvent que le VPN joint exactement une adresse. Cette lecture confond l’adresse du client lui-même avec l’ensemble des destinations routées par le tunnel. Sur une interface point à point ou routée, les deux sont des objets différents, et un seul limite l’accessibilité. Le mythe perdure parce que le masque ressemble au masque de sous-réseau appris sur Ethernet.

Le mythe : un masque d’hôte signifie un seul hôte joignable

Une attribution /32 indique à l’interface quelle adresse appartient à cette extrémité du lien, et sur une liaison point à point c’est tout ce qu’elle signifie. L’adresse du pair est un champ distinct, et les routes qui disent ce qui se trouve au-delà du pair le sont tout autant. Rien dans le masque ne décrit le réseau distant, car le masque n’est pas l’endroit où l’on décrit les réseaux distants. Le lire comme une limite de portée revient à lire le numéro de sa propre maison comme la liste de toutes les adresses qu’on a le droit de visiter.

La confusion a une racine réelle : sur Ethernet, un masque d’hôte signifierait bien une seule adresse sur ce segment. Un tunnel n’est pas un segment Ethernet, et c’est la table de routage du client, non le masque, qui décide de ce qui y passe. C’est pourquoi le même /32 peut se trouver devant tout un centre de données.

Lisez l’adresse et les routes comme des objets distincts

Affichez l’interface et la table ensemble, puis lisez-les comme deux réponses à deux questions. L’adresse répond qui est cette extrémité ; les routes répondent où le trafic peut aller. Une troisième question, quelles destinations la passerelle autorise, n’est pas visible du tout sur le client. La référence d’adressage d’iproute2 décrit séparément les champs d’adresse locale, de pair et de route de préfixe précisément pour cette raison.

ip addr show tun0
ip route show
ip route get 10.60.5.10

Sous Windows, la même séparation existe entre la liste d’adresses et la table de routage, et la commande de recherche est le moyen le plus rapide de voir laquelle l’emporte pour une destination donnée. Si la recherche renvoie l’interface du tunnel, le client y enverra le paquet. Si elle renvoie l’adaptateur physique, le client n’interroge jamais le VPN, et aucune autorisation côté serveur n’y changera rien. Vérifiez la destination dont vous avez réellement besoin, pas une adresse publique générique.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Arrêtez-vous si la recherche pointe vers la mauvaise interface. C’est un problème de routage du client, et il se corrige sur le client.

Pourquoi élargir le masque aggrave généralement les choses

Passer l’attribution à un /24 pour ressembler au LAN du bureau peut créer un préfixe sur le lien : le noyau croit désormais que tout le /24 est directement rattaché à l’interface du tunnel. Le trafic vers des adresses qui devraient être routées par la passerelle est alors envoyé comme si un voisin se trouvait sur le lien. Le résultat est un trou noir qui ressemble à une panne de serveur.

Cela masque aussi le vrai problème, à savoir une route manquante ou une autorisation manquante sur la passerelle. Aucun des deux n’est créé par un masque plus large, et les deux survivent au changement. Si la conception exige un préfixe plus grand sur l’interface, c’est une décision pour le modèle d’interface utilisé, prise avec la documentation en main. Copier un masque depuis les captures d’un autre produit n’est pas cette décision.

Si la route du préfixe distant manque, corrigez son provisionnement. Si elle est présente et que la connexion est toujours refusée, le masque n’a jamais été le diagnostic.

Quand la route est bonne et que le flux échoue encore

Une route correcte prouve seulement que le client enverra le paquet. La passerelle doit encore accepter la destination, le chemin de retour doit exister pour l’adresse attribuée, et le service doit autoriser le flux. Testez ces trois points séparément : la recherche sur le client, la portée autorisée de la passerelle et une requête vers un serveur nécessaire. Que l’authentification réussisse avant que les trois soient en place est normal, et c’est pourquoi un client connecté peut encore n’atteindre rien.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Gardez les objets réseau et les autorisations de groupe chez leur propriétaire sur un service géré par un équipement. Ce qu’on dit au client d’atteindre et ce qu’il est autorisé à utiliser sont des réglages différents, souvent sur des écrans différents. Changer l’un et tester l’autre, c’est ainsi qu’un ticket rebondit entre deux équipes.

Le mythe à retirer est que le masque soit une limite de portée. Lisez l’adresse, les routes et la politique de la passerelle comme trois faits distincts, et un /32 cesse de ressembler à une restriction et commence à ressembler à une attribution normale de tunnel.