Пир WireGuard выходит через неправильный WAN: пять проверок по порядку

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

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

Выполните проверки ниже по порядку. У каждой есть условие остановки, а забегание вперёд обычно даёт уверенный неправильный ответ.

Отделите рукопожатие от перенаправленного потока

У зашифрованного обмена с пиром есть маршрут до публичного адреса сервера. У перенаправленного клиентского трафика другое назначение, и он может выбираться метками или правилами политики. Это два решения маршрутизации, которые делят один интерфейс. Считать одно доказательством о другом — первая ошибка.

Остановитесь, как только поймаете себя на рассуждении из рукопожатия. Оно доказывает только путь до конечной точки.

Читайте правило политики, а не таблицу по умолчанию

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

Проверьте метку и трансляцию вместе

Маршрутизация по политике опирается на метку пакета, выставленную раньше в цепочке. Если правило маркировки пропускает ваш трафик, поток проваливается в основную таблицу и уходит через то, что там по умолчанию. Перенаправленные пакеты часто обходят цепочки, написанные для локально созданного трафика.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

Следите, какой интерфейс несёт ответ

Снимайте трафик на обоих внешних каналах, пока идёт один запрос. Отметьте, какой интерфейс несёт запрос, а какой — ответ. Асимметричные пути гораздо легче увидеть, чем предсказать.

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

Измените одну вещь, оставив путь назад

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

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

Похожие статьи