Помилка 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
Прочитайте список щодо прив'язки розв'язання адрес і сторонніх фільтрів. Вимкнена прив'язка — це точкове виправлення, тоді як наявність фільтра — питання до власника цього програмного забезпечення, а не дозвіл вимикати захисний продукт. Видалення всіх адаптерів — єдиний крок, який знищує докази, потрібні вам, якщо збій повернеться.
Після виправлення повторіть той самий профіль, а потім повторіть випадок із двома клієнтами, якщо це був початковий симптом, бо успішне перше з'єднання приховує проблему виділення, яку виявляє другий клієнт. Тримайте нотатку в чотирьох полях: який клієнт, яка прив'язка, яка подія і що змінилося. Змінюйте й один шар за спробу, оскільки виправлення клієнта та зміну пулу, застосовані разом, не можна віднести до причини, і наступний збій виглядатиме новим, хоча він той самий.