WireGuard подключён, но трафик не идёт: AllowedIPs, маршруты, NAT, firewall и DNS

Handshake есть — что это реально значит

Handshake подтверждает, что ключи подходят, endpoint достижим и два peer способны обменяться служебными пакетами WireGuard. Но пользовательский трафик после этого ещё должен пройти обычную IP-маршрутизацию и firewall.

AllowedIPs: самый частый источник ошибок

В WireGuard AllowedIPs играет сразу две роли. На отправляющей стороне это определяет, какой трафик относится к конкретному peer. На принимающей стороне адрес источника пакета должен соответствовать AllowedIPs данного peer.

У Linux-инструмента wg-quick маршруты автоматически выводятся из AllowedIPs. Официальная man page прямо указывает, что wg-quick добавляет маршруты из списков allowed IPs peer, а при 0.0.0.0/0 или ::/0 отдельно обрабатывает default route.

Split tunnel: через VPN только нужные сети

[Peer]
AllowedIPs = 192.168.1.0/24

Такой клиент направит через WireGuard только трафик к сети 192.168.1.0/24. Обычный интернет продолжит идти через локальный Wi‑Fi или мобильную сеть.

Full tunnel: весь интернет через WireGuard

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0

Официальная документация MikroTik также использует 0.0.0.0/0 как пример для отправки всего IPv4-трафика через WireGuard.

Но одного AllowedIPs недостаточно. VPN-шлюз должен:

• разрешать forwarding WG → WAN;
• иметь маршрут в интернет;
• обычно выполнять source NAT/masquerade;
• предоставить рабочий DNS;
• корректно обрабатывать IPv6, если он также включён.

Проверьте маршруты

Если клиент должен попасть в 192.168.2.0/24, такой маршрут должен существовать либо через AllowedIPs, либо быть создан другим способом.

В site-to-site конфигурации маршруты нужны с обеих сторон, если обе сети должны инициировать соединения друг к другу.

Firewall: input и forward — не одно и то же

Если клиент пингует сам VPN-шлюз, но не видит устройства за ним, часто проблема именно в forwarding.

Документация MikroTik для IPv6 WireGuard прямо указывает необходимость firewall rule в forward chain для разрешения трафика клиента.

Когда нужен NAT / masquerade

Для full tunnel клиент обычно выходит в интернет через WAN VPN-шлюза. Если upstream не знает маршрута обратно к WireGuard-подсети, source NAT упрощает схему.

OpenWrt управляет masquerading на уровне firewall zone. В документации OpenWrt NAT/MASQUERADE описывается как per-zone настройка исходящего трафика.

Для доступа к LAN NAT не всегда обязателен. Более чистая схема — нормальная маршрутизация и обратный маршрут. Но в небольших сетях masquerade иногда используют, если изменить маршруты на LAN-устройствах нельзя.

IP открывается, а сайты нет — почти наверняка проверяйте DNS

1. Попробуйте ping по IP.
2. Попробуйте открыть DNS-сервер по его IP.
3. Проверьте, какой DNS выдан WireGuard-клиенту.
4. Проверьте firewall к UDP/TCP 53, если DNS локальный.
5. Убедитесь, что DNS-сервер принимает запросы из WireGuard subnet.

Если 1.1.1.1 доступен, а доменные имена нет, сам туннель и интернет-маршрут уже, вероятно, работают.

Одинаковые подсети с двух сторон: скрытая причина

Представим, что дома LAN 192.168.1.0/24. Пользователь приходит в гостиницу, где Wi‑Fi тоже использует 192.168.1.0/24.

Для домашних сетей, к которым планируется удалённый VPN-доступ, полезно использовать менее типичные приватные подсети, например из диапазона 10.0.0.0/8 или нестандартную сеть 192.168.x.0/24.

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

Если ping маленькими пакетами проходит, но сайты зависают, большие загрузки ломаются или отдельные HTTPS-сервисы не открываются, стоит проверить MTU/PMTU.

Не начинайте диагностику с MTU, если вообще не пингуется адрес WireGuard peer или LAN. Сначала исправьте AllowedIPs, маршруты и firewall.

PersistentKeepalive: для NAT, а не для исправления маршрутов

Официальный WireGuard Quick Start рекомендует PersistentKeepalive как механизм поддержания NAT/firewall mapping для peer за NAT. Типичное разумное значение для такого сценария — 25 секунд.

PersistentKeepalive = 25

По умолчанию функция выключена, и большинству peer она не нужна. PersistentKeepalive не исправит неверный AllowedIPs, отсутствующий route или запрещённый forward.

IPv6 может создавать отдельный маршрут мимо IPv4 VPN

Если клиент настроен только с 0.0.0.0/0, но устройство имеет рабочий IPv6 через локального провайдера, часть трафика может идти напрямую по IPv6.

Для полноценного dual-stack full tunnel нужны соответствующие IPv6 addresses, AllowedIPs, routes и firewall rules. MikroTik публикует отдельное руководство по WireGuard IPv6 с добавлением IPv6 allowed-address и forward rule.

MikroTik: что проверять

• /interface wireguard peers print detail — handshake и Allowed Address;
• /ip route print — маршруты;
• /ip firewall filter print — input и forward;
• /ip firewall nat print — masquerade для full tunnel;
• /ip dns — DNS, если роутер должен отвечать VPN-клиентам;
• адрес WireGuard interface и уникальность peer address.

В RouterOS Allowed Address для peer не должен конфликтовать с Allowed Address другого peer на том же интерфейсе.

OpenWrt: чаще всего проблема в firewall zone

На OpenWrt недостаточно создать WireGuard interface. Нужно определить, в какую firewall zone он входит и какие forwarding разрешены.

Официальные OpenWrt guides отдельно описывают WireGuard server/client и firewall zone/NAT конфигурацию.

Linux и wg-quick

У wg-quick AllowedIPs автоматически участвует в создании routes. Это удобно, но иногда удивляет при нескольких default routes, policy routing или нескольких VPN одновременно.

ip route
ip rule
wg show

Если конфигурация сложная, смотрите не только файл WireGuard, но и фактическую routing table после поднятия интерфейса.

Пошаговая диагностика: handshake есть, трафика нет

1. Проверьте IP WireGuard interface на обеих сторонах.
2. Проверьте latest handshake.
3. Пингуйте WireGuard IP противоположного peer.
4. Проверьте AllowedIPs.
5. Проверьте route к нужной LAN.
6. Проверьте firewall input, если обращаетесь к VPN-шлюзу.
7. Проверьте firewall forward, если идёте через шлюз.
8. Для full tunnel проверьте NAT/masquerade на WAN.
9. Проверьте DNS отдельно от IP-связности.
10. Проверьте конфликт локальной и удалённой подсети.
11. Если ломаются только большие пакеты, проверьте MTU.
12. Только затем добавляйте PersistentKeepalive, если peer за NAT.

Три типичных сценария по симптомам

Чего делать не нужно

Частые вопросы