Рукостискання є, інтернету немає: що виправити першим на Windows 11

У Windows 11 свіжі рукостискання часто стоять поруч із браузерами, які нічого не відкривають. Рукостискання доводить лише те, що обмін UDP з партнером завершився. Воно нічого не каже про маршрут, який встановив Windows, про резолвер, який він використовує, і про те, чи передає вихід узагалі щось.

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

Визначте шар, перш ніж торкатися ключів

Пройдіть три призначення в цьому порядку. Почніть з адреси з боку тунелю, потім публічний IP числом і закінчіть іменем хоста. Там, де ланцюг рветься, там і визначається шар. Відмова на першому кроці — це маршрутизація, на другому — пересилання або NAT, на третьому — розв'язання імен.

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

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Якщо час рукостискання порожній

Коли час рукостискання порожній, зашифрований обмін так і не завершився. Отже, збій лежить раніше за маршрутизацію. Спершу подивіться на адресу кінцевої точки й порт, потім на те, чи фільтрує мережа UDP. Хостер, який відкидає трафік WireGuard, дає саме це, і клієнт, який скопіював кінцеву точку зі старого профілю, теж.

Байти, які виходять, але не входять, — інший випадок. Це вказує на NAT або на міжмережевий екран, що повертає трафік не туди.

Якщо маршрут програє фізичному адаптеру

Для повного тунелю розділ партнера має покривати призначення, які ви збираєтеся використовувати. Windows іноді зберігає маршрут за замовчуванням фізичного адаптера навіть із налаштованим правилом для всього. Поділ правила для всього на 0.0.0.0/1 і 128.0.0.0/1 створює два конкретніші префікси, які виграють пошук. Поділ — документований обхід, а не перевага.

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

Якщо адреси працюють, а імена ні

WireGuard переносить пакети IP і не має думки про DNS. Поставте рядок DNS = у розділ інтерфейсу або налаштуйте адаптер через Windows. Без нього ping за адресою проходить, а кожне ім'я хоста не розв'язується, і користувачі повідомляють про це як про відсутність інтернету.

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

Якщо машина з Windows — це вихід

Internet Connection Sharing переписує адресацію, коли ввімкнений, що може перемістити спільний адаптер в інший діапазон. Клієнт, який досі вказує на початкову адресу, тоді перестає працювати. Значення реєстру ScopeAddress і StandaloneDHCPAddress керують цим діапазоном, і налаштування може відкотитися після перезавантаження.

Варто поглянути ще на два конфлікти, характерні для Windows. Служба Routing and Remote Access може заважати тунелю. Інсталятор, зібраний під неправильну архітектуру, падає з повідомленням, яке ніколи не згадує архітектуру.

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