Un gateway VPN che delega l'autenticazione a Windows NPS ha bisogno di un oggetto lato NPS prima che qualsiasi criterio utente possa funzionare: una voce di client RADIUS per il gateway. La maggior parte dei tentativi falliti registra l'indirizzo sbagliato, perché l'indirizzo che conta è quello che il gateway usa sul proprio percorso backend, non il nome host che il personale digita nella propria app VPN. Se quel valore è errato, NPS scarta la richiesta in silenzio, il che dal lato del client sembra una password sbagliata. Tre condizioni decidono quale indirizzo appartiene al campo, quindi risolvetele prima di aprire la console.

Registrate il gateway, non i portatili o il pool

L'oggetto client RADIUS rappresenta il dispositivo di accesso alla rete che invia le richieste di autenticazione. È il gateway VPN, non ogni portatile che esegue il client, e non l'intervallo di indirizzi assegnati all'interno dei tunnel.

Quegli indirizzi di tunnel non compaiono mai come origine di una richiesta RADIUS, perché la richiesta viaggia sul percorso di rete proprio del gateway. Registrare una voce di pool di client produce un criterio che non può mai corrispondere, mentre la richiesta reale arriva da un indirizzo che NPS non ha mai sentito. La stessa confusione porta ad aggiungere l'IP domestico di ogni dipendente, cosa che è insieme insostenibile e sbagliata.

Tre condizioni decidono l'indirizzo che inserite

Primo, trovate l'indirizzo di origine che il gateway usa davvero verso NPS. Un gateway con più interfacce invia spesso da un'interfaccia di gestione o backend invece che dal suo listener VPN pubblico. Secondo, verificate se c'è NAT tra i due: se la richiesta viene tradotta, NPS vede l'indirizzo tradotto, e quello è il valore da registrare. Terzo, se due gateway condividono il ruolo, ogni origine di richiesta ha bisogno della propria voce di client, perché un solo oggetto con un indirizzo ne copre solo uno.

Una scheda a due estremi tiene la coppia in ordine. La tabella seguente usa indirizzi privati per illustrazione, quindi sostituiteli con quelli che il vostro percorso usa davvero.

At NPSAt the VPN gateway
RADIUS client address 10.20.0.10Authentication server 10.20.0.20
Shared secret, agreed valueThe same secret, same value
UDP 1812 permitted from 10.20.0.10UDP 1812 permitted toward 10.20.0.20

Confermate l'origine invece di indovinarla. Osservate il log di NPS o del firewall durante un tentativo, oppure catturate sull'host NPS con sudo tcpdump -ni any udp port 1812. L'indirizzo in quella cattura è l'unica risposta difendibile per la voce di client. Se il gateway ha più origini possibili, registrate ciascuna con il proprio nome descrittivo.

Il segreto condiviso è un valore tra gateway e NPS

Il segreto condiviso autentica la relazione tra i dispositivi. Non è una password utente e non viene mai distribuito al personale né incorporato nei profili dei client.

Scegliete un valore, inseritelo in entrambi i punti e conservatelo dove vive il backup della configurazione del gateway. Una discordanza produce una richiesta che NPS scarta senza un errore utile, cosa che nel log del gateway non si distingue da un server irraggiungibile. Ruotatelo durante una finestra di manutenzione e aggiornate entrambi gli estremi nello stesso cambiamento.

Confermate con una richiesta consentita

Usate un account controllato e correlate un solo tentativo su entrambi i lati. Sul gateway, confermate che la richiesta è partita verso il server previsto; su NPS, che è arrivata dal client registrato e ha corrisposto al criterio di richiesta di connessione atteso. Un timeout e un rifiuto significano cose diverse, e trattare entrambi come un problema di credenziali fa perdere l'ora successiva. Poi provate un account valido ma non idoneo e una password errata, perché un criterio che accetta tutto supera anche il primo test.

Infine, controllate cosa fa il gateway con l'autorizzazione restituita. Registrare un client RADIUS consente solo al dispositivo di partecipare; non concede a ogni sessione risultante l'accesso alla LAN.

Tenete circoscritto l'output diagnostico: nessun segreto condiviso, nessuna password utente, nessun payload completo di pacchetto in un ticket di supporto. Se il progetto richiede che il server NPS legga attributi di directory, quel permesso è un'attività amministrativa separata dalla registrazione del client, e quando manca fallisce in un altro modo.

Articoli correlati