Грешка 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Прочетете списъка за свързването за разрешаване на адреси и за филтри на трети страни. Забраненото свързване е целенасочена поправка, докато наличието на филтър е въпрос към собственика на този софтуер, а не разрешение за изключване на продукт за сигурност. Изтриването на всички адаптери е единственият ход, който унищожава доказателствата, които би ви трябвали, ако повредата се върне.
След корекцията опитайте отново същия профил и след това повторете случая с два клиента, ако това е бил първоначалният симптом, защото успешна първа връзка скрива проблема с разпределянето, който разкрива втори клиент. Дръжте бележката в четири полета: кой клиент, кое свързване, кое събитие и какво се промени. Променяйте и един слой на опит, тъй като поправка на клиента и промяна на пула, приложени заедно, не могат да бъдат приписани, а следващата повреда ще изглежда нова, когато е същата.