Коротко: WireGuard handshake нет доступа: Чаще всего причина в неправильных настройках DNS, слишком большом MTU или некорректных AllowedIPs. Проверьте, разрешает ли конфигурация маршрутизацию всего трафика, а затем протестируйте связь с внешним миром через пинг по IP и DNS.
Ситуация знакома: WireGuard handshake нет доступа — индикатор показывает зелёный, рукопожатие выполнено, но браузер упорно не открывает страницы. Проблема не в самом подключении, а в передаче данных после установки туннеля.
Основные причины
| Причина | Что это значит |
|---|---|
| Некорректный DNS-сервер | Handshake может выполняться успешно за счёт прямого IP-соединения, но DNS-запросы не доходят или используют неверный резолвер. Без работающего DNS браузер не сможет найти IP-адреса сайтов. |
| Неподходящий MTU | Размер максимального пакета (MTU) слишком велик для туннеля, что вызывает фрагментацию или потерю пакетов. Особенно часто страдают HTTPS-сайты, требующие целостности TCP-сессии. |
| Неверные AllowedIPs | Если в секции пира не указан параметр AllowedIPs = 0.0.0.0/0 (или нужная подсеть), трафик не маршрутизируется в туннель. Клиент успешно аутентифицируется, но не отправляет пакеты веб-трафика. |
| Отсутствует IP Forwarding на сервере | Сервер не пересылает пакеты между интерфейсами (wg0 и внешним). Без параметра net.ipv4.ip_forward=1 трафик клиента остановится на сервере. |
| Не настроен NAT/Masquerade | Пакеты от клиента приходят с внутреннего адреса VPN и не могут выйти в интернет без преобразования адреса источника. Требуется правило iptables с MASQUERADE. |
| Блокировка трафика файерволом | Локальный или серверный брандмауэр может разрешать UDP-пакеты WireGuard (и handshake), но блокировать проходящий трафик после установки туннеля. |
| Конфликт подсетей | Если локальная сеть клиента использует ту же адресацию, что и туннель или удалённая сеть (например, 192.168.1.0/24), маршрутизация может запутаться, и пакеты уходят не туда. |
| Проблемы с NAT на стороне клиента | Жёсткий NAT или двойной NAT у провайдера может нарушать проброс портов после handshake, особенно при отсутствии PersistentKeepalive. |
Что проверить сначала
- Проверьте пинг до 8.8.8.8 (IP Google). Если IP пингуется, проблема с DNS.
- Выполните ping с большим пакетом: ping -f -l 1472 8.8.8.8 (Windows) или ping -s 1472 -M do 8.8.8.8 (Linux). Если пакет не проходит, нужен меньший MTU.
- Убедитесь, что в конфигурации клиента AllowedIPs содержит 0.0.0.0/0 и ::/0 (если нужен весь трафик).
- Проверьте, прописаны ли DNS-серверы в секции [Interface] клиента: DNS = 8.8.8.8 или адрес DNS внутри туннеля.
- Пропингуйте внутренний IP сервера в туннеле (например, 10.0.0.1). Если пинг не идёт, проблема в самом туннеле или маршрутизации.
- На сервере выполните sysctl net.ipv4.ip_forward и убедитесь, что значение 1.
- Посмотрите таблицу маршрутизации клиента (route -n или route print), нет ли перекрытия новых маршрутов.
- Проверьте логи WireGuard (journalctl -u wg-quick@wg0 на Linux) на ошибки сразу после handshake.
- Временно отключите файервол на клиенте и повторите тест. Если трафик пошёл, настройте разрешающее правило.
- Убедитесь, что порт сервера (по умолчанию 51820/udp) доступен извне и не закрыт провайдером или роутером.
Пошаговое решение
- Пропишите DNS-серверы в клиентской конфигурации: в секцию [Interface] добавьте DNS = 8.8.8.8, DNS = 1.1.1.1. Перезапустите интерфейс.
- Уменьшите MTU в конфигурации клиента до 1280: в секции [Interface] добавьте MTU = 1280. Переподключите туннель.
- Убедитесь, что в секции пира на клиенте указано AllowedIPs = 0.0.0.0/0, ::/0. Если нужен только трафик к определённым сайтам, укажите соответствующие подсети.
- На сервере активируйте форвардинг: sudo sysctl -w net.ipv4.ip_forward=1 и добавьте net.ipv4.ip_forward=1 в /etc/sysctl.conf для постоянного эффекта.
- Настройте NAT на сервере для интерфейса, выходящего в интернет: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE (замените eth0 на ваш WAN-интерфейс). Для сохранения правил используйте iptables-save.
- Добавьте разрешающие правила в фаервол сервера для трафика туннеля: iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT.
- На клиенте Windows откройте командную строку с правами администратора и выполните route print. Если присутствует маршрут по умолчанию с меньшей метрикой, измените метрику виртуального адаптера WireGuard в его свойствах IP.
- Если не нужен IPv6, временно удалите IPv6-адреса из AllowedIPs и из [Interface] (или закомментируйте), чтобы сузить проблему.
- Убедитесь, что Endpoint клиента содержит корректный внешний IP и порт сервера. Проверьте проброс порта на роутере, если сервер за NAT.
- Добавьте PersistentKeepalive = 25 в конфигурацию клиента в секцию пира, чтобы поддерживать туннель через NAT.
- Запустите на сервере захват пакетов: tcpdump -i wg0. Попробуйте открыть сайт с клиента. Смотрите, уходят ли пакеты от туннельного интерфейса во внешнюю сеть.
- Если после всех шагов трафик не идёт, соберите полный дамп трафика клиента и сервера и выполните детальный анализ маршрутизации и фильтрации.
Проверить проблему WireGuard
Введите ошибку, симптом или часть конфигурации: handshake, AllowedIPs, DNS, MTU, Endpoint.
FAQ
Почему после подключения WireGuard я не могу открыть сайты, хотя рукопожатие есть?
Вероятно, не настроена маршрутизация DNS или параметр AllowedIPs не включает весь трафик. Проверьте, указаны ли DNS-серверы и AllowedIPs = 0.0.0.0/0.
Менять MTU безопасно?
Да, уменьшение MTU до 1280–1350 часто решает проблемы с передачей пакетов без снижения безопасности. Рекомендуется протестировать значение с помощью пинга.
Как проверить, работает ли DNS через WireGuard?
Выполните nslookup example.com с указанием DNS-сервера туннеля, например nslookup example.com 10.0.0.1 (IP сервера в туннеле). Если запрос не проходит, проблема в DNS.
Что делать, если IP-адреса пингуются, а домены нет?
Это указывает на проблему с DNS. Пропишите публичный DNS в конфигурации клиента или настройте DNS-сервер внутри туннеля.
Может ли антивирус или файервол блокировать трафик после handshake?
Да, некоторые локальные файерволы или антивирусы могут блокировать исходящий трафик виртуального адаптера. Временно отключите их для проверки и добавьте интерфейс в доверенную сеть.
Почему handshake успешен, но через несколько минут трафик падает?
Возможно, сессия рвется из-за NAT. Добавьте PersistentKeepalive = 25 в конфигурацию клиента для поддержания соединения.
Итог
Проблема «рукопожатие есть, сайты не открываются» почти всегда сводится к неправильной маршрутизации, DNS или MTU. Последовательно проверяя таблицу маршрутизации, настройки AllowedIPs, DNS и параметры форвардинга, вы быстро найдёте узкое место. Корректно настроенный туннель WireGuard должен пропускать трафик так же надёжно, как и устанавливать соединение.