Короткий ответ

Handshake WireGuard доказывает только то, что UDP до endpoint vpn.example.com:51820 доходит и ключи совпали. Полезный трафик идёт отдельно: cryptokey routing по AllowedIPs, маршрут в таблице клиента и политика FORWARD/NAT на шлюзе. Если wg show показывает свежий handshake, а ping 10.8.0.1 или хост в 10.0.10.0/24 молчит — чините маршруты и фильтр, а не пересоздавайте ключи.

Сначала снимите wg show на обеих сторонах, ip route get 10.0.10.10 на клиенте и счётчики firewall. Не открывайте WAN «на всякий случай» и не ставьте AllowedIPs = 0.0.0.0/0, пока не решили, нужен ли full tunnel.

Симптомы и как отличить

Типичная картина:

  • latest handshake — секунды или минуты назад;
  • transfer почти не растёт после ping;
  • интерфейс wg0 UP, адрес 10.8.0.10/24 на месте;
  • ICMP в LAN или даже в peer туннеля таймаутится.

Отличия:

Что видноЭто не эта статьяКуда
Handshake никогда не появляетсяUDP, ключ, endpoint, времяHandshake отсутствует
Ping до 10.8.0.1 есть, LAN нетforwarding, обратный маршрут, SNATLAN недоступна
Крупные пакеты падают, мелкие проходятMTU/MSSMTU и MSS
Маршрутов к 10.0.10.0/24 нет в таблицеpush/Table/AllowedIPsМаршруты не добавляются

Возможные причины

От частых к редким:

  1. На клиенте в AllowedIPs нет 10.0.10.0/24 (или нет 10.8.0.0/24) — ядро не отправит пакет в туннель.
  2. На сервере в AllowedIPs пира нет /32 клиента (10.8.0.10/32) — входящий пакет с туннельного адреса отбрасывается cryptokey routing.
  3. wg-quick с Table = off — интерфейс есть, маршрутов нет.
  4. net.ipv4.ip_forward=0 на шлюзе или FORWARD drop в nftables/iptables/Windows Firewall.
  5. Обратный путь: хосты LAN не знают 10.8.0.0/24, а SNAT/MASQUERADE на шлюзе не включён.
  6. rp_filter или policy routing: ответ уходит не в wg0.
  7. Клиент Windows: профиль Public, блокировка ICMPv4, либо WireGuard-туннель без маршрутов в AllowedIPs.

Диагностика

Плейсхолдеры: endpoint vpn.example.com, UDP 51820, туннель 10.8.0.0/24, LAN 10.0.10.0/24. Подставьте свои.

1. Состояние пира

На Linux-клиенте и на сервере:

wg show
ip -4 addr show dev wg0
ip route
ip route get 10.0.10.10
ip route get 10.8.0.1

Нужны: свежий handshake, allowed ips с нужными префиксами, маршрут на wg0 для цели ping.

На Windows 11, если это встроенный RAS, а не WireGuard:

Get-VpnConnection | Format-List Name, ConnectionStatus, SplitTunneling, Guid
Get-NetRoute -AddressFamily IPv4 | Where-Object { $_.DestinationPrefix -match '10\.8\.|10\.0\.10\.' }

Для официального клиента WireGuard смотрите wg show из каталога установки и список AllowedIPs в конфиге туннеля.

2. Cryptokey routing

Сервер должен видеть пира с адресом, с которого клиент реально шлёт. Если клиент шлёт с 10.8.0.10, на сервере должно быть 10.8.0.10/32 (или покрывающий префикс) в AllowedIPs этого пира. Два пира с пересекающимися AllowedIPs — классика «handshake есть, трафик до одного из них нет».

3. Форвардинг и фильтр

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.wg0.rp_filter

Снимите счётчики, не отключая firewall:

iptables -L FORWARD -n -v
iptables -t nat -L POSTROUTING -n -v
nft list ruleset

Параллельно на WAN сервера убедитесь, что handshake-пакеты есть, а внутренний ICMP не появляется на wg0:

tcpdump -n -i any udp port 51820
tcpdump -n -i wg0 icmp

4. Windows-клиент

Get-NetIPInterface -AddressFamily IPv4 | Format-Table ifIndex, InterfaceAlias, ConnectionState, NlMtu, InterfaceMetric
Test-NetConnection 10.8.0.1
Test-NetConnection 10.0.10.10 -Port 3389

Если Test-NetConnection до 10.8.0.1 падает при живом handshake — пакет не уходит в туннель (AllowedIPs/маршрут) или режется локальным фильтром, а не «сломался WireGuard».

Решение

Сценарий A. Нет префикса LAN в AllowedIPs клиента

В конфиге клиента добавьте LAN и туннель явно:

[Interface]
Address = 10.8.0.10/24
PrivateKey = <ключ клиента>

[Peer]
PublicKey = <ключ сервера>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.0.10.0/24
PersistentKeepalive = 25

Перечитайте туннель (wg-quick down wg0 / up, либо перезапуск туннеля в GUI). Проверьте ip route get 10.0.10.10 — устройство должно быть wg0.

Сценарий B. Сервер не принимает адрес клиента

На сервере у пира должен быть уникальный AllowedIPs = 10.8.0.10/32. Не давайте двум пирам один и тот же /32. После правки:

wg syncconf wg0 <(wg-quick strip wg0)
wg show wg0 allowed-ips

Сценарий C. Нет маршрутов из-за Table = off

Уберите Table = off либо добавьте маршруты сами:

ip route add 10.0.10.0/24 dev wg0

Постоянно — в post-up или в netplan/NetworkManager, не «руками до перезагрузки».

Сценарий D. Форвардинг выключен или FORWARD drop

На шлюзе:

sysctl -w net.ipv4.ip_forward=1
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/99-ip-forward.conf

Разрешите FORWARD между wg0 и LAN-интерфейсом, не весь мир:

iptables -A FORWARD -i wg0 -o eth0 -s 10.8.0.0/24 -d 10.0.10.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -s 10.0.10.0/24 -d 10.8.0.0/24 -j ACCEPT

Если хосты LAN не имеют маршрута на 10.8.0.0/24, добавьте MASQUERADE только для VPN-подсети на LAN-интерфейсе — либо маршрут на шлюзе LAN. Не маскарадьте весь трафик офиса.

Сценарий E. Handshake есть, ICMP есть, TCP «зависает»

Это уже не AllowedIPs. Переходите к MTU и MSS и пошаговой диагностике.

Как проверить, что проблема устранена

С клиента:

wg show
ping -c 3 10.8.0.1
ping -c 3 10.0.10.10
ip route get 10.0.10.10

Ожидание: handshake обновляется, transfer растёт в обе стороны, ip route get показывает dev wg0, ping до узла LAN отвечает. С Windows — Test-NetConnection 10.0.10.10 с PingSucceeded : True либо успешный TCP к нужному порту.

На сервере wg show должен показывать ненулевой received/sent после вашей проверки, не только handshake.

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

  • Handshake жив, ping к 10.8.0.1 есть, до 10.0.10.10 нет — это уже LAN/forwarding, не ключи. Статья LAN недоступна.
  • Пересекающиеся 10.0.10.0/24 дома и в офисе — пакеты уходят в локальный NIC. Overlapping.
  • TCP открывается, SMB/RDP рвётся на крупных кадрах — MTU.
  • wg show на сервере не видит пира, хотя клиент пишет handshake — смотрите другой интерфейс/другой конфиг wg0 vs wg1.

Профилактика

  • Храните конфиги в git/ansible с уникальным /32 на пира; не копируйте один [Peer] двум людям.
  • Мониторьте latest handshake и рост transfer, не только «интерфейс UP».
  • Документируйте: туннель 10.8.0.0/24, LAN 10.0.10.0/24, UDP 51820, endpoint vpn.example.com.
  • Не смешивайте full tunnel и split без явной политики. Для служебного доступа достаточно LAN-префиксов.

FAQ

Почему handshake есть, а ping до 10.8.0.1 нет?

Потому что handshake не использует ваш ICMP. Ядро отправит ping в туннель только если адрес назначения покрыт AllowedIPs и есть маршрут. Иначе пакет уйдёт в LAN/WAN.

Нужно ли перевыпускать ключи?

Нет, если handshake уже устанавливается. Новые ключи не добавят маршрут и не откроют FORWARD.

Можно ли на время выключить firewall на сервере?

Нет как способ «починить VPN». Снимите counters и tcpdump. Если правило слишком узкое — расширьте его до пары интерфейсов и подсетей, затем верните лишнее закрытым.

Зачем PersistentKeepalive, если handshake уже есть?

Чтобы NAT на стороне клиента не забыл UDP-маппинг. На трафик после handshake это почти не влияет, на обрывы — да. См. периодические разрывы.

Клиент Windows пингует 10.8.0.1, Linux — нет, конфиги «одинаковые»

Сверьте AllowedIPs посимвольно и метрики маршрутов. GUI Windows иногда не применяет изменение, пока туннель не деактивировать. На Linux Table = off легко оставить в одном из файлов /etc/wireguard/.