Два peer-а WireGuard делят диапазон: кому достанется пакет
Перекрывающиеся диапазоны разрешаются самым конкретным префиксом, а не порядком. Сначала проверьте маршрут, затем список peer-ов, прежде чем что-то расширять.
Два peer-а перечисляют диапазоны, которые соприкасаются, и трафик попадает не к тому. Ничего не повреждено: WireGuard выбирает peer, сопоставляя пункт назначения с настроенными диапазонами, и побеждает самое конкретное совпадение. Прежде чем что-то расширять, решите, какой peer должен владеть каким префиксом.
Самый длинный префикс побеждает внутри WireGuard
Каждая запись peer-а несёт набор префиксов назначения. Когда пакет направляется в интерфейс, реализация ищет запись с самым конкретным подходящим префиксом — то же правило, которое применяет таблица маршрутизации. Поэтому /24 побеждает /16, который его содержит, и более узкий peer получает трафик.
Конфигурации road-warrior используют это намеренно. Один peer владеет широким диапазоном для площадки, а отдельные хосты выделяются записями /32, которые принадлежат другим peer-ам. Схема работает потому, что выделения более конкретны, а не из-за порядка.
Запишите владение в виде таблицы префикса и peer-а. Если две записи описывают один и тот же префикс, конфигурация больше не выражает намерение, она выражает гонку.
Операционная система сначала выбирает интерфейс
WireGuard выбирает только среди peer-ов на одном интерфейсе. Какой интерфейс получит пакет, решается раньше — таблицей маршрутизации хоста, и второй маршрут по умолчанию или устаревший маршрут может отправить трафик туда, где список peer-ов его никогда не видит. Поэтому диагностика на уровне peer-а может быть верной и всё же не объяснять сбой. Проверьте маршрут до пункта назначения, прежде чем читать конфигурацию peer-а, потому что маршрут, указывающий на физический интерфейс, обходит весь вопрос.
Инструмент обычно устанавливает эти маршруты из диапазонов peer-ов, а значит, изменение в списке одного peer-а может молча перенаправить трафик, который раньше принадлежал другому. Поэтому редактирование peer-а — это замаскированное изменение маршрутизации. Просмотрите оба сразу, иначе исправите одно и сломаете другое.
Входящие пакеты проверяются по источнику
Список диапазонов выполняет двойную роль. Для исходящего трафика он выбирает peer по назначению, а для входящего — авторизует адрес источника. Пакет, пришедший с адреса вне диапазонов этого peer-а, отбрасывается до того, как его увидит какой-либо фаервол.
Эту асимметрию легко упустить, читая одну сторону конфигурации. Peer, который может достичь подсети, не получает из-за этого права отправлять из этой подсети, и оба направления обеспечиваются разными проверками.
Узкое владение источником превращает это в преимущество. Дайте каждому peer-у /32 для его собственного адреса, и фаервол ниже получит надёжный источник для сопоставления, а не диапазон на всю группу, на который мог бы претендовать любой участник.
Дублирующиеся диапазоны — это не failover
Назначение одного и того же префикса двум peer-ам не создаёт балансировщик нагрузки или резервный путь. Нет ни проверки состояния, ни привязки сеансов: побеждающая запись определяется внутренним порядком реализации, а это не контракт, на который стоит проектировать. Если нужны альтернативные выходы, выражайте их там, где определён выбор. Политика маршрутизации, метрика или пара разных префиксов с документированным владельцем каждого дают поведение, которое можно предсказать и проверить.
Расширение диапазона, чтобы исправить несвязанный сбой, — другая распространённая ошибка. Оно уводит трафик от peer-а, который работал, и новый симптом появляется раньше, чем старый понят.
Проверьте выбор перед редактированием
Три команды по порядку отвечают на три вопроса. Первая перечисляет диапазоны, на которые претендует каждый peer. Вторая показывает, какой интерфейс хост использовал бы для пункта назначения. Третья показывает живое состояние peer-ов после того, как трафик прошёл.
wg show wg0 allowed-ips ip route get 10.66.8.20 wg show wg0 ip rule show
Запустите их до и после изменения и сравните. Если вывод маршрута изменился, но трафик по-прежнему приходит не к тому peer-у, списки префиксов перекрываются так, как вы ещё не описали. Если вывод маршрута не изменился, конфигурация peer-а никогда не была тем, что рассматривалось.
Запишите в заявку пункт назначения, выбранный интерфейс и выбранный peer. Именно эта тройка делает перекрытие проверяемым позже и гораздо полезнее снимка экрана конфигурации.