Errore 720 VPN Windows: pool di indirizzi o binding del client?
L'errore 720 significa che alla connessione non è mai stato assegnato un indirizzo utilizzabile. Distingua i guasti su un solo host dai guasti su molti host prima di reinstallare un adattatore.
L'errore 720 compare dopo che le credenziali sono accettate, ed è per questo che rimanda le persone al campo della password. La connessione ha raggiunto il punto in cui si negozia un indirizzo e non ne ha ottenuto uno. Due guasti molto diversi producono la stessa finestra: il server non aveva nulla da distribuire, oppure questo specifico client non è riuscito a completare la negoziazione. Separare i due prima di toccare qualsiasi cosa è la maggior parte della riparazione, e la distinzione è documentata nella pagina di risoluzione dei problemi di Microsoft sull'errore 720.
Ciò che la finestra di dialogo tace
Il messaggio descrive un guasto nella negoziazione PPP, ed è volutamente vago perché il client non può vedere perché il server ha rifiutato. Non è un errore di credenziali e non è un'affermazione sulla crittografia del tunnel. Significa che l'indirizzo o i parametri di negoziazione non sono stati consegnati.
Lato server, la causa abituale è l'allocazione: un pool statico RRAS senza indirizzi liberi, o una configurazione DHCP il cui ambito è esaurito o irraggiungibile, produce esattamente questo sintomo in ogni client che prova. Lato client, la causa abituale è un binding. Il WAN Miniport che trasporta PPP deve essere associato ai componenti corretti, e un binding disabilitato o un filtro di rete inserito possono fermare la negoziazione senza alcun problema visibile del dispositivo. Le due famiglie richiedono prove diverse, e il modo più rapido per scegliere tra loro è contare quanti client sono colpiti.
Separi la popolazione prima del pool
Conti i client colpiti prima di leggere qualsiasi configurazione. Un guasto che colpisce tutti insieme è una condizione del server, e un guasto che segue una macchina tra reti diverse è una condizione del client. Quel conteggio costa un messaggio in un canale di chat e fa risparmiare un pomeriggio.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Poi correli un tentativo fallito con il registro del server stesso, perché RRAS registra un evento quando non riesce ad allocare e quell'evento nomina il guasto anziché il sintomo. Se il guasto segue un client specifico, il registro del server non mostrerà nulla per quel tentativo, il che è di per sé informativo. L'assenza di un errore di allocazione restringe il problema alla negoziazione su quel client e le dice quali comandi eseguire dopo.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Legga lo stato di allocazione del server
Lato RRAS, confermi quale metodo di allocazione è realmente configurato e non quale la documentazione presuppone. Un pool statico e una configurazione inoltrata da DHCP falliscono in modi diversi, e la correzione spetta a quello in uso. Per un pool statico, conti gli indirizzi liberi e cerchi assegnazioni per utente che mantengono un lease che nessuno ricorda di aver concesso, perché un pool che sembra grande può essere completamente impegnato. Per DHCP, verifichi che il relay raggiunga un server e che l'ambito abbia lease liberi.
Un ambito esaurito da client ordinari produce lo stesso 720 di un pool mal configurato, e la console RRAS apparirà perfettamente sana in entrambi i casi. Resista alla soluzione ereditata di dividere un pool in intervalli più piccoli: il consiglio originale descriveva il risultato di un amministratore e non ripara un guasto di allocazione che gli stessi eventi del server possono nominare direttamente.
Legga i binding del client senza romperli
Se le prove indicano un client, ispezioni l'adattatore nascosto invece di reinstallare lo stack. Il primo comando elenca le interfacce WAN Miniport e i loro nomi; il secondo prende il nome che ha restituito, non un nome copiato da una guida.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLegga l'elenco per il binding di risoluzione degli indirizzi e per i filtri di terze parti. Un binding disabilitato è una riparazione mirata, mentre la presenza di un filtro è una domanda per il proprietario di quel software e non un permesso di disattivare un prodotto di sicurezza. Eliminare tutti gli adattatori è l'unica mossa che distrugge le prove che le servirebbero se il guasto tornasse.
Dopo la correzione, riprovi lo stesso profilo e poi ripeta il caso a due client se era quello il sintomo originale, perché una prima connessione riuscita nasconde il problema di allocazione che un secondo client rivela. Tenga la nota su quattro campi: quale client, quale binding, quale evento e cosa è cambiato. Cambi anche un solo livello per tentativo, dato che una correzione del client e una modifica del pool applicate insieme non sono attribuibili, e il prossimo guasto sembrerà nuovo quando è lo stesso.