RRAS DHCP: ¿una dirección nueva o solo opciones de configuración?

Leer un DHCPACK en una captura como prueba de que el cliente VPN obtuvo su dirección de DHCP es un error. Normalmente solo demuestra que se respondió algún mensaje DHCP. Windows RRAS puede repartir direcciones de sesión desde su propio grupo estático mientras DHCP sigue suministrando opciones al cliente conectado. El tipo de solicitud le dice cuál de las dos tareas estaba ocurriendo.

Dos tareas que comparten un tipo de mensaje

DHCP hace dos cosas distintas y ambas comparten tipos de mensaje. Una es asignar una dirección y un arrendamiento. La otra es entregar configuración a un host que ya tiene una dirección, lo que la RFC 2131 llama DHCPINFORM. La respuesta del segundo caso lleva opciones y ningún tiempo de arrendamiento.

Así que un ACK es prueba de una respuesta, no prueba de una asignación. El mensaje que lo precedió decide qué pregunta se hizo. Lea primero la línea de solicitud y el resto de la traza normalmente se explica solo.

De dónde obtiene RRAS la dirección

RRAS es dueño de la decisión de la dirección VPN mediante su método de asignación IPv4 configurado: o bien un servidor DHCP o bien un grupo de direcciones estático. Cuando el grupo es estático, el grupo es el asignador, y una reserva en un servidor DHCP aparte no tiene nada que decir en esa sesión. Los dos mecanismos pueden coexistir en la misma red sin que ninguno controle al otro.

Get-Command -Module RemoteAccess *IPAddress*

Encuentre el método de asignación vigente antes de depurar la dirección. Si es un grupo estático, el ámbito DHCP es el lugar equivocado donde mirar. El comando anterior enumera los cmdlets disponibles en la versión que ejecuta, y eso basta para encontrar el ajuste.

Qué puede demostrar una clase de usuario y qué no

Una clase de usuario DHCP es una cadena que envía el cliente, no una pertenencia a grupo autenticada. Incluso cuando un cliente envía una y el servidor aplica una directiva sobre ella, la etiqueta solo demuestra que la cadena llegó. La RFC 3004 dice claramente que la opción no autentica el derecho a la clase.

No espere que un nombre de usuario VPN, un identificador de grupo de seguridad o la dirección Ethernet del portátil aparezcan en esa solicitud de forma utilizable. Son hechos de autenticación y de directorio, y la solicitud DHCP no lleva ninguno de los dos. Si el requisito es distinguir personas autorizadas, aplíquelo en la directiva VPN, donde la identidad existe de verdad. Esa separación es la razón por la que los dos sistemas siguen siendo independientes.

Compare las pruebas, no el ACK

Construya la cadena de pruebas en lugar de leer un solo paquete. Anote la dirección que recibió la sesión, el tipo y los campos de la solicitud, las opciones que devolvió el servidor y la configuración efectiva del cliente después. Cada eslabón responde a una pregunta distinta, y el eslabón que falta es donde suele estar la falla real.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Si la dirección vino del grupo de RRAS, una reserva DHCP no explica nada. Si las opciones llegaron pero el cliente las ignoró, el servidor hizo su trabajo y la configuración del cliente es la siguiente parada. Compare esos dos resultados de forma explícita y el ACK deja de ser ambiguo. Dos trazas, una por cada método de asignación, zanjan la discusión más rápido que cualquier documentación.