У п'ятницю це працювало. У понеділок той самий клієнт Windows відповідає діалогом про те, що спроба підключення не вдалася, а фраза під ним — та, яку ви вже бачили для десятка не пов'язаних проблем. Цей діалог — кінець ланцюжка, а не його початок. Windows приховує етап, на якому спроба справді померла, і два невеликі докази називають його: числовий код результату й одна подія RasClient з тієї ж хвилини. Ось порядок, яким я користуюся: зафіксуйте спробу, прочитайте код, витягніть подію і потім змініть рівно один рівень.

Текст діалогу — останній крок, а не причина

Фраза, яку ви читаєте, вибирається після того, як спроба вже розгорнулася. «Підключення було перервано віддаленим комп'ютером до встановлення підключення» з'являється, коли сервер кладе слухавку посеред узгодження, коли IPsec не вдався ще до надсилання вашого імені користувача і коли політика відмовила в тунелі відразу. Три різні власники, одна фраза. Ставтеся до формулювання як до класу симптомів і не дозволяйте йому щось спрямовувати, доки код із ним не погодиться.

Те, що ще можна зафіксувати, — це сама спроба. Запишіть ім'я підключення, тип тунелю, збережений у профілі — PPTP, L2TP/IPsec, SSTP або IKEv2 —, час із точністю до секунди і код. Якщо ви не впевнені, який протокол насправді працював, відкрийте %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk і прочитайте запис, а не покладайтеся на пам'ять; профіль, повторно використаний для нового протоколу, зберігає своє старе відображуване ім'я.

Прочитайте число перш ніж читати слова

Коди поділяються на три етапи, і етап важливіший за точне формулювання: обмін автентифікації, до якого дійшли і в якому відмовили, сервер, який так і не відповів, або узгодження, що розвалилося після підняття каналу. 691 — це перший тип: перевірка облікових даних пройшла і не вдалася, чи то через неправильний пароль, заблокований або прострочений обліковий запис, чи то через протокол автентифікації, який сервер не приймає. 812 — теж відмова, але з чинними обліковими даними: політика на сервері віддаленого доступу вирішила проти вас. Microsoft веде канонічний список кодів помилок комутованих і VPN-підключень, і варто прочитати свій номер там, перш ніж шукати текст повідомлення.

809 — протилежний клас: нічого не повернулося. Це проблема шляху — TCP 443 фільтрується для SSTP, GRE блокується для PPTP, UDP 500 і 4500 або ESP відкидаються для проходження IPsec. Новий пароль цього не виправить, і новий сертифікат теж. 720 означає, що канал піднявся, а PPP так і не завершив узгодження, що вказує на несумісність протоколу або сервер, який не зміг призначити адресу. 789, або 13801 на IKEv2, — це ідентичність усередині IPsec: сертифікат, суб'єкт якого не збігається з набраним ім'ям, недовірений ланцюжок або попередньо спільний ключ, що різниться між двома кінцями.

Витягніть подію RasClient за ту саму хвилину

У Переглядачі подій Windows Logs > Application, відфільтроване за джерелом RasClient, — перше місце, куди варто дивитися. Опис Microsoft щодо помилки 720 вказує на подію 20227 у цьому журналі. Той самий постачальник видає інші ідентифікатори для інших результатів, тому читайте повідомлення і вбудований у нього код результату, а не вважайте ID діагнозом; загальний діалог плюс 20227, що несе 720, — уже набагато вужча історія.

З PowerShell, не клацаючи в графічному інтерфейсі:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Порожній результат інформативний. Зазвичай він означає, що додзвін так і не зайшов достатньо далеко, щоб RAS щось записав, або що програмне забезпечення, яке відмовило, взагалі не є штатним клієнтом — сторонні клієнти ведуть власну діагностику і часто нічого не пишуть у журнал Application. Перевірте журнал постачальника, перш ніж робити висновок, що реєстрація подій зламана.

Побудуйте одну шкалу часу замість купи подій

Цикли повторних спроб створюють шум. П'ять автоматичних перепідключень залишають скупчення подій, і виникає спокуса прочитати їх як одну послідовність з однією причиною. Це п'ять окремих спроб, і лише деякі з них дійшли до сервера. Візьміть вікно у дві-три хвилини, одне ім'я підключення і перелічіть кожну подію з її власним кодом, перш ніж щось інтерпретувати.

Потім запитайте, де спроба зупинилася. Коли шлюз або серверна частина автентифікації не зберігає жодного запису для цієї позначки часу, клієнт туди не дійшов, і ви дивитеся на проблему доступності. Коли серверна частина показує запит і відмову, рішення ухвалено там, і діє клас облікових даних або політики. Порівняйте годинники, перш ніж порівнювати часи: клієнти повідомляють місцевий час, багато шлюзів записують у UTC, і зсув змусить ідеально корельовану пару виглядати не пов'язаною.

Для відтворюваного запису додзвоніться з командного рядка і дайте їй надрукувати результат:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

Консоль показує номер, який графічний інтерфейс ховає за дружнім текстом, а двократний запуск скаже, чи код стабільний, чи періодичний.

Що кожен етап велить змінити

Називати етап корисно лише тоді, коли це звужує набір змін до одного рівня:

  • 691 — автентифікація: метод EAP, який пропонує клієнт, проти того, який приймає сервер, стан облікового запису, термін дії пароля, дозвіл на додзвін.
  • 812 — політика сервера: політика віддаленого доступу або правило NPS, що відповідає цьому користувачеві й цьому часовому вікну.
  • 809 — доступність: правила брандмауера на шляху, NAT і проходження протоколу, порт, потрібний вибраному типу тунелю.
  • 720 — узгодження PPP: несумісність протоколу автентифікації, призначення адреси, параметр PPP на боці сервера.
  • 789 / 13801 — ідентичність IPsec: суб'єкт сертифіката проти набраного імені, ланцюжок довіри, попередньо спільний ключ.

Змініть щось одне, перевірте той самий профіль знову і запишіть новий код. Інший код після зміни — це прогрес, а не суперечність: ви зсунули збій на пізніший етап, і саме так виглядає виправлення багатоетапного рукостискання. Чого робити не варто — змінювати брандмауер, сертифікат і пароль за один підхід, а потім приписувати заслугу тому, що було останнім.

Діліться доказами, а не оточенням

Повідомлення подій багатші, ніж здаються. Вони несуть ім'я підключення, обліковий запис, часто внутрішнє ім'я або адресу шлюзу, а іноді відбиток сертифіката. Зберігайте оригінал там, де йому місце, і створюйте окрему відредаговану копію для будь-кого іншого; передруковування шкали часу з пам'яті втрачає саме ті деталі, які роблять її корисною.

Передача, яку будуть опрацьовувати, потребує п'яти полів: коду, етапу, до якого він належить, клієнта й типу тунелю, позначки часу з її часовим поясом і того, чи бачив шлюз запит узагалі. Усе інше необов'язкове. З цими п'ятьма наступна людина відрізнить суперечку про облікові дані від суперечки про маршрутизацію, не повторюючи розслідування.

Перш ніж щось закрити, повторіть спробу на тому самому профілі й підтвердьте, де код опиняється тепер. Успіх це завершує; інший збій означає, що початковий етап виправлено і наступний у вас у руках.

Схожі статті