I client VPN di RRAS hanno bisogno del proprio pool IPv4 e di una via di ritorno

Il client VPN si connette e riceve un indirizzo, ma l’host della LAN di cui ha bisogno continua a non potergli rispondere. In Windows Routing and Remote Access, l’indirizzo interno dei client VPN proviene da un pool configurato separatamente dall’adattatore LAN del server, e il lato LAN ha bisogno di una rotta di ritorno verso quel pool. Due modifiche, non una, e falliscono in modi diversi. Affrontatele in ordine perché il piano degli indirizzi e la via di ritorno siano dimostrati prima di ritirare i vecchi intervalli.

Riservate l’intervallo prima di aprire la console

Scegliete un prefisso che non si sovrapponga alla LAN, ad altri intervalli VPN o a qualsiasi cosa instradata verso il sito. Un /24 è una dimensione comoda per una prova, e la prima parte utilizzabile può essere assegnata ai client mentre il resto resta libero per la crescita. Annotatelo con il suo scopo e il suo responsabile prima di digitarlo in una console. Lasciate spazio a entrambe le estremità del blocco perché una divisione successiva non imponga una rinumerazione.

Un piano degli indirizzi che vive solo in una console è a una ricostruzione da una collisione. Tende anche a crescere: qualcuno aggiunge un secondo intervallo più avanti e nessuno controlla il primo. Tenete il piano accanto alla documentazione del server, non in un thread di chat.

L’adattatore LAN del server non definisce questo pool. Cambiare il listener pubblico o aggiungere un adattatore alla LAN fa qualcosa di completamente diverso. Per questo i client possono connettersi e ricevere comunque un indirizzo dal posto sbagliato. Il pool vive nelle proprietà IPv4 del server, non nell’elenco degli adattatori.

Cambiare metodo non è aggiungere un intervallo

RRAS ha un metodo di assegnazione e un insieme di intervalli. Passare da DHCP a un pool statico è un cambio di metodo. Aggiungere un altro blocco mentre il pool statico è già attivo è un cambio di intervallo.

Visualizzate entrambe le operazioni prima di eseguirne una, e leggete quale corrisponde allo stato attuale del server:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Il secondo cmdlet fallisce o produce un pool inutilizzabile se il server è ancora su assegnazione DHCP. Il primo sostituisce il metodo invece di estendere un pool esistente. Nessuna delle due anteprime applica nulla, quindi eseguite quella che corrisponde e poi confermate il pool risultante nella console. Se non siete sicuri dello stato del server, leggete il metodo di assegnazione nella pagina delle proprietà IPv4 ed elencate gli intervalli configurati:

Get-VpnIPAddressRange

Un metodo DHCP con un elenco di intervalli vuoto significa che si applica la prima anteprima. Un pool di indirizzi statico con un intervallo esistente significa che si applica la seconda.

Tenete conto del riavvio del servizio che l’impostazione può richiedere, e non date per scontato che i client connessi vengano rinumerati subito. Un client che conserva il vecchio indirizzo finché non si riconnette si comporta normalmente. Pianificate la modifica per una finestra in cui una riconnessione sia accettabile.

La LAN ha bisogno di una rotta di ritorno

Supponete che la LAN sia 10.60.0.0/24 e che il server RRAS sia 10.60.0.10 su di essa. Un host di quella LAN che risponde a un client in 10.250.50.0/24 ha bisogno di un percorso verso il pool attraverso il server RRAS. Senza quel percorso la richiesta arriva e la risposta muore.

Se il gateway predefinito dell’host è un altro router, quel router ha bisogno della rotta di ritorno per il prefisso VPN. Una rotta statica sul server RRAS non aiuta qui; la via di ritorno deve esistere sul dispositivo che possiede il gateway della LAN, quindi aggiungetela alla tabella di routing o al processo di routing dinamico, secondo ciò che usa il sito.

Controllate anche il firewall dell’host e qualsiasi regola di accesso alla rete rispetto al nuovo intervallo di origine. Le regole scritte per il vecchio intervallo dei client rifiutano quello nuovo anche se l’assegnazione è riuscita. Le rotte del client verso la LAN e la risoluzione DNS sono requisiti separati, ed entrambi possono fallire mentre il tunnel sembra sano. Provate ciascuno separatamente.

Dimostrate il nuovo pool su un solo dispositivo prima di ritirare il vecchio

Prendete un’autorizzazione che controllate, riconnettetevi e leggete l’indirizzo del pool ricevuto dal client. Quel singolo numero separa l’assegnazione dal routing. Poi esercitate un’applicazione concreta, osservate il traffico di ritorno e provate una destinazione che deve restare negata. Tre osservazioni, tre modalità di guasto diverse.

La risoluzione dei nomi merita una prova a sé: l’accesso tramite IP può funzionare mentre il DNS del client punta ancora a un resolver che non riesce a raggiungere. Un server DNS sulla LAN è raggiungibile solo se il client ha una rotta verso di esso e il server accetta query dal nuovo intervallo. Entrambi sono errori frequenti quando il pool si sposta.

Ritirate gli intervalli vecchi e le loro eccezioni solo dopo aver tenuto conto delle sessioni attive e del processo di manutenzione. Un client connesso con un indirizzo nuovo dimostra l’assegnazione, non la politica di accesso. Mantenete documentato il vecchio intervallo finché l’ultima sessione che lo ha usato non è scaduta.

Verificate il risultato con tre osservazioni

L’accettazione richiede tre fatti: il client ha un indirizzo dal nuovo pool, un host della LAN può raggiungerlo e ottenere risposta, e una destinazione negata resta negata. Ognuno ha il proprio controllo, quindi un guasto indica assegnazione, routing o politica. Eseguitele in quest’ordine.

Dal client, confermate l’indirizzo e la rotta verso un host della LAN:

ipconfig | findstr /i "IPv4"
route print -4

Dall’host della LAN, confermate la via di risposta e la politica in un solo passaggio. Se ping fallisce ma l’applicazione funziona, il pezzo mancante è probabilmente una regola ICMP e non la rotta. Se falliscono entrambi, leggete la rotta sull’host prima di modificare la VPN. Annotate i tre risultati nel ticket di modifica perché la persona successiva parta dalle prove.