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

Клієнт розв’язує ім’я перед підключенням

Вбудоване VPN-з’єднання Windows читає свій профіль, розв’язує адресу сервера, запускає тунель і лише потім виконує автентифікацію. Помилка 868 належить до другого кроку. Оскільки наступні кроки ніколи не виконуються, діалог може виглядати як проблема з обліковими даними, коли пошук не вдався першим.

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

Яке ім’я, коли поле показує адресу

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

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

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

Resolve-DnsName vpn.example.com

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

Схема перепідключення в Windows 7

Гілка, що стоїть за цією помилкою, описує машини, які одного разу підключилися, а потім зазнали збою з 868 під час пізнішої спроби, хоча в профілі нічого не змінювалося. Учасники повідомляли, що перезапуск служби Remote Access Connection Manager або вихід і повторний вхід тимчасово відновлювали з’єднання. Це обхідні шляхи, а не доведена першопричина.

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

ObservationPoints towardWhat to do next
Fails from one network, works from anotherName resolution on that pathResolve the stored name from both networks
Fails after a disconnect, works after service restartClient state, not DNSRecord the sequence for the vendor
Fails only on a newly provisioned machineProfile content or scopeCompare ServerAddress and TunnelType

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

Що зібрати для адміністратора

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

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

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

Схожі статті