RRAS DHCP: un nuovo indirizzo o solo opzioni di configurazione?

Leggere un DHCPACK in una cattura come prova che il client VPN ha ottenuto il suo indirizzo da DHCP è un errore. Di solito prova solo che a un qualche messaggio DHCP è stata data risposta. Windows RRAS può distribuire indirizzi di sessione dal proprio pool statico mentre DHCP continua a fornire opzioni al client connesso. Il tipo di richiesta dice quale delle due attività era in corso.

Due attività che condividono un tipo di messaggio

DHCP fa due cose distinte e condividono i tipi di messaggio. Una è assegnare un indirizzo e una lease. L’altra è consegnare la configurazione a un host che ha già un indirizzo, cosa che la RFC 2131 chiama DHCPINFORM. La risposta nel secondo caso porta opzioni e nessun tempo di lease.

Quindi un ACK è prova di una risposta, non prova di un’assegnazione. Il messaggio che lo precede decide quale domanda è stata posta. Leggete prima la riga di richiesta e il resto della traccia di solito si spiega da sé.

Da dove RRAS prende l’indirizzo

RRAS possiede la decisione sull’indirizzo VPN tramite il metodo di assegnazione IPv4 configurato: o un server DHCP o un pool di indirizzi statico. Quando il pool è statico, il pool è l’assegnatore, e una prenotazione su un server DHCP separato non ha voce in capitolo in quella sessione. I due meccanismi possono convivere sulla stessa rete senza che uno controlli l’altro.

Get-Command -Module RemoteAccess *IPAddress*

Trovate il metodo di assegnazione in vigore prima di cercare la causa nell’indirizzo. Se è un pool statico, l’ambito DHCP è il posto sbagliato dove guardare. Il comando sopra elenca i cmdlet disponibili nella versione che eseguite, e questo basta per trovare l’impostazione.

Che cosa una classe utente può provare e che cosa no

Una classe utente DHCP è una stringa che il client invia, non un’appartenenza a gruppo autenticata. Anche quando un client ne invia una e il server applica una politica su di essa, l’etichetta prova solo che la stringa è arrivata. La RFC 3004 dice chiaramente che l’opzione non autentica il diritto alla classe.

Non aspettatevi che un nome utente VPN, un identificatore di gruppo di sicurezza o l’indirizzo Ethernet del portatile compaiano in quella richiesta in una forma utilizzabile. Sono fatti di autenticazione e di directory, e la richiesta DHCP non porta né l’uno né l’altro. Se il requisito è distinguere le persone autorizzate, applicatelo nella politica VPN, dove l’identità esiste davvero. Questa separazione è la ragione per cui i due sistemi restano indipendenti.

Confrontate le prove, non l’ACK

Costruite la catena di prove invece di leggere un solo pacchetto. Annotate l’indirizzo ricevuto dalla sessione, il tipo e i campi della richiesta, le opzioni restituite dal server e la configurazione effettiva del client in seguito. Ogni anello risponde a una domanda diversa, e l’anello mancante è di solito dove si trova il guasto reale.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Se l’indirizzo è arrivato dal pool RRAS, una prenotazione DHCP non spiega nulla. Se le opzioni sono arrivate ma il client le ha ignorate, il server ha fatto il suo lavoro e la configurazione del client è la tappa successiva. Confrontate esplicitamente questi due esiti e l’ACK smette di essere ambiguo. Due tracce, una per ciascun metodo di assegnazione, chiudono la discussione più in fretta di qualsiasi documentazione.