Два 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. Саме ця трійка робить перекриття перевірним пізніше і набагато корисніша за знімок екрана конфігурації.