Error 720 ng Windows VPN: pool ng address o binding ng kliyente?
Ang error 720 ay nangangahulugang hindi kailanman nabigyan ng magagamit na address ang koneksyon. Ihiwalay ang mga pagkabigo sa isang host mula sa mga pagkabigo sa maraming host bago mag-install muli ng adapter.
Lumilitaw ang error 720 pagkatapos tanggapin ang mga kredensyal, at iyon ang dahilan kung bakit pinapabalik nito ang mga tao sa field ng password. Naabot ng koneksyon ang puntong kung saan pinag-uusapan ang isang address at wala itong nakuha. Dalawang magkaibang pagkabigo ang gumagawa ng parehong dialog: walang maipamahagi ang server, o ang partikular na kliyenteng ito ay hindi natapos ang negosasyon. Ang paghihiwalay ng dalawang iyon bago hawakan ang anuman ang pinakamalaking bahagi ng pagkumpuni, at ang paghihiwalay ay dokumentado sa pahina ng pag-troubleshoot ng Microsoft para sa error 720.
Ano ang hindi sinasabi ng dialog
Inilalarawan ng mensahe ang isang pagkabigo sa negosasyon ng PPP, at sadyang malabo ito dahil hindi makikita ng kliyente kung bakit tumanggi ang server. Hindi ito error sa kredensyal, at hindi ito pahayag tungkol sa encryption ng tunnel. Nangangahulugan ito na ang address o ang mga parameter ng negosasyon ay hindi naihatid.
Sa panig ng server, ang karaniwang dahilan ay paglalaan: ang static na pool ng RRAS na walang libreng address, o isang configuration ng DHCP na ang saklaw ay naubos o hindi maabot, ay gumagawa ng eksaktong sintomas na ito sa bawat kliyenteng sumusubok. Sa panig ng kliyente, ang karaniwang dahilan ay binding. Ang WAN Miniport na nagdadala ng PPP ay dapat na nakatali sa tamang mga bahagi, at ang isang naka-disable na binding o nakapasok na filter ng network ay makapipigil sa negosasyon nang walang nakikitang problema sa device. Kailangan ng dalawang pamilya ng magkaibang ebidensya, at ang pinakamabilis na paraan upang pumili sa pagitan nila ay bilangin kung ilang kliyente ang apektado.
Ihiwalay ang populasyon bago ang pool
Bilangin ang mga apektadong kliyente bago magbasa ng anumang configuration. Ang pagkabigong tumatama sa lahat nang sabay ay kondisyon ng server, at ang pagkabigong sumusunod sa isang makina sa iba't ibang network ay kondisyon ng kliyente. Ang bilang na iyon ay isang mensahe lang sa isang chat channel at nakakatipid ng isang hapon.
| 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 |
Pagkatapos, iugnay ang isang nabigong pagtatangka sa sariling talaan ng server, dahil nag-log ang RRAS ng event kapag hindi ito makapaglalaan at pinangalanan ng event na iyon ang pagkabigo kaysa sa sintomas. Kung ang pagkabigo ay sumusunod sa isang partikular na kliyente, wala itong ipapakita sa log ng server para sa pagtatangkang iyon, na kagyat na nagbibigay-kaalaman. Ang kawalan ng error sa paglalaan ay nagpapaliit sa problema sa negosasyon sa kliyenteng iyon at nagsasabi sa iyo kung aling mga command ang susunod na patakbuhin.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Basahin ang estado ng paglalaan ng server
Sa panig ng RRAS, kumpirmahin kung aling paraan ng paglalaan ang aktwal na naka-configure at hindi kung alin ang ipinapalagay ng dokumentasyon. Ang static na pool at ang configuration na ipinadala ng DHCP ay nabibigo sa magkaibang paraan, at ang pagwawasto ay para sa alinman sa ginagamit. Para sa static na pool, bilangin ang mga libreng address at hanapin ang mga paglalaan sa bawat user na may hawak na lease na walang nakakaalala kung sino ang gumawa, dahil ang pool na mukhang malaki ay maaaring ganap na nakatalaga. Para sa DHCP, tiyakin na naaabot ng relay ang isang server at may malayang lease ang saklaw.
Ang saklaw na naubos ng mga ordinaryong kliyente ay gumagawa ng parehong 720 tulad ng maling naka-configure na pool, at ang RRAS console ay magmumukhang ganap na malusog sa parehong kaso. Labanan ang namamana na workaround ng paghahati ng pool sa mas maliliit na saklaw: inilarawan ng orihinal na payo ang resulta ng isang administrator, at hindi nito kinukumpuni ang pagkabigo sa paglalaan na kayang pangalanan nang direkta ng mga event ng server.
Basahin ang mga binding ng kliyente nang hindi sinisira
Kung ang ebidensya ay tumuturo sa isang kliyente, suriin ang nakatagong adapter kaysa i-install muli ang stack. Inililista ng unang command ang mga interface ng WAN Miniport at ang kanilang mga pangalan; kinukuha ng pangalawa ang pangalang ibinalik nito, hindi ang pangalang kinopya mula sa gabay.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsBasahin ang listahan para sa binding ng paglutas ng address at para sa mga filter ng third-party. Ang naka-disable na binding ay isang naka-target na pagkumpuni, samantalang ang pagkakaroon ng filter ay tanong para sa may-ari ng software na iyon at hindi pahintulot na i-disable ang isang security product. Ang pagtanggal ng lahat ng adapter ay ang tanging hakbang na sumisira sa ebidensyang kakailanganin mo kung bumalik ang pagkabigo.
Pagkatapos ng pagwawasto, subukan muli ang parehong profile at pagkatapos ay ulitin ang kaso ng dalawang kliyente kung iyon ang orihinal na sintomas, dahil ang matagumpay na unang koneksyon ay nagtatago ng problema sa paglalaan na inilalantad ng pangalawang kliyente. Panatilihin ang tala sa apat na field: aling kliyente, aling binding, aling event at ano ang nagbago. Palitan din ang isang layer sa bawat pagtatangka, dahil ang pagwawasto ng kliyente at pagbabago ng pool na inilapat nang sabay ay hindi maiuugnay, at ang susunod na pagkabigo ay magmumukhang bago kung ito rin ang pareho.