Узел WireGuard недоступен, а другой работает: контрольный список

Один узел WireGuard пропускает трафик, а второй завершает рукопожатие, но так и не достигает ничего за туннелем. Работающий узел говорит вам, что интерфейс, UDP-порт и ключ сервера, скорее всего, в порядке. Он ничего не говорит про AllowedIPs второго узла, его внутренний адрес источника или правила пересылки между ними. Пройдите список по порядку и остановитесь на первом шаге, условие которого не выполняется.

Шаг 1: Запишите путь, который должен пройти пакет

Два клиента на одном концентраторе не достигают друг друга автоматически. В схеме «концентратор и спицы» сервер принимает пакет на wg0 и должен переслать его обратно из wg0 другому узлу, а для этого нужны пересылка IP и правило пересылки. В прямой схеме «узел к узлу» каждой стороне нужен адрес второй стороны и адрес её туннеля внутри AllowedIPs. Решите, какую схему вы отлаживаете, прежде чем читать любую конфигурацию.

Ожидаемый путь также говорит, куда смотреть. Если пакет должен пройти через концентратор, сбойное звено — это либо AllowedIPs отправителя, либо пересылка на концентраторе, либо AllowedIPs получателя. Если он должен идти напрямую, концентратор не важен, и значение имеют поля адреса второй стороны у обоих узлов.

Шаг 2: Сравните AllowedIPs с обеих сторон, а не только с одной

WireGuard использует AllowedIPs одновременно как таблицу маршрутизации и как список доступа. При отправке адрес назначения ищется в AllowedIPs узла, чтобы выбрать туннель; при получении внутренний адрес источника должен попадать в AllowedIPs отправляющего узла, иначе пакет отбрасывается. Отсутствующий диапазон с любой стороны даёт один и тот же симптом: транспорт работает, полезная нагрузка исчезает.

Читайте живое состояние, а не файл, потому что перезагрузка могла тихо не удаться: sudo wg show wg0 allowed-ips. На сервере запись сбойного узла должна включать адрес его туннеля, например 10.90.0.3/32. На клиенте запись узла-сервера должна включать проверяемое назначение, будь то адрес туннеля концентратора или удалённая подсеть. Перекрывающиеся диапазоны делают поиск неоднозначным и могут выбрать узел, который вы не имели в виду, поэтому держите их раздельно.

Шаг 3: Проверьте внутренний адрес источника

Клиент, который направляет 10.90.0.3 через wg0, но отправляет пакеты со своего адреса Wi-Fi, будет отклонён получателем, потому что источник не совпадает с AllowedIPs узла. Убедитесь, что именно выбирает ядро, с помощью ip route get 10.90.0.3 from 10.90.0.2, и подтвердите адрес, назначенный интерфейсу туннеля, с помощью ip -brief addr show wg0.

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

Шаг 4: Проверьте пересылку на концентраторе и обратный путь

Если концентратор должен пересылать между узлами, ядру нужен net.ipv4.ip_forward=1, а межсетевой экран должен принимать пересылаемый поток: вход на wg0, выход на wg0, от адреса туннеля отправителя к адресу получателя. Частая неисправность — правило входа, которое принимает UDP 51820, но правила пересылки нет], поэтому рукопожатие проходит, а полезная нагрузка гибнет. Перечислите действующие правила с помощью sudo nft list ruleset или эквивалента для вашего менеджера межсетевого экрана.

Затем проверьте ответ. У хоста назначения должен быть маршрут обратно к отправителю, либо через концентратор, либо через свой шлюз. Если концентратор также выполняет NAT для подсети туннеля, убедитесь, что трансляция применяется к пересылаемому потоку и что ответ доходит до концентратора до истечения состояния. Односторонний сбой, который выглядит как проблема с ключом, часто оказывается именно этим обратным маршрутом.

Наконец, отделите рукопожатие от данных. Узел, который завершает рукопожатие, но застревает на больших передачах, обычно имеет проблему MTU или MSS именно на этом пути, а не проблему AllowedIPs. Сначала проверьте малым ping, затем полноразмерным, и сравните оба узла.

Шаг 5: Измените одну вещь и не трогайте работающий узел

Сделайте единственное изменение на сбойном пути и повторите проверку обоих узлов. Замена AllowedIPs каждого узла на 0.0.0.0/0 — самый быстрый способ сломать уже работавший узел, потому что это меняет решение о маршрутизации для всего трафика на этом интерфейсе. Измените одну запись, перезагрузите и прочитайте живое состояние обратно.

Запишите, какой путь сработал, какой нет и точный вывод команды для каждого. Это сравнение ценнее общего отчёта о том, что VPN сломан, и именно его первым делом попросит следующий человек.