Les clients VPN de RRAS ont besoin de leur propre pool IPv4 et d’un chemin de retour

Le client VPN se connecte et reçoit une adresse, mais l’hôte du LAN dont il a besoin ne peut toujours pas lui répondre. Dans Windows Routing and Remote Access, l’adresse interne des clients VPN provient d’un pool configuré séparément de l’adaptateur LAN du serveur, et le côté LAN a besoin d’une route de retour vers ce pool. Deux changements, pas un, et ils échouent de manières différentes. Traitez-les dans l’ordre pour que le plan d’adressage et le chemin de retour soient prouvés avant le retrait des anciennes plages.

Réservez la plage avant d’ouvrir la console

Choisissez un préfixe qui ne chevauche ni le LAN, ni d’autres plages VPN, ni quoi que ce soit routé vers le site. Un /24 est une taille pratique pour un test, et la première partie utilisable peut être confiée aux clients tandis que le reste demeure libre pour la croissance. Notez-le avec son objectif et son propriétaire avant de le saisir dans une console. Laissez de la place aux deux extrémités du bloc pour qu’une division ultérieure n’impose pas de renumérotation.

Un plan d’adressage qui ne vit que dans une console est à une reconstruction d’une collision. Il tend aussi à grossir : quelqu’un ajoute une seconde plage plus tard et personne ne vérifie la première. Gardez le plan à côté de la documentation du serveur, pas dans un fil de discussion.

L’adaptateur LAN du serveur ne définit pas ce pool. Changer l’écouteur public ou ajouter un adaptateur au LAN fait quelque chose de tout autre. C’est pourquoi les clients peuvent se connecter et recevoir malgré tout une adresse du mauvais endroit. Le pool vit dans les propriétés IPv4 du serveur, pas dans la liste des adaptateurs.

Changer de méthode n’est pas ajouter une plage

RRAS dispose d’une méthode d’attribution et d’un ensemble de plages. Passer de DHCP à un pool statique est un changement de méthode. Ajouter un autre bloc alors que le pool statique est déjà actif est un changement de plage.

Prévisualisez les deux opérations avant d’en exécuter une, et lisez laquelle correspond à l’état actuel du serveur :

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

La seconde cmdlet échoue ou produit un pool inutilisable si le serveur est encore en attribution DHCP. La première remplace la méthode au lieu d’étendre un pool existant. Aucune des deux prévisualisations n’applique quoi que ce soit, exécutez donc celle qui correspond, puis confirmez le pool obtenu dans la console. Si vous n’êtes pas sûr de l’état du serveur, lisez la méthode d’attribution sur la page des propriétés IPv4 et listez les plages configurées :

Get-VpnIPAddressRange

Une méthode DHCP avec une liste de plages vide signifie que la première prévisualisation s’applique. Un pool d’adresses statique avec une plage existante signifie que la seconde s’applique.

Tenez compte du redémarrage du service que le paramètre peut exiger, et ne supposez pas que les clients connectés sont renumérotés immédiatement. Un client qui garde son ancienne adresse jusqu’à sa reconnexion se comporte normalement. Planifiez le changement pour une fenêtre où une reconnexion est acceptable.

Le LAN a besoin d’une route de retour

Supposons que le LAN soit 10.60.0.0/24 et que le serveur RRAS soit 10.60.0.10 sur celui-ci. Un hôte de ce LAN qui répond à un client de 10.250.50.0/24 a besoin d’un chemin vers le pool via le serveur RRAS. Sans ce chemin, la requête arrive et la réponse meurt.

Si la passerelle par défaut de l’hôte est un autre routeur, ce routeur a besoin de la route de retour pour le préfixe VPN. Une route statique sur le serveur RRAS n’aide pas ici ; le chemin de retour doit exister sur l’appareil qui possède la passerelle du LAN, ajoutez-le donc à la table de routage ou au processus de routage dynamique, selon ce que le site utilise.

Vérifiez aussi le pare-feu de l’hôte et toute règle d’accès réseau contre la nouvelle plage source. Les règles écrites pour l’ancienne plage de clients rejettent la nouvelle même si l’attribution a réussi. Les routes du client vers le LAN et la résolution DNS sont des exigences distinctes, et les deux peuvent échouer alors que le tunnel semble sain. Testez chacune séparément.

Prouvez le nouveau pool sur un seul appareil avant de retirer l’ancien

Prenez une autorisation que vous contrôlez, reconnectez-vous et lisez l’adresse de pool reçue par le client. Ce seul nombre sépare l’attribution du routage. Exercez ensuite une application nommée, observez le trafic de retour et essayez une destination qui doit rester refusée. Trois observations, trois modes de défaillance différents.

La résolution de noms mérite son propre test : l’accès par IP peut fonctionner alors que le DNS du client pointe encore vers un résolveur qu’il ne peut pas joindre. Un serveur DNS du LAN n’est joignable que si le client a une route vers lui et que le serveur accepte les requêtes de la nouvelle plage. Les deux sont des oublis fréquents lors du déplacement du pool.

Retirez les anciennes plages et leurs exceptions seulement après avoir tenu compte des sessions actives et du processus de maintenance. Un client connecté avec une nouvelle adresse prouve l’attribution, pas la politique d’accès. Gardez l’ancienne plage documentée jusqu’à l’expiration de la dernière session qui l’a utilisée.

Vérifiez le résultat avec trois observations

L’acceptation exige trois faits : le client a une adresse du nouveau pool, un hôte du LAN peut l’atteindre et obtenir une réponse, et une destination refusée reste refusée. Chacun a son propre contrôle, un échec pointe donc vers l’attribution, le routage ou la politique. Exécutez-les dans cet ordre.

Depuis le client, confirmez l’adresse et la route vers un hôte du LAN :

ipconfig | findstr /i "IPv4"
route print -4

Depuis l’hôte du LAN, confirmez le chemin de retour et la politique en une seule passe. Si ping échoue mais que l’application fonctionne, la pièce manquante est probablement une règle ICMP et non la route. Si les deux échouent, lisez la route sur l’hôte avant de modifier le VPN. Notez les trois résultats dans le ticket de changement pour que la personne suivante parte des preuves.