„Windows“ VPN klaida 720: adresų telkinys ar kliento susiejimas?
Klaida 720 reiškia, kad ryšys taip ir negavo naudojamo adreso. Atskirkite vieno hosto gedimus nuo daugelio hostų gedimų prieš iš naujo įdiegdami adapterį.
Klaida 720 pasirodo po to, kai priimami prisijungimo duomenys, todėl ji nukreipia žmones atgal į slaptažodžio lauką. Ryšys pasiekė tašką, kuriame derinamas adresas, ir jo negavo. Dvi labai skirtingos gedimų rūšys sukuria tą patį dialogą: serveris neturėjo ko išdalyti arba būtent šis klientas negalėjo užbaigti derinimo. Atskirti šiuos du prieš ką nors liesdami yra didžioji dalis remonto, o atskyrimas aprašytas „Microsoft“ klaidos 720 trikčių šalinimo puslapyje.
Ko dialogas nenutyla
Pranešimas aprašo PPP derinimo gedimą ir yra sąmoningai neaiškus, nes klientas nemato, kodėl serveris atsisakė. Tai nėra prisijungimo duomenų klaida ir nėra teiginys apie tunelio šifravimą. Tai reiškia, kad adresas arba derinimo parametrai nebuvo pristatyti.
Serverio pusėje įprasta priežastis yra priskyrimas: statinis RRAS telkinys be laisvų adresų arba DHCP konfigūracija, kurios sritis išnaudota arba nepasiekiama, sukuria būtent šį simptomą kiekvienam klientui, kuris bando. Kliento pusėje įprasta priežastis yra susiejimas. WAN Miniport, kuriuo eina PPP, turi būti susietas su tinkamais komponentais, o išjungtas susiejimas arba įterptas tinklo filtras gali sustabdyti derinimą be jokios matomos įrenginio problemos. Šioms dviem šeimoms reikia skirtingų įrodymų, o greičiausias būdas pasirinkti tarp jų yra suskaičiuoti, kiek klientų paveikta.
Pirmiausia atskirkite populiaciją, tada telkinį
Suskaičiuokite paveiktus klientus prieš skaitydami bet kokią konfigūraciją. Gedimas, kuris vienu metu ištinka visus, yra serverio būsena, o gedimas, kuris seka vieną mašiną tarp tinklų, yra kliento būsena. Toks skaičiavimas kainuoja vieną žinutę pokalbių kanale ir sutaupo popietę.
| 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 |
Tada susiekite vieną nepavykusį bandymą su pačiu serverio įrašu, nes RRAS įrašo įvykį, kai negali priskirti, ir tas įvykis įvardija gedimą, o ne simptomą. Jei gedimas seka konkretų klientą, serverio žurnalas tam bandymui nieko nerodys, o tai savaime informatyvu. Priskyrimo klaidos nebuvimas susiaurina problemą iki to kliento derinimo ir pasako, kokias komandas vykdyti toliau.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Perskaitykite serverio priskyrimo būseną
RRAS pusėje patvirtinkite, kuris priskyrimo metodas iš tikrųjų sukonfigūruotas, o ne kurį numato dokumentacija. Statinis telkinys ir per DHCP persiunčiama konfigūracija nepavyksta skirtingai, o pataisymas priklauso tam, kuris naudojamas. Statinio telkinio atveju suskaičiuokite laisvus adresus ir ieškokite priskyrimų pagal naudotoją, kurie laiko nuomą, kurios niekas neprisimena, nes telkinys, kuris atrodo didelis, gali būti visiškai užimtas. DHCP atveju patikrinkite, ar retransliatorius pasiekia serverį ir ar srityje yra laisvų nuomų.
Sritis, kurią išnaudojo įprasti klientai, sukuria tą pačią 720 kaip neteisingai sukonfigūruotas telkinys, o RRAS konsolė abiem atvejais atrodys visiškai sveika. Atsispirkite paveldėtam apėjimo būdui skaidyti telkinį į mažesnes sritis: pradinis patarimas aprašė vieno administratoriaus rezultatą ir nepataiso priskyrimo gedimo, kurį paties serverio įvykiai gali įvardyti tiesiogiai.
Perskaitykite kliento susiejimus jų nesugriovę
Jei įrodymai rodo į vieną klientą, apžiūrėkite paslėptą adapterį, o ne iš naujo įdiekite steką. Pirmoji komanda išvardija WAN Miniport sąsajas ir jų pavadinimus; antroji paima pavadinimą, kurį ji grąžino, o ne pavadinimą, nurašytą iš vadovo.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsPerskaitykite sąrašą dėl adresų sprendimo susiejimo ir dėl trečiųjų šalių filtrų. Išjungtas susiejimas yra tikslingas remontas, o filtro buvimas yra klausimas tos programinės įrangos savininkui, o ne leidimas išjungti saugos produktą. Visų adapterių trynimas yra vienintelis veiksmas, kuris sunaikina įrodymus, kurių prireiktų, jei gedimas sugrįžtų.
Po pataisymo bandykite tą patį profilį dar kartą, o tada pakartokite dviejų klientų atvejį, jei tai buvo pradinis simptomas, nes sėkmingas pirmasis ryšys paslepia priskyrimo problemą, kurią atskleidžia antras klientas. Laikykite pastabą keturiuose laukuose: kuris klientas, kuris susiejimas, kuris įvykis ir kas pasikeitė. Keiskite ir vieną sluoksnį per bandymą, nes kliento pataisymo ir telkinio pakeitimo, atliktų kartu, negalima priskirti, o kitas gedimas atrodys naujas, nors yra tas pats.