Петля маршруту за замовчуванням у WireGuard: знайдіть шлях до кінцевої точки

Інтерфейс піднімається, конфігурація партнера виглядає правильно, і жодне рукостискання так і не завершується. Додавання маршруту за замовчуванням через тунель — це крок, який часто це спричиняє: та сама таблиця маршрутизації тепер вирішує, куди мають іти власні зашифровані пакети тунелю, і відповідь, яку вона видає, веде назад у тунель. Ніщо не може нести зовнішній пакет, який ніс би внутрішній, тому з'єднання зупиняється, не почавшись. Виправлення невелике, але має порядок, і перевірка важливіша за редагування.

Підтвердьте петлю, перш ніж змінити маршрут

Прочитайте поточну адресу кінцевої точки партнера і потім запитайте стек маршрутизації, куди піде пакет на цю адресу. Якщо відповідь називає інтерфейс тунелю, петлю підтверджено і подальша діагностика не потрібна. Збережіть обидва виводи в журналі змін, перш ніж чогось торкатися, бо порівняння після виправлення — це ті самі дві команди. Петля не тонка, щойно її побачиш; складність у тому, що інтерфейс виглядає здоровим, поки це відбувається.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Включіть правила політики до цього запису. Маршрут за замовчуванням, який виглядає правильним у головній таблиці, все ще може програти правилу, що вибирає іншу таблицю для позначеного чи непозначеного трафіку, і петля з'явиться знову з таблицею маршрутів, яка виглядає гаразд.

Читайте шлях до кінцевої точки, а не шлях тунелю

Шлях до кінцевої точки — це маршрут, яким зашифровані дейтаграми йдуть до публічної адреси партнера, і він має залишатися поза тунелем, поки тунель існує. Шлях тунелю — це все, що партнеру дозволено нести. Ці два шляхи поділяють одну таблицю маршрутизації, і саме тому один запис, що охоплює все, може зіштовхнути їх одне в одного. Розділення трафіку тунелю та власного транспорту тунелю — це вся проблема проєктування, і кожен підтримуваний інструмент вирішує її десь трохи інакше.

Перевірте обидві родини адрес окремо, якщо інтерфейс несе обидві. Робоче виключення IPv4 нічого не каже про те, чи ще доступна кінцева точка IPv6, і змішана конфігурація може виглядати робочою, доки не буде вибрано адресу IPv6 партнера.

Відновіть шлях до кінцевої точки однією узгодженою зміною

Існують два підтримувані підходи, і їх змішування — це те, що робить робочу установку непередбачуваною. Перший — дозволити інструменту, який володіє інтерфейсом, керувати всім тунелем: wg-quick має спеціальну обробку для діапазону партнерів за замовчуванням, яка встановлює окрему таблицю, правила політики та позначку сокета, що утримує зовнішні пакети поза тунелем. Залиште цей механізм недоторканим, замість того щоб відтворювати половину його вручну. Установка, яка змішує вручну доданий маршрут за замовчуванням із менеджером, що вже встановлює позначки й правила, зазвичай зазнає невдачі після повторного підключення, коли менеджер перезаписує стан, який передбачав ручний крок.

Другий — ручний дизайн, у якому кінцева точка отримує явний маршрут до хоста через фізичний шлюз. Додайте цей маршрут перед маршрутом за замовчуванням, замініть, а не додайте, щоб застарілий запис не міг перемогти, і підтвердьте пошук після цього.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Перевірте, а потім збережіть шлях назад

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

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Перш за все збережіть поточний стан маршрутизації та переконайтеся, що є шлях входу, який не залежить від тунелю: консоль, адреса позасмугового керування або колега на місці. Віддалену машину, яка втратила маршрут за замовчуванням, не можна відновити через з'єднання, яке вона щойно втратила, і найбезпечніший крок у runbook — той, що зроблено перед першою командою.