Рукопожатие есть, интернета нет: что исправить первым на 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 может мешать туннелю. Установщик, собранный под неверную архитектуру, падает с сообщением, которое никогда не упоминает архитектуру.

Исправьте слой, который назвал тест, затем повторите те же три назначения. Изменение, которое чинит тест имени хоста, но ломает адрес туннеля, было применено не к тому слою.