Ситуация, когда WireGuard показывает активное подключение, но интернет не работает, обычно означает, что handshake состоялся, а пользовательский трафик не проходит дальше туннеля. Причину нужно искать в маршрутах, пересылке пакетов, NAT, AllowedIPs, DNS или размере MTU.

Не стоит сразу перевыпускать все ключи или переустанавливать сервер. Сначала определите, на каком участке останавливаются пакеты: клиент, интерфейс WireGuard, маршрутизация сервера, внешний сетевой интерфейс или DNS.

Что означает активный handshake

Handshake подтверждает, что клиент и сервер нашли друг друга, согласовали ключи и могут обмениваться служебными пакетами. Он не подтверждает правильность маршрута в интернет. Поэтому состояние «подключено» может сохраняться даже при отключенном IP forwarding или отсутствующем правиле NAT.

Что проверить в первую очередь

  • Посмотрите время последнего handshake и счетчики transfer в выводе wg show на сервере.
  • Проверьте, пингуется ли внутренний адрес WireGuard-сервера с клиента.
  • Попробуйте открыть внешний IP-адрес напрямую, чтобы отделить проблему DNS от маршрутизации.
  • Уточните имя внешнего интерфейса сервера: это может быть eth0, ens3, enp1s0 или другое значение.
  • Сохраните текущие правила firewall и маршрутизации перед изменениями.

Проверьте AllowedIPs на клиенте

AllowedIPs одновременно задает список адресов, которые разрешены для peer, и маршруты, направляемые в туннель. Для полного туннеля обычно используют 0.0.0.0/0 и, при необходимости, ::/0. Для выборочной маршрутизации указывают только конкретные подсети.

  • Убедитесь, что нужные адреса действительно входят в AllowedIPs клиента.
  • Проверьте, не создает ли другой VPN-клиент или корпоративный агент более приоритетный маршрут.
  • Для split tunneling не добавляйте весь интернет в туннель, если это не соответствует задаче.
  • Проверьте таблицу маршрутов после подключения, а не только содержимое конфигурационного файла.

Проверьте IP forwarding на сервере

Linux должен пересылать пакеты между интерфейсом WireGuard и внешним интерфейсом. Текущее состояние IPv4 можно проверить через sysctl net.ipv4.ip_forward. Для IPv6 используется отдельный параметр forwarding.

  • Если значение равно 0, временно включите forwarding для проверки.
  • После подтверждения причины сохраните параметр в системной конфигурации sysctl.
  • Убедитесь, что настройка не сбрасывается после перезагрузки или применения cloud-init.
  • Не включайте IPv6-маршрутизацию без подготовленного firewall и корректной схемы адресации.

Проверьте NAT и firewall

Если клиенты используют частную подсеть WireGuard, серверу обычно требуется masquerade или другое правило SNAT на внешнем интерфейсе. Ошибка часто появляется после переименования сетевого интерфейса, обновления firewall или смешивания iptables и nftables.

  • Проверьте, существует ли правило NAT для подсети WireGuard и фактического внешнего интерфейса.
  • Посмотрите счетчики правил: они должны увеличиваться при попытке открыть сайт с клиента.
  • Убедитесь, что цепочка FORWARD разрешает трафик из туннеля и обратные established/related пакеты.
  • Проверьте, какой backend используется системой: iptables-legacy, iptables-nft или чистый nftables.
  • Не отключайте firewall целиком. Добавьте минимальные диагностические правила и затем зафиксируйте итоговую политику.

Как отделить ошибку DNS

Если внешний IP открывается, а доменное имя нет, туннель и NAT, вероятнее всего, работают. Тогда нужно проверить DNS в клиентском профиле, доступность выбранного резолвера через туннель и системные настройки устройства.

  • Выполните запрос к конкретному DNS-серверу и сравните его с системным запросом.
  • Проверьте, не остается ли недоступный корпоративный DNS после подключения.
  • Убедитесь, что DNS-сервер входит в AllowedIPs при выборочной маршрутизации.
  • На мобильных устройствах проверьте взаимодействие профиля WireGuard с Private DNS и другими VPN-приложениями.

Когда виноват MTU

При неверном MTU небольшие пакеты и handshake проходят, а крупные HTTPS-запросы зависают. Это особенно заметно в сетях с дополнительной инкапсуляцией, PPPoE, мобильным интернетом или вложенными туннелями.

  • Сравните работу ping с запретом фрагментации и разными размерами пакета.
  • Временно уменьшите MTU интерфейса WireGuard и повторите открытие проблемных сайтов.
  • Не выбирайте случайно слишком маленькое значение: найдите рабочий предел и учтите накладные расходы туннеля.
  • Проверьте обе стороны и промежуточный канал, если проблема проявляется только в одной сети.

Пошаговая диагностика трафика

  • Убедитесь, что handshake свежий и счетчик отправленных клиентом байтов растет.
  • Проверьте доступность внутреннего IP сервера WireGuard.
  • На сервере запустите наблюдение трафика на wg-интерфейсе и внешнем интерфейсе.
  • Если пакет приходит в wg, но не выходит наружу, проверяйте forwarding, FORWARD и NAT.
  • Если пакет выходит, но ответ не возвращается, проверяйте обратный маршрут, NAT и фильтры провайдера.
  • Если обмен по IP работает, переходите к DNS.
  • Если работают только небольшие ответы, проверьте MTU и Path MTU Discovery.

Как безопасно исправить конфигурацию

  • Сделайте резервную копию конфигурации WireGuard и текущих правил firewall.
  • Исправляйте по одному уровню: маршрут, forwarding, firewall, NAT, DNS, затем MTU.
  • После каждого изменения повторяйте один и тот же контрольный сценарий.
  • Не публикуйте private key клиента или сервера в логах, скриншотах и обращениях за помощью.
  • Если private key уже раскрыт, перевыпустите пару ключей и удалите старый peer.

Как проверить результат

  • Клиент пингует внутренний адрес сервера и внешний IP через нужный маршрут.
  • DNS разрешает имена без задержек и утечек в нежелательный интерфейс согласно выбранной схеме.
  • HTTPS-сайты и загрузка крупных файлов работают, а не только ping.
  • Счетчики wg, firewall и NAT увеличиваются согласованно.
  • После перезагрузки сервера forwarding и правила firewall восстанавливаются.
  • Другие peer не потеряли доступ и не получили лишних маршрутов.

Типичные ошибки

  • Использовать eth0 в готовой команде, не проверив реальное имя внешнего интерфейса.
  • Добавить 0.0.0.0/0 и одновременно забыть маршрут до endpoint WireGuard.
  • Смешать правила iptables-legacy и nftables, из-за чего проверяется не тот набор правил.
  • Диагностировать DNS до проверки прохождения пакетов по IP.
  • Полностью отключить firewall и оставить сервер без защиты.
  • Пытаться решить отсутствие интернета заменой ключей, хотя handshake уже работает.

Как не допустить повторения

  • Храните конфигурацию firewall и sysctl как код или документированный набор правил.
  • После обновления ОС проверяйте backend firewall и восстановление правил при загрузке.
  • Добавьте мониторинг handshake, трафика и доступности контрольного адреса через туннель.
  • Зафиксируйте выбранную схему full tunnel или split tunnel для каждого профиля.
  • Периодически проверяйте резервное восстановление конфигурации без передачи приватных ключей в репозиторий.

Итог

Если WireGuard подключен, но интернета нет, начните с маршрута AllowedIPs и внутреннего IP, затем последовательно проверьте forwarding, firewall, NAT, DNS и MTU. Такая последовательность быстро показывает точку обрыва и позволяет обойтись без переустановки всего VPN-сервера.

Если причина остается неясной, я могу проверить конфигурацию WireGuard, маршруты и firewall, найти участок потери пакетов и аккуратно восстановить доступ без раскрытия приватных ключей.