Windows VPN-eraro 720: adresaro aŭ klienta ligo?
Eraro 720 signifas, ke la konekto neniam ricevis uzeblan adreson. Apartigu fiaskojn ĉe unu gastiganto de fiaskoj ĉe multaj gastigantoj antaŭ ol reinstali adaptilon.
Eraro 720 aperas post kiam la legitimiloj estas akceptitaj, kaj tial ĝi resendas homojn al la pasvorta kampo. La konekto atingis la punkton, kie oni intertraktas adreson, kaj ricevis neniun. Du tre malsamaj paneoj produktas tiun saman dialogon: la servilo havis nenion por disdoni, aŭ ĝuste ĉi tiu kliento ne povis fini la intertraktadon. Apartigi tiujn du antaŭ ol tuŝi ion ajn estas la plej granda parto de la riparo, kaj la apartigo estas dokumentita en la paĝo de Microsoft pri solvado de eraro 720.
Kion la dialogo ne diras
La mesaĝo priskribas paneon en la PPP-intertraktado, kaj ĝi estas intence malpreciza, ĉar la kliento ne povas vidi, kial la servilo rifuzis. Ĝi ne estas legitimila eraro, kaj ĝi ne estas aserto pri la ĉifrado de la tunelo. Ĝi signifas, ke la adreso aŭ la intertraktaj parametroj ne estis liveritaj.
Ĉe la servila flanko la kutima kaŭzo estas asigno: statika RRAS-adresaro sen liberaj adresoj, aŭ DHCP-agordo, kies amplekso estas elĉerpita aŭ neatingebla, produktas ĝuste ĉi tiun simptomon ĉe ĉiu kliento, kiu provas. Ĉe la klienta flanko la kutima kaŭzo estas ligo. La WAN Miniport, kiu portas PPP, devas esti ligita al la ĝustaj komponantoj, kaj malŝaltita ligo aŭ enmetita retfiltro povas haltigi la intertraktadon sen videbla aparata problemo. La du familioj bezonas malsamajn pruvojn, kaj la plej rapida maniero elekti inter ili estas kalkuli, kiom da klientoj estas trafitaj.
Apartigu la populacion antaŭ ol rigardi la adresaron
Kalkulu la trafitajn klientojn antaŭ ol legi ajnan agordon. Paneo, kiu trafas ĉiujn samtempe, estas servila stato, kaj paneo, kiu sekvas unu maŝinon inter retoj, estas klienta stato. Tiu kalkulo kostas unu mesaĝon en babilkanalo kaj ŝparas posttagmezon.
| 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 |
Poste kunligu unu malsukcesan provon kun la propra registro de la servilo, ĉar RRAS protokolas eventon, kiam ĝi ne povas asigni, kaj tiu evento nomas la paneon anstataŭ la simptomon. Se la paneo sekvas specifan klienton, la servila protokolo montros nenion por tiu provo, kio mem estas informa. La foresto de asigna eraro limigas la problemon al la intertraktado ĉe tiu kliento kaj diras al vi, kiujn komandojn ruli poste.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Legu la asignan staton de la servilo
Konfirmu ĉe la RRAS-flanko, kiun asignan metodon oni fakte agordis, kaj ne kiun la dokumentaro supozas. Statika adresaro kaj DHCP-plusendita agordo fiaskas laŭ malsamaj manieroj, kaj la riparo apartenas al tiu, kiu estas uzata. Kalkulu la liberajn adresojn en statika adresaro kaj serĉu asignojn laŭ uzanto, kiuj tenas luon, kiun neniu memoras fari, ĉar adresaro, kiu aspektas granda, povas esti plene okupita. Kontrolu ĉe DHCP, ĉu la plusendilo atingas servilon kaj ĉu la amplekso havas liberajn luojn.
Amplekso elĉerpita de ordinaraj klientoj produktas la saman 720 kiel misagordita adresaro, kaj la RRAS-konzolo aspektos tute sana en ambaŭ kazoj. Rezistu la hereditan laboraroundon disigi adresaron en pli malgrandajn intervalojn: la origina konsilo priskribis la rezulton de unu administranto, kaj ĝi ne riparas asignan paneon, kiun la eventoj de la servilo mem povas rekte nomi.
Legu la ligojn de la kliento sen difekti ilin
Se la pruvoj montras al unu kliento, inspektu la kaŝitan adaptilon anstataŭ reinstali la stakon. La unua komando listigas la WAN Miniport-interfacojn kaj iliajn nomojn; la dua prenas la nomon, kiun ĝi redonis, ne nomon kopiitan el gvidilo.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLegu la liston por la adresresolva ligo kaj por filtroj de triaj partioj. Malŝaltita ligo estas celita riparo, dum la ĉeesto de filtro estas demando por la posedanto de tiu programaro, ne permeso malŝalti sekurecan produkton. Forigi ĉiun adaptilon estas la ununura ago, kiu detruas la pruvojn, kiujn vi bezonus, se la paneo revenus.
Post la korekto, reprovu la saman profilon kaj poste ripetu la kazon de du klientoj, se tio estis la origina simptomo, ĉar sukcesa unua konekto kaŝas la asignan problemon, kiun dua kliento malkaŝas. Tenadu la noton al kvar kampoj: kiu kliento, kiu ligo, kiu evento kaj kio ŝanĝiĝis. Ŝanĝu ankaŭ unu tavolon po provo, ĉar klienta riparo kaj adresara ŝanĝo kune ne povas esti atribuitaj, kaj la sekva fiasko aspektos nova, kiam ĝi estas la sama.