Памылка 720 VPN у Windows: пул адрасоў ці прывязка кліента?
Памылка 720 азначае, што злучэнне так і не атрымала прыдатны адрас. Аддзяліце збоі на адным вузле ад збояў на многіх вузлах, перш чым пераўсталёўваць адаптар.
Памылка 720 з'яўляецца пасля прыняцця ўліковых даных, таму яна вяртае людзей да поля пароля. Злучэнне дайшло да пункта, дзе ўзгадняецца адрас, і не атрымала яго. Два цалкам розныя збоі даюць тое самае акно: серверу не было чаго выдаць або менавіта гэты кліент не змог завяршыць узгадненне. Падзяліць гэтыя два выпадкі да любога ўмяшання — большая частка рамонту, і гэты падзел апісаны на старонцы Microsoft па выпраўленні непаладак памылкі 720.
Пра што маўчыць дыялог
Паведамленне апісвае збой падчас узгаднення PPP, і яно наўмысна расплывістае, бо кліент не бачыць, чаму сервер адмовіў. Гэта не памылка ўліковых даных і не сцвярджэнне пра шыфраванне тунеля. Яно азначае, што адрас або параметры ўзгаднення не былі дастаўлены.
На баку сервера звычайная прычына — выдзяленне адрасоў: статычны пул RRAS без свабодных адрасоў або канфігурацыя DHCP, дыяпазон якой вычарпаны ці недаступны, дае менавіта гэты сімптом у кожнага кліента, які спрабуе. На баку кліента звычайная прычына — прывязка. WAN Miniport, па якім ідзе PPP, павінен быць прывязаны да правільных кампанентаў, а адключаная прывязка або ўстаўлены сеткавы фільтр можа спыніць узгадненне без бачнай праблемы прылады. Гэтым дзвюм сем'ям патрэбныя розныя доказы, і самы хуткі спосаб выбраць паміж імі — палічыць, колькі кліентаў закранута.
Спачатку падзяліце папуляцыю, потым пул
Палічыце закранутых кліентаў, перш чым чытаць любую канфігурацыю. Збой, які ўражае ўсіх адразу, — гэта стан сервера, а збой, які ідзе за адной машынай паміж сеткамі, — стан кліента. Такі падлік каштуе аднаго паведамлення ў чаце і эканоміць паўдня.
| 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 |
Затым супастаўце адну няўдалую спробу з уласным запісам сервера, бо RRAS запісвае падзею, калі не можа выдзеліць адрас, і гэта падзея называе збой, а не сімптом. Калі збой ідзе за канкрэтным кліентам, журнал сервера нічога не пакажа для гэтай спробы, што само па сабе інфарматыўна. Адсутнасць памылкі выдзялення звужвае праблему да ўзгаднення на гэтым кліенце і кажа, якія каманды выконваць далей.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Прачытайце стан выдзялення на серверы
На баку RRAS пацвердзіце, які метад выдзялення сапраўды наладжаны, а не які мяркуе дакументацыя. Статычны пул і канфігурацыя з рэтрансляцыяй DHCP адмаўляюць па-рознаму, і выпраўленне датычыцца таго, які выкарыстоўваецца. Для статычнага пула палічыце свабодныя адрасы і пашукайце прызначэнні па карыстальніках, якія трымаюць арэнду, пра якую ніхто не памятае, бо пул, што выглядае вялікім, можа быць цалкам заняты. Для DHCP праверце, што рэтранслятар дасягае сервера і што ў дыяпазоне ёсць свабодныя арэнды.
Дыяпазон, вычарпаны звычайнымі кліентамі, дае тую самую памылку 720, што і няправільна наладжаны пул, і кансоль RRAS у абодвух выпадках выглядацьме цалкам здаровай. Супрацьстойце ўспадкаванаму абыходнаму шляху з драбненнем пула на меншыя дыяпазоны: пачатковая рада апісвала вынік аднаго адміністратара, і яна не ліквідуе збой выдзялення, які падзеі самага сервера могуць назваць непасрэдна.
Прачытайце прывязкі кліента, не зламаўшы іх
Калі доказы паказваюць на аднаго кліента, аглядзіце схаваны адаптар, а не пераўсталёўвайце стек. Першая каманда пералічвае інтэрфейсы WAN Miniport і іх імёны; другая бярэ імя, якое яна вярнула, а не імя, скапіяванае з дапаможніка.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsПрачытайце спіс наконт прывязкі развязання адрасоў і старонніх фільтраў. Адключаная прывязка — гэта кропкавае выпраўленне, тады як наяўнасць фільтра — пытанне да ўласніка гэтага праграмнага забеспячэння, а не дазвол выключаць ахоўны прадукт. Выдаленне ўсіх адаптараў — адзіны крок, які знішчае доказы, патрэбныя вам, калі збой вернецца.
Пасля выпраўлення паўтарыце той самы профіль, а потым паўтарыце выпадак з двума кліентамі, калі гэта быў пачатковы сімптом, бо паспяховае першае злучэнне хавае праблему выдзялення, якую выяўляе другі кліент. Трымайце нататку ў чатырох палях: які кліент, якая прывязка, якая падзея і што змянілася. Змяняйце і адзін слой за спробу, паколькі выпраўленне кліента і змену пула, ужытыя разам, нельга аднесці да прычыны, і наступны збой выглядацьме новым, хоць ён той самы.