Клиент пишет «подключено», значок горит, а ни один сайт не открывается. Состояние сбивает с толку именно потому, что формально всё в порядке: соединение установлено.

Ниже — порядок проверок от самой частой причины к самой редкой. Каждый шаг отсекает целый класс проблем, поэтому идти лучше по очереди, а не пробовать наугад.

Шаг 1. Есть ли рукопожатие

Первое, что нужно выяснить: дошли ли ваши пакеты до сервера вообще. «Подключено» в интерфейсе клиента этого не гарантирует — WireGuard не устанавливает соединение в привычном смысле и показывает интерфейс поднятым сразу.

wg show

Смотрите на строку latest handshake. Если она есть и время в ней растёт разумно — сервер отвечает, переходите к шагу 2.

Если рукопожатия нет, а счётчик transfer: … sent растёт — пакеты уходят и не возвращаются. Причины: закрыт UDP-порт у провайдера или в сети, неверный адрес сервера, устаревший ключ. Проверьте, не изменился ли адрес — если в конфигурации записан IP, а сервер переехал, конфигурация перестаёт работать целиком.

Шаг 2. Проверьте по адресу, а не по имени

Разделяем сеть и разрешение имён — иначе перепутать их очень легко:

ping 1.1.1.1

Отвечает — маршрутизация работает, проблема в DNS. Переходите к шагу 3.

Не отвечает — трафик не доходит до туннеля или не уходит из него. Переходите к шагу 4.

Эта единственная команда разделяет две совершенно разные проблемы, которые внешне выглядят одинаково.

Шаг 3. DNS

Самая частая причина «подключено, но ничего не работает».

nslookup example.com

Если запрос не проходит или отвечает не тот сервер, что ожидался, дело в разрешении имён. Типичные ситуации:

  • в конфигурации указана строка DNS, но в системе нет resolvconf — на Linux wg-quick тогда молча её пропускает;
  • система использует systemd-resolved, и настройки нужно задавать через resolvectl, а не в файле;
  • резолвер прописан внутри туннеля, но маршрут до него не создан.

Быстрая проверка гипотезы: откройте любой сайт по адресу, а не по имени. Работает — точно DNS. Как это чинится и как проверять утечки, разобрано отдельно.

Шаг 4. Маршруты и AllowedIPs

Если не отвечает даже адрес, смотрим, куда система отправляет пакеты:

ip route get 1.1.1.1        # Linux
route get 1.1.1.1           # macOS

В выводе должен фигурировать интерфейс туннеля. Если там обычный сетевой адаптер — маршрут в туннель не создан.

Проверьте AllowedIPs в конфигурации. Для полного туннелирования там должно быть 0.0.0.0/0 — и ::/0, если нужен ещё и IPv6. Помните, что этот параметр управляет маршрутизацией, а не правами: узкий список означает, что остальной трафик пойдёт мимо.

На роутерах добавляется отдельная причина: интерфейс создан, но не помещён в зону файрвола, и пересылка из локальной сети в него запрещена. Симптом при этом ровно такой же.

Шаг 5. MTU

Особый случай, который легко принять за что-то другое: часть запросов проходит, а часть виснет. Мелкие страницы открываются, крупные замирают на середине.

Если картина такая — дело в размере пакета. Поставьте MTU = 1280 и проверьте снова. Подробный разбор с командами подбора — в отдельной статье.

Сводка

Что видим Где искать
Рукопожатия нет, отправлено растёт порт, адрес сервера, ключи
ping 1.1.1.1 идёт, имена не открываются DNS
ping 1.1.1.1 не идёт маршруты, AllowedIPs, зона файрвола
Часть сайтов работает, часть виснет MTU
Работает и снова отваливается keepalive и тайм-ауты

Если ничего не помогло

Проверьте самое скучное: не истекла ли подписка и не выдавался ли этот же ключ на другое устройство. Один ключ на двух устройствах одновременно не работает — пиры опознаются именно по ключу, и второе подключение выбивает первое.

Коротко

Порядок важнее набора действий. Рукопожатие отвечает на вопрос «дошли ли пакеты до сервера», ping по адресу разделяет проблемы сети и DNS, ip route get показывает, ушёл ли трафик в туннель, а выборочные зависания указывают на MTU. Четыре проверки закрывают подавляющее большинство случаев.