Ошибка 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Прочитайте список на предмет привязки разрешения адресов и сторонних фильтров. Отключённая привязка — это точечное исправление, тогда как наличие фильтра — вопрос к владельцу этого программного обеспечения, а не разрешение отключать защитный продукт. Удаление всех адаптеров — единственный шаг, который уничтожает доказательства, нужные вам, если сбой вернётся.
После исправления повторите тот же профиль, а затем повторите случай с двумя клиентами, если это был исходный симптом, потому что успешное первое подключение скрывает проблему выделения, которую выявляет второй клиент. Держите заметку в четырёх полях: какой клиент, какая привязка, какое событие и что изменилось. Меняйте и один слой за попытку, поскольку исправление клиента и изменение пула, применённые вместе, нельзя отнести к причине, и следующий сбой будет выглядеть новым, хотя он тот же.