Пір 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 про простори імен і маршрутизацію описують, як навмисно відокремити шлях до кінцевої точки від тунельованого трафіку, що зазвичай чистіше, ніж копіювати обхідний варіант із маршрутом за замовчуванням.

Схожі статті