Префикс хоста в WireGuard: почему работает один адрес, а остальные нет

Туннель поднят, handshake происходит каждые две минуты, и ровно один адрес на другой стороне отвечает. Пинги на туннельный адрес пира проходят; ничего за ним — нет. Кто-то читает конфигурацию интерфейса, видит префикс хоста и делает вывод, что маска неверна. Расширение до /24 чинит пинг на время, а потом ломает что-то другое. Префикс никогда не был причиной, и отсутствующий маршрут — не тот, которым управляет маска.

Что на самом деле создаёт префикс интерфейса

В Linux назначение адреса интерфейсу создаёт подключённый маршрут для этого префикса. Назначьте префикс хоста — подключённый маршрут покроет один адрес. Назначьте /24 — он покроет 256, и каждый из них теперь считается достижимым через этот линк.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs — это два правила под одним именем

Список разрешённых на каждого пира в WireGuard делает две работы одновременно, и синтаксис конфигурации заставляет их выглядеть как одна. На входе он разрешает, какие адреса источника пир может предъявить. На выходе он выбирает, какому пиру отправить пакет, находя самое точное совпадение.

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

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

Откуда берётся маршрут

Если вы используете wg-quick, маршруты создаются за вас из списка разрешённых каждого пира, если только вы не задали Table = off и не взяли управление на себя. Это документированное поведение инструмента, и именно поэтому конфигурация без явных директив маршрутизации всё равно работает.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Сравните список разрешённых с маршрутами, которые реально есть. Пир, разрешающий целую подсеть, но создавший только маршрут хоста, означает, что помощник ни разу не запускался, или что интерфейсом вы управляете напрямую через wg и ip, и тогда маршруты для вас никто не создаёт.

Когда вы управляете им вручную, маршрут — одна строка, и его форма явная: адресат через интерфейс, без шлюза, потому что линк «точка-точка». Добавить его — не обходной путь для плохого префикса; это недостающая половина решения, которое сознательно взяло маршрутизацию на себя.

Более широкий префикс не добавляет запись пира

Соблазнительное исправление — поменять адрес на /24, чтобы подключённый маршрут покрыл локальную сеть сервера. Кажется, что это работает, и причина в том, что подключённый маршрут теперь совпадает, а не в том, что WireGuard узнал что-то новое.

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

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

Подтвердите оба направления, прежде чем что-то менять

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

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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