Eroarea 720 VPN în Windows: pool de adrese sau legarea clientului?
Eroarea 720 înseamnă că conexiunea nu a primit niciodată o adresă utilizabilă. Separați defecțiunile de pe un singur host de cele de pe mai multe hosturi înainte de a reinstala un adaptor.
Eroarea 720 apare după ce acreditările sunt acceptate, și de aceea trimite oamenii înapoi la câmpul parolei. Conexiunea a ajuns în punctul în care se negociază o adresă și nu a primit niciuna. Două defecțiuni foarte diferite produc același dialog: serverul nu avea nimic de distribuit, sau acest client anume nu a putut finaliza negocierea. Separarea celor două înainte de a atinge ceva este cea mai mare parte a reparației, iar distincția este documentată pe pagina de depanare Microsoft pentru eroarea 720.
Ce omite dialogul
Mesajul descrie o defecțiune în negocierea PPP, și este deliberat vag pentru că clientul nu poate vedea de ce a refuzat serverul. Nu este o eroare de acreditări și nu este o afirmație despre criptarea tunelului. Înseamnă că adresa sau parametrii de negociere nu au fost livrați.
Pe partea de server, cauza obișnuită este alocarea: un pool static RRAS fără adrese libere, sau o configurație DHCP al cărei domeniu este epuizat sau inaccesibil, produce exact acest simptom la fiecare client care încearcă. Pe partea de client, cauza obișnuită este o legătură. WAN Miniport care transportă PPP trebuie să fie legat de componentele corecte, iar o legătură dezactivată sau un filtru de rețea inserat poate opri negocierea fără nicio problemă vizibilă a dispozitivului. Cele două familii au nevoie de dovezi diferite, iar cel mai rapid mod de a alege între ele este să numărați câți clienți sunt afectați.
Separați populația înainte de pool
Numărați clienții afectați înainte de a citi orice configurație. O defecțiune care lovește pe toată lumea deodată este o condiție de server, iar o defecțiune care urmează o singură mașină între rețele este o condiție de client. Acea numărare costă un mesaj într-un canal de chat și economisește o după-amiază.
| 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 |
Apoi corelați o încercare eșuată cu propria evidență a serverului, pentru că RRAS înregistrează un eveniment când nu poate aloca, iar acel eveniment numește defecțiunea în loc de simptom. Dacă defecțiunea urmează un client anume, jurnalul serverului nu va arăta nimic pentru acea încercare, ceea ce este informativ în sine. Absența unei erori de alocare restrânge problema la negocierea de pe acel client și vă spune ce comenzi să rulați în continuare.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Citiți starea de alocare a serverului
Pe partea RRAS, confirmați ce metodă de alocare este configurată efectiv și nu care presupune documentația. Un pool static și o configurație retransmisă prin DHCP eșuează în moduri diferite, iar remedierea aparține celei aflate în uz. Pentru un pool static, numărați adresele libere și căutați atribuiri pe utilizator care dețin un lease pe care nimeni nu își amintește că l-a făcut, pentru că un pool care pare mare poate fi complet angajat. Pentru DHCP, verificați că releul ajunge la un server și că domeniul are lease-uri libere.
Un domeniu epuizat de clienți obișnuiți produce același 720 ca un pool configurat greșit, iar consola RRAS va arăta perfect sănătoasă în ambele cazuri. Rezistați soluției moștenite de a împărți un pool în intervale mai mici: sfatul original descria rezultatul unui administrator și nu repară o defecțiune de alocare pe care evenimentele proprii ale serverului o pot numi direct.
Citiți legăturile clientului fără a le rupe
Dacă dovezile indică un client, inspectați adaptorul ascuns în loc să reinstalați stiva. Prima comandă listează interfețele WAN Miniport și numele lor; a doua preia numele returnat de aceasta, nu un nume copiat dintr-un ghid.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsCitiți lista pentru legătura de rezolvare a adreselor și pentru filtrele terțe. O legătură dezactivată este o reparație țintită, în timp ce prezența unui filtru este o întrebare pentru proprietarul acelui software și nu o permisiune de a dezactiva un produs de securitate. Ștergerea tuturor adaptoarelor este singura mișcare care distruge dovezile de care ați avea nevoie dacă defecțiunea revine.
După corectare, reîncercați același profil și apoi repetați cazul cu doi clienți dacă acesta era simptomul inițial, pentru că o primă conexiune reușită ascunde problema de alocare pe care o expune al doilea client. Țineți nota la patru câmpuri: care client, care legătură, care eveniment și ce s-a schimbat. Schimbați și un singur strat pe încercare, deoarece o corectare a clientului și o modificare a pool-ului aplicate împreună nu pot fi atribuite, iar următoarea defecțiune va părea nouă când este aceeași.