RRAS DHCP: un enderezo novo ou só opcións de configuración?

Ler un DHCPACK nunha captura como proba de que o cliente VPN obtivo o seu enderezo de DHCP é un erro. Normalmente só demostra que se respondeu algunha mensaxe DHCP. Windows RRAS pode repartir enderezos de sesión desde o seu propio grupo estático mentres DHCP segue subministrando opcións ao cliente conectado. O tipo de solicitude dille cal das dúas tarefas estaba a ocorrer.

Dúas tarefas que comparten un tipo de mensaxe

DHCP fai dúas cousas separadas e ambas comparten tipos de mensaxe. Unha é asignar un enderezo e un arrendamento. A outra é entregar configuración a un equipo que xa ten un enderezo, o que a RFC 2131 chama DHCPINFORM. A resposta no segundo caso leva opcións e ningún tempo de arrendamento.

Así que un ACK é proba dunha resposta, non proba dunha asignación. A mensaxe que o precedeu decide que pregunta se fixo. Lea primeiro a liña de solicitude e o resto da traza normalmente explícase só.

De onde obtén RRAS o enderezo

RRAS é dono da decisión do enderezo VPN mediante o seu método de asignación IPv4 configurado: ou un servidor DHCP ou un grupo de enderezos estático. Cando o grupo é estático, o grupo é o asignador, e unha reserva nun servidor DHCP á parte non ten nada que dicir nesa sesión. Os dous mecanismos poden convivir na mesma rede sen que ningún controle o outro.

Get-Command -Module RemoteAccess *IPAddress*

Atope o método de asignación vixente antes de depurar o enderezo. Se é un grupo estático, o ámbito DHCP é o lugar equivocado onde mirar. O comando anterior enumera os cmdlets dispoñibles na versión que executa, e iso abonda para atopar o axuste.

Que pode demostrar unha clase de usuario e que non

Unha clase de usuario DHCP é unha cadea que envía o cliente, non unha pertenza a grupo autenticada. Mesmo cando un cliente envía unha e o servidor aplica unha política sobre ela, a etiqueta só demostra que a cadea chegou. A RFC 3004 di claramente que a opción non autentica o dereito á clase.

Non espere que un nome de usuario VPN, un identificador de grupo de seguridade ou o enderezo Ethernet do portátil aparezan nesa solicitude nunha forma utilizábel. Son feitos de autenticación e de directorio, e a solicitude DHCP non leva ningún dos dous. Se o requisito é distinguir persoas autorizadas, aplíqueo na política VPN, onde a identidade existe de verdade. Esa separación é a razón pola que os dous sistemas seguen independentes.

Compare as probas, non o ACK

Constrúa a cadea de probas en lugar de ler un só paquete. Anote o enderezo que recibiu a sesión, o tipo e os campos da solicitude, as opcións que devolveu o servidor e a configuración efectiva do cliente despois. Cada elo responde a unha pregunta distinta, e o elo que falta adoita ser onde está a falla real.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Se o enderezo veu do grupo de RRAS, unha reserva DHCP non explica nada. Se as opcións chegaron pero o cliente ignorounas, o servidor fixo o seu traballo e a configuración do cliente é a seguinte parada. Compare eses dous resultados de forma explícita e o ACK deixa de ser ambiguo. Dúas trazas, unha por cada método de asignación, resolven a discusión máis rápido ca calquera documentación.