Коротко: WireGuard подключается: Если WireGuard подключился, но трафик через VPN отсутствует, сначала проверьте, что в AllowedIPs клиента указан диапазон 0.0.0.0/0 для полного туннеля или нужная подсеть, а на сервере разрешена пересылка пакетов (IP forwarding) и настроен NAT. Часто проблема решается добавлением маршрута или корректировкой фаервола.
WireGuard подключается: Когда WireGuard трафик не идёт, несмотря на активный туннель и подтверждённое рукопожатие, причина почти всегда кроется в неправильной маршрутизации или параметре AllowedIPs. С виду соединение установлено, но пакеты уходят не в тот интерфейс или блокируются локальными правилами. Разобраться помогает последовательная диагностика и правка конфигурации на клиенте и сервере.
Основные причины
| Причина | Что это значит |
|---|---|
| Неправильный AllowedIPs на клиенте | Параметр AllowedIPs определяет, какие адреса будут маршрутизироваться через туннель. Если он не включает нужные сети (например, 0.0.0.0/0 для всего трафика), пакеты пойдут через основной интерфейс. |
| Отсутствие IP-форвардинга на сервере | Чтобы сервер мог передавать трафик между интерфейсами, в ядре должна быть включена пересылка пакетов (net.ipv4.ip_forward=1). Без неё сервер дропает пакеты, предназначенные другим узлам. |
| Не настроен NAT (MASQUERADE) на сервере | Если клиент использует внутренние адреса WireGuard (типа 10.0.0.x), сервер должен маскировать их под свой внешний IP при выходе в интернет, иначе обратные пакеты не вернутся. |
| Локальный фаервол блокирует трафик | Правила iptables/nftables или ufw могут запрещать пересылку пакетов между интерфейсами WireGuard и внешней сетью. Нужно разрешить FORWARD и MASQUERADE. |
| Конфликт подсетей | Адресное пространство WireGuard (например, 10.0.0.0/24) может пересекаться с локальной сетью клиента, из-за чего ОС отправляет пакеты в неправильный интерфейс. |
| Некорректный шлюз по умолчанию и метрики | Если на клиенте не изменена таблица маршрутизации, ОС может продолжить слать трафик через физический шлюз, игнорируя туннель, особенно при частичном AllowedIPs. |
| DNS-запросы уходят мимо VPN | Даже если трафик приложений идёт через туннель, системный резолвер иногда использует локальный DNS-сервер, что приводит к утечке. Проблема устраняется явным указанием DNS в конфиге WireGuard. |
Что проверить сначала
- Убедитесь, что handshake successful (вывод wg show).
- Проверьте вывод `ip route` на клиенте: появился ли маршрут до AllowedIPs через интерфейс wg0?
- Убедитесь, что на сервере включен IP forwarding: `sysctl net.ipv4.ip_forward`.
- Проверьте правила NAT на сервере: `iptables -t nat -L -v -n | grep MASQUERADE`.
- Проверьте фаервол: `iptables -L FORWARD -v -n` на сервере.
- Проверьте, не блокирует ли локальный брандмауэр клиента исходящий трафик с интерфейса wg0.
- Пропингуйте внутренний IP сервера WireGuard (например, 10.0.0.1) с клиента.
- Попробуйте пинговать внешний IP, например 8.8.8.8, с клиента при активном VPN.
- Проверьте AllowedIPs на обеих сторонах: на клиенте должно быть 0.0.0.0/0 или конкретная сеть, на сервере — IP клиента /32.
- Убедитесь, что DNS-запросы направляются через туннель: проверьте `nslookup example.com` и адрес DNS-сервера.
Пошаговое решение
- На сервере: включите IP-форвардинг. Выполните `echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf && sysctl -p`, проверьте `sysctl net.ipv4.ip_forward`.
- На сервере: настройте NAT для интерфейса WireGuard (wg0 или подобный). Если внешний интерфейс eth0, добавьте правило: `iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE` и сохраните.
- На сервере: разрешите пересылку трафика через фаервол: `iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT`. Сохраните правила.
- На клиенте: отредактируйте конфигурационный файл WireGuard (обычно wg0.conf). В секции [Peer] установите `AllowedIPs = 0.0.0.0/0`, чтобы направить весь трафик в туннель. Если нужен только доступ к определённой сети, укажите её, например 10.0.0.0/24.
- На клиенте: убедитесь, что нет конфликта подсетей. Если локальная сеть использует ту же подсеть, что и WireGuard, измените адресное пространство VPN на менее распространённое (например, 10.252.0.0/24).
- На клиенте: отключите и заново поднимите интерфейс: `wg-quick down wg0 && wg-quick up wg0`. Проверьте таблицу маршрутизации `ip route`, убедитесь, что появился маршрут по умолчанию через wg0.
- Проверьте связность: `ping 10.0.0.1` (адрес сервера). Если пинг не проходит, проверьте настройки сервера: фаервол, AllowedIPs (должен содержать IP клиента /32).
- Проверьте выход в интернет: `curl ifconfig.me` или `ping 8.8.8.8`. Если трафик не идёт, проверьте NAT на сервере (п.2).
- При необходимости настройте DNS: в клиентском конфиге в секции [Interface] укажите `DNS = 1.1.1.1` или другой публичный DNS.
- Если используется split-tunnel (только определённые подсети), проверьте метрики маршрутов: возможно, нужно вручную добавить маршрут с помощью `ip route add` или изменить метрику.
- При использовании NetworkManager или systemd-networkd может конфликтовать автоматическое управление. Попробуйте отключить управление WireGuard через них и использовать wg-quick напрямую.
- На мобильных клиентах убедитесь, что в настройках VPN выбрана опция «Весь трафик» или схожая, а не только трафик отдельных приложений.
Проверить проблему WireGuard
Введите ошибку, симптом или часть конфигурации: handshake, AllowedIPs, DNS, MTU, Endpoint.
FAQ
Почему после подключения WireGuard пинг на 10.0.0.1 идёт, а интернет не работает?
Скорее всего на сервере не настроен NAT для трафика из туннеля. Добавьте правило iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE и включите IP forwarding.
Достаточно ли указать AllowedIPs = 0.0.0.0/0 на клиенте?
Да, это направит весь трафик через VPN. Но также потребуется корректная маршрутизация на сервере, иначе пакеты не вернутся. Проверьте IP-форвардинг и NAT.
Как понять, что трафик уходит через VPN, а не через обычный интернет?
Выполните traceroute 8.8.8.8 или curl ifconfig.me — вы увидите внешний IP сервера VPN. Если отображается ваш локальный IP, туннель не используется для исходящего трафика.
Может ли проблема быть из-за DNS?
Да, если DNS-запросы резолвятся локально, сайты могут не открываться, создавая впечатление отсутствия трафика. Укажите DNS = 1.1.1.1 в конфиге клиента и перезапустите туннель.
Что делать, если на сервере несколько сетевых интерфейсов?
Убедитесь, что правило MASQUERADE применяется к правильному исходящему интерфейсу (обычно с внешним IP). Можно указать -o eth0 или использовать -s с адресом туннельной сети.
Как проверить, что фаервол сервера не блокирует трафик?
Временно отключите фаервол (ufw disable или iptables -P FORWARD ACCEPT) и проверьте связь. Если заработало, добавьте постоянные разрешающие правила.
Итог
Проблема «подключение есть, трафика нет» в WireGuard почти всегда решается настройкой AllowedIPs, включением IP-форвардинга и корректным NAT на сервере. Последовательная проверка маршрутов, фаервола и DNS помогает обнаружить и устранить неисправность за несколько минут.