Коди помилок VPN у Windows: який етап не вдався і що протоколювати

Відкрийте діалог VPN у Windows після збою, і він дасть вам номер і речення, причому речення зазвичай менш корисна половина. Номер указує, на якому етапі з’єднання стався збій, а етап визначає, який журнал, яке налаштування і яку команду дивитися далі. Послідовний прохід етапами займає близько десяти хвилин і запобігає знайомій послідовності: переінсталяції адаптерів, зміни протоколів і скидання стека, щоб виправити обліковий запис, якому ніколи не дозволяли дзвонити.

Читайте номер як етап

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

Помилка, якої треба уникати, — вважати код ступенем серйозності. Збій каналу і збій авторизації обидва читаються як "не вдалося підключитися", і більше нічого спільного в них немає. Серйозність каже, наскільки це нагально; етап каже, що відкривати.

Перший етап: канал і спроба додзвону

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

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

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

Якщо той самий профіль працює в іншій мережі, зупиніться тут. Код описує стан шляху, а не помилку конфігурації, і наступне корисне порівняння — два знімки, а не ще одна переінсталяція.

Другий етап: PPP і прив’язка мініпорту

720 міститься між каналом і користувачем. Тунель піднявся, і потім рівень PPP не зміг узгодити адресу або протокол керування, що часто є проблемою прив’язки на клієнті, а не відхиленими обліковими даними. Саме ця різниця — вся цінність коду: він каже, що облікових даних так і не було досягнуто, тож обліковий запис не підозрюваний.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Читати ці два виводи інформативніше, ніж скидати будь-що. Мініпорт, який є, але не запущений, або прив’язка протоколу, вимкнена іншим програмним забезпеченням, дають рівно збій цього етапу. І те, і те виправляється без втручання в решту стека. Повне скидання, навпаки, видаляє адресацію та стан фільтрації, які не мали стосунку до несправності.

Третій етап: ідентичність і авторизація

691 означає, що облікові дані відхилено. 649 означає, що обліковому запису не дозволено дзвонити, а 812 означає, що політика віддаленого доступу відхилила з’єднання. Це рішення, а не транспортні збої, і клієнт може лише повідомити про них.

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

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

Четвертий етап: підключено, і нічого не працює

З’єднання може завершитися і все одно бути марним. Воно має адресу, клієнт повідомляє про успіх, а кожен запит застосунку вичерпує час. У діалозі це жодним чином не відображено, і коду для перевірки немає. У цей момент діалог завершено, а корисні докази — в іншому місці.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Якщо маршруту немає, сервер його не проштовхнув або клієнт його відкинув. Якщо маршрут є, а ім’я не розв’язується, проблема в розв’язанні імен. Якщо працює і те, і те, а застосунок усе одно падає, ви вже за тунелем і в конфігурації самого застосунку.

Тримайте зміни на одному шарі на тест. Кожна правка перед наступною спробою стає частиною контексту наступного коду, а код, що описує вашу останню правку, гірший за відсутність коду.

Одна спроба, одна зміна, один запис

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

Потім покладіть цю позначку часу поруч із записом на іншому боці. Таблиця у верхній частині цієї сторінки каже, якому етапу належить кожна розбіжність. Без другого запису код лише звужує пошук; із ним етап вирішено. Саме порівняння перетворює номер на діагноз, а не на здогад.

Ця звичка охоплює майже будь-яку власну несправність VPN у Windows, і жодна з гілок не вимагає переінсталяції чогось. Діалог завжди казав, який із них у вас; робота в тому, щоб відмовлятися вважати їх усі однією проблемою.