WireGuard AllowedIPs: маршрут, который NetworkManager так и не добавил

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

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

Подтвердите туннель, прежде чем гнаться за маршрутом

wg show выводит интерфейс, пира, конечную точку и возраст последнего рукопожатия, а ip addr show подтверждает наличие адреса. Недавнее рукопожатие означает, что ключи, конечная точка и путь UDP работают. Всё сломанное находится ниже по потоку: маршрутизация, фильтрация или разрешение имён.

Затем спросите ядро, что оно сделает с реальным адресом назначения, а не с гипотетическим: ip route get 10.42.7.9. Ответ называет исходящий интерфейс и адрес источника, который понёс бы пакет. Когда он называет физический адаптер, пакет никогда не попадает в туннель, каким бы здоровым ни выглядело рукопожатие.

AllowedIPs — это фильтр и список маршрутов

Префиксы в AllowedIPs выполняют две задачи. Они выбирают, какой пир несёт исходящий адрес назначения, и проверяют адрес источника входящих пакетов, что и является границей маршрутизации по криптоключу. В wg-quick они также управляют автоматической установкой маршрутов, и именно это дополнительное поведение объясняет, почему одна и та же конфигурация работает из терминала, но не из настольного клиента.

В случае, стоящем за этой статьёй, профиль был импортирован через сторонний плагин, а не через встроенную поддержку, и интерфейс поднялся без префиксного маршрута. Перечисление таблицы показывает это сразу: ip route show содержит только подключённый маршрут для адреса интерфейса и ничего для удалённого диапазона.

Спросите, включены ли маршруты к пирам вообще

Прочитайте настройку, прежде чем что-либо менять: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Когда peer-routes показывает no, поддерживаемое исправление — nmcli connection modify work-wg wireguard.peer-routes yes, а затем повторное подключение. Добавление статического маршрута вместо этого работает до следующей активации и потом тихо исчезает. Это исчезновение и есть подсказка: маршрут, который каждое утро возвращается как загадка, устанавливает не профиль.

Если опция уже включена, проверьте с помощью ip route show table all | grep 10, не живёт ли префикс в другой таблице. Маршрут в таблице, которая не является основной, не отсутствует, он просто невидим для поиска, который смотрит только в основную таблицу. Исправьте политическую маршрутизацию вместо того, чтобы нагромождать сверху дублирующую запись.

Добавьте префикс в соединение, а не в работающую систему

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

Выберите самый узкий префикс, который покрывает нужные вам хосты. Копирование примера /8 от провайдера может проглотить локальные диапазоны, случайно оказавшиеся внутри, и возникшие сбои выглядят как сломанный туннель, а не как слишком широкий маршрут.

Разделённое туннелирование определяется списком префиксов

Переключателя разделённого туннеля не существует; список префиксов и есть решение. Пир с одним диапазоном для офисной LAN и одним для лабораторной сети отправляет через туннель ровно эти адреса назначения и оставляет всё остальное в покое. Одному хосту нужен /32, а пересекающимся диапазонам на двух площадках нужны префиксы хостов, пока кто-нибудь не перенумерует подсеть.

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

Один владелец таблицы маршрутов

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

Когда разделение должно следовать за физическим адаптером, а не за адресом назначения, вы перешли к политической маршрутизации, а политическая маршрутизация тоже требует одного автора. Проверьте, повторив ip route get, а затем достав до хоста внутри удалённого префикса чем-то, что выводит выбранный им адрес источника. Проверьте IPv6 и DNS отдельно, если профиль несёт что-то из этого.