Рукопожатие WireGuard работает, но офисная подсеть не отвечает

Рукопожатие завершается, wg show сообщает о недавней передаче, и адрес туннеля сервера отвечает на ping. А хост в локальной сети сервера — нет. Три условия должны выполняться одновременно: клиент должен направлять префикс локальной сети в туннель, сервер должен пересылать пакеты, а ответу нужен путь назад. Когда одного из трёх нет, симптом одинаков.

AllowedIPs — это и список доступа, и таблица маршрутизации

На клиенте список AllowedIPs решает и то, что можно отправлять этому узлу, и то, какие маршруты устанавливает WireGuard. Запись узла, где указан только адрес туннеля сервера, устанавливает один маршрут к хосту, поэтому назначения локальной сети никогда не попадают в туннель. Добавление префикса локальной сети — первое, что нужно проверить, и это же изменение чаще всего отсутствует после скопированной конфигурации. Узел, расширенный до маршрута по умолчанию, — это другая схема, и он также перенесёт интернет-трафик клиента.

Держите маршрут к хосту и префикс локальной сети отдельными записями. Если в офисе две подсети, обе принадлежат списку, и отсутствующий второй префикс даёт сбой, который выглядит избирательным, а не полным.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Пересылка и трансляция выполняются на сервере

Серверу нужно включённая пересылка IP, правило пересылки, принимающее трафик из туннеля, и правило трансляции в сторону его локального интерфейса. Именно трансляция позволяет схеме работать, не трогая каждый хост в офисной сети. Тогда ответы возвращаются на сервер, а не на адрес, о котором локальная сеть никогда не слышала. Без неё каждому хосту нужен маршрут к подсети туннеля и правило межсетевого экрана, которое его разрешает, а это редко приемлемо в сети, которой управляет кто-то другой.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Правила, добавленные вручную, исчезают при перезагрузке, поэтому привяжите их к интерфейсу командами-перехватчиками в конфигурации сервера. Набор правил, переживающий свой интерфейс, — это способ, которым машина в итоге транслирует трафик для туннеля, которого больше нет.

Когда локальная сеть переехала, а правило нет

Замена маршрутизатора, которая перенумеровывает офисную подсеть, — классическая версия этого сбоя. Туннель остаётся поднятым, рукопожатие остаётся свежим, и ничего за сервером не отвечает, потому что правило трансляции всё ещё называет старый адрес. Установочные скрипты часто вписывают локальный адрес сервера в правило POSTROUTING, и после перенумерации этого адреса нет ни на одном интерфейсе. Тогда пакеты перезаписываются на назначение, которое не может ответить.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Сравните два вывода. Цель трансляции, которой нет в списке интерфейсов, — это ошибка, и исправить её — изменение в одну строку, как только вы её увидите. Правило может жить в сгенерированном unit, а не в конфигурации WireGuard, поэтому перезагрузите этот unit после правки и убедитесь, что следующая загрузка не перезапишет ваше изменение.

Двум площадкам за NAT нужно место встречи

Когда ни одна сторона не принимает входящие соединения, практичный ответ — небольшой хост с публичным адресом и двумя интерфейсами WireGuard. Каждая площадка подключается наружу, средний хост перечисляет локальную сеть каждого узла в своём AllowedIPs, а пересылка переносит пакеты между двумя туннелями. Ничего в межсетевом экране ни одной из площадок менять не нужно, поэтому эта схема легко распространяется.

Маршрутизация между площадками сохраняет исходные адреса источника и потому сохраняет осмысленность журналирования по хостам. Трансляция на среднем хосте проще, когда две локальные сети пересекаются, но ценой потери идентичности источника в журналах. Решите, какое свойство важно, прежде чем выбирать.

Разделите уровни четырьмя проверками

Выполняйте одну проверку на уровень, а не меняйте три вещи в надежде на успех. Первая показывает возраст рукопожатия и счётчики для каждого узла. Вторая показывает, действительно ли клиент направляет это назначение в туннель. Третья и четвёртая говорят, дошёл ли запрос и отбросила ли его какая-либо политика после прибытия.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Запрос, который доходит и не вызывает ответа, указывает на путь ответа или на хост локальной сети. Запрос, который никогда не доходит, указывает на AllowedIPs или на маршрут клиента. Эти два исхода требуют разных исправлений, и именно захват позволяет их различить.