RRAS DHCP : une nouvelle adresse ou de simples options de configuration ?

Lire un DHCPACK dans une capture comme la preuve que le client VPN a obtenu son adresse auprès de DHCP est une erreur. Le plus souvent, cela prouve seulement qu’un message DHCP a reçu une réponse. Windows RRAS peut distribuer les adresses de session depuis son propre pool statique tandis que DHCP fournit encore les options au client connecté. Le type de requête vous dit laquelle des deux tâches était en cours.

Deux tâches qui partagent un type de message

DHCP fait deux choses distinctes, et elles partagent des types de message. L’une consiste à attribuer une adresse et un bail. L’autre consiste à livrer une configuration à un hôte qui possède déjà une adresse, ce que la RFC 2131 appelle DHCPINFORM. La réponse du second cas porte des options et aucun temps de bail.

Un ACK est donc la preuve d’une réponse, pas celle d’une attribution. Le message qui le précède décide quelle question a été posée. Lisez d’abord la ligne de requête et le reste de la trace s’explique généralement seul.

Où RRAS prend-il l’adresse

RRAS possède la décision d’adresse VPN par sa méthode d’attribution IPv4 configurée : soit un serveur DHCP, soit un pool d’adresses statique. Quand le pool est statique, le pool est l’attributaire, et une réservation sur un serveur DHCP distinct n’a pas voix au chapitre dans cette session. Les deux mécanismes peuvent coexister sur le même réseau sans que l’un contrôle l’autre.

Get-Command -Module RemoteAccess *IPAddress*

Identifiez la méthode d’attribution en vigueur avant de chercher la panne d’adresse. S’il s’agit d’un pool statique, l’étendue DHCP est le mauvais endroit où regarder. La commande ci-dessus liste les cmdlets disponibles sur la version que vous exécutez, et cela suffit pour trouver le réglage.

Ce qu’une classe d’utilisateur peut prouver et ce qu’elle ne peut pas

Une classe d’utilisateur DHCP est une chaîne que le client envoie, pas une appartenance à un groupe authentifiée. Même lorsqu’un client en envoie une et que le serveur applique une stratégie dessus, l’étiquette prouve seulement que la chaîne est arrivée. La RFC 3004 dit clairement que l’option n’authentifie pas le droit à la classe.

N’attendez pas qu’un nom d’utilisateur VPN, un identifiant de groupe de sécurité ou l’adresse Ethernet de l’ordinateur portable apparaissent dans cette requête sous une forme exploitable. Ce sont des faits d’authentification et d’annuaire, et la requête DHCP ne porte ni l’un ni l’autre. Si l’exigence est de distinguer les personnes autorisées, appliquez-la dans la stratégie VPN, là où l’identité existe réellement. Cette séparation est la raison pour laquelle les deux systèmes restent indépendants.

Comparez les preuves, pas l’ACK

Construisez la chaîne de preuves au lieu de lire un seul paquet. Notez l’adresse reçue par la session, le type et les champs de la requête, les options renvoyées par le serveur, puis la configuration effective du client. Chaque maillon répond à une question différente, et le maillon manquant est là où se trouve généralement la vraie panne.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Si l’adresse vient du pool RRAS, une réservation DHCP n’explique rien. Si les options sont arrivées mais que le client les a ignorées, le serveur a fait son travail et la configuration du client est l’étape suivante. Comparez explicitement ces deux issues et l’ACK cesse d’être ambigu. Deux traces, une par méthode d’attribution, tranchent le débat plus vite que n’importe quelle documentation.