RRAS DHCP: una adreça nova o només opcions de configuració?

Llegir un DHCPACK en una captura com a prova que el client VPN va rebre l’adreça del DHCP és un error. Normalment només demostra que algun missatge DHCP va obtenir resposta. Windows RRAS pot repartir adreces de sessió del seu propi conjunt estàtic mentre DHCP encara subministra opcions al client connectat. El tipus de petició us diu quina de les dues feines s’estava fent.

Dues feines que comparteixen un tipus de missatge

El DHCP fa dues coses separades, i comparteixen tipus de missatge. Una és assignar una adreça i un arrendament. L’altra és lliurar configuració a un equip que ja té una adreça, cosa que la RFC 2131 anomena DHCPINFORM. La resposta del segon cas porta opcions i cap temps d’arrendament.

Per tant, un ACK és prova d’una resposta, no prova d’una assignació. El missatge que el precedeix decideix quina pregunta es va fer. Llegiu primer la línia de petició i la resta de la traça normalment s’explica sola.

D’on obté RRAS l’adreça

RRAS és l’amo de la decisió de l’adreça VPN mitjançant el mètode d’assignació IPv4 que tingui configurat: o bé un servidor DHCP o bé un conjunt d’adreces estàtic. Quan el conjunt és estàtic, el conjunt és l’assignador, i una reserva en un servidor DHCP a part no hi té res a dir en aquesta sessió. Els dos mecanismes poden conviure a la mateixa xarxa sense que cap controli l’altre.

Get-Command -Module RemoteAccess *IPAddress*

Trobeu el mètode d’assignació vigent abans de depurar l’adreça. Si és un conjunt estàtic, l’àmbit DHCP és el lloc equivocat on mirar. L’ordre anterior llista els cmdlets disponibles a la versió que executeu, i això ja és prou per trobar el paràmetre.

Què pot demostrar una classe d’usuari i què no

Una classe d’usuari DHCP és una cadena que envia el client, no una pertinença a grup autenticada. Fins i tot quan un client n’envia una i el servidor hi aplica una política, l’etiqueta només demostra que la cadena va arribar. La RFC 3004 diu clarament que l’opció no autentica el dret a la classe.

No espereu que un nom d’usuari VPN, un identificador de grup de seguretat o l’adreça Ethernet de l’ordinador portàtil apareguin en aquesta petició en una forma utilitzable. Són fets d’autenticació i de directori, i la petició DHCP no porta ni l’un ni l’altre. Si el requisit és distingir persones autoritzades, apliqueu-lo a la política VPN, on la identitat existeix de veritat. Aquesta separació és la raó per la qual els dos sistemes es mantenen independents.

Compareu les proves, no l’ACK

Construïu la cadena de proves en lloc de llegir un sol paquet. Anoteu l’adreça que va rebre la sessió, el tipus i els camps de la petició, les opcions que va retornar el servidor i la configuració efectiva del client després. Cada baula respon una pregunta diferent, i la baula que falta és on sol haver-hi la falla real.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Si l’adreça va venir del conjunt de RRAS, una reserva DHCP no explica res. Si les opcions van arribar però el client les va ignorar, el servidor va fer la seva feina i la següent parada és la configuració del client. Compareu aquests dos resultats explícitament i l’ACK deixa de ser ambigu. Dues traces, una per cada mètode d’assignació, tanquen la discussió més de pressa que qualsevol documentació.