RRAS DHCP: um endereço novo ou apenas opções de configuração?

Ler um DHCPACK numa captura como prova de que o cliente VPN obteve o endereço do DHCP é um erro. Normalmente isso prova apenas que alguma mensagem DHCP foi respondida. O Windows RRAS pode distribuir endereços de sessão a partir do seu próprio pool estático enquanto o DHCP continua a fornecer opções ao cliente conectado. O tipo de pedido diz qual das duas tarefas estava em curso.

Duas tarefas que partilham um tipo de mensagem

O DHCP faz duas coisas distintas, e ambas partilham tipos de mensagem. Uma é atribuir um endereço e uma concessão. A outra é entregar configuração a um anfitrião que já tem um endereço, o que a RFC 2131 chama de DHCPINFORM. A resposta no segundo caso leva opções e nenhum tempo de concessão.

Portanto, um ACK é prova de uma resposta, não prova de uma atribuição. A mensagem que o antecedeu decide que pergunta foi feita. Leia primeiro a linha do pedido e o resto da captura normalmente explica-se sozinho.

De onde o RRAS tira o endereço

O RRAS é dono da decisão do endereço VPN através do método de atribuição IPv4 configurado: ou um servidor DHCP, ou um pool de endereços estático. Quando o pool é estático, o pool é o atribuidor, e uma reserva num servidor DHCP separado não tem voz nessa sessão. Os dois mecanismos podem coexistir na mesma rede sem que nenhum controle o outro.

Get-Command -Module RemoteAccess *IPAddress*

Descubra o método de atribuição em vigor antes de investigar o endereço. Se for um pool estático, o âmbito DHCP é o lugar errado para procurar. O comando acima lista os cmdlets disponíveis na versão que executa, e isso basta para encontrar a definição.

O que uma classe de utilizador pode e não pode provar

Uma classe de utilizador DHCP é uma cadeia que o cliente envia, não uma pertença a grupo autenticada. Mesmo quando um cliente envia uma e o servidor aplica uma política sobre ela, o rótulo só prova que a cadeia chegou. A RFC 3004 diz claramente que a opção não autentica o direito à classe.

Não espere que um nome de utilizador VPN, um identificador de grupo de segurança ou o endereço Ethernet do portátil apareçam nesse pedido de forma utilizável. São factos de autenticação e de diretório, e o pedido DHCP não transporta nenhum dos dois. Se o requisito é distinguir pessoas autorizadas, aplique-o na política VPN, onde a identidade existe de facto. Essa separação é a razão pela qual os dois sistemas continuam independentes.

Compare as provas, não o ACK

Construa a cadeia de provas em vez de ler um único pacote. Registe o endereço que a sessão recebeu, o tipo e os campos do pedido, as opções devolvidas pelo servidor e, depois, a configuração efetiva do cliente. Cada elo responde a uma pergunta diferente, e o elo em falta é onde o defeito real costuma estar.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Se o endereço veio do pool do RRAS, uma reserva DHCP não explica nada. Se as opções chegaram mas o cliente as ignorou, o servidor fez o seu trabalho e a configuração do cliente é a próxima paragem. Compare esses dois resultados de forma explícita e o ACK deixa de ser ambíguo. Duas capturas, uma por cada método de atribuição, resolvem a discussão mais depressa do que qualquer documentação.