mDNS поверх WireGuard: три брами, доки пер не відповість
Avahi потрібен відповідний інтерфейс, маршрут до групи й пер, який володіє призначенням. Три брами, три окремі перевірки й жодного розгалуження.
Установлення прапорця multicast на пристрої WireGuard робить інтерфейс придатним для програм виявлення, і на цьому дія прапорця завершується. Він не повідомляє протоколу, куди має йти груповий пакет, а на пристрої з кількома перами немає однієї очевидної відповіді. Між працюючим демоном і виявленим сервісом стоять три окремі брами.
Перевіряйте їх по черзі, бо проходження однієї нічого не каже про наступну.
Перша брама: прапорець і політика демона
Пристрій WireGuard у Linux створюється як з'єднання точка-точка без ARP і за замовчуванням не несе прапорця multicast. Додавання прапорця — це локальна зміна інтерфейсу, яку виконує те, що керує пристроєм. Avahi має над цим власний погляд на світ, і його типова політика повністю пропускає інтерфейси точка-точка. Тому до руху хоча б одного пакета застосовуються дві незалежні перевірки придатності.
Отже, демону потрібне явне рішення, а не лише працюючий процес. Його документовані засоби керування включають allow-interfaces, deny-interfaces і allow-point-to-point, і останній — те налаштування, яке люди проґавлюють.
Перевірки нижче повідомляють прапорці з'єднання, маршрут multicast і те, чи конфігурація демона взагалі розбирається:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkУспішно запущений демон не обов'язково відкрив сокети на тому інтерфейсі, який вам важливий. Читайте його чинну конфігурацію, а не припускайте, що стан служби дорівнює покриттю.
Друга брама: маршрут до групи
Друга брама — звичайна маршрутизація. Пакет, адресований 224.0.0.251, іде за таблицею пересилання, як і все інше, і якщо таблиця відправляє його через фізичний інтерфейс LAN, жодна конфігурація WireGuard цього не змінить. Спершу виправте маршрут, і решта розслідування скоротиться. Подивіться, що ядро повідомляє про адресу групи, перш ніж торкатися будь-яких ключів перів.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Без конкретного маршруту ядро повертається до власної обробки multicast з'єднання, тому типово все виглядає правильно в плоскій LAN і неправильно, щойно той самий груповий трафік має вийти через тунель. Збій непомітний з боку відправника: запит іде кудись, а відповідь ніколи не надходить.
Третя брама: WireGuard вибирає одного пера на пакет
WireGuard вибирає вихідний пер, шукаючи призначення в наборах дозволених адрес, і шлях передавання Linux виконує цей пошук один раз на пакет. Результат один, і пакет шифрується для цього пера. Той самий префікс групи в дозволених списках кількох перів не створює членства чи реплікації; він створює неоднозначний пошук, який вирішується на одному з них.
На виділеному з'єднанні з двома кінцями це саме те, що потрібно, бо для навмисно перенесеного групового трафіку є один призначений отримувач. На інтерфейсі з п'ятьма перами це обмеження, а не властивість, і виправлення належить проєктуванню, а не конфігурації окремого пера.
Проєкту з розгалуженням потрібен явний ретранслятор, окремі з'єднання або зовсім інший механізм виявлення. Публікація рецепта для двох кінців як рішення для багатьох клієнтів через те, що кожен клієнт може пінгнути шлюз, — це спосіб розгорнути це неправильно.
Вхідний напрямок перевіряється інакше: джерело отриманого пакета має потрапляти в дозволений список автентифікованого пера. Додавання туди multicast-призначення не замінює реального володіння джерелом відправника.
Відображення — це межа, а не міст
Відбивач Avahi відтворює повідомлення mDNS між вибраними інтерфейсами на прикладному рівні. Це межа виявлення між мережами, а не Ethernet-міст і не загальний multicast-маршрутизатор. Два відбивачі, під'єднані до тих самих мереж, охоче створять петлю повторюваних оголошень.
Відображення також передає назви служб і їхні метадані до іншої мережі, що є рішенням про приватність не менше, ніж рішенням про маршрутизацію. Обмежте вибрані інтерфейси й використовуйте фільтри служб там, де встановлена версія їх підтримує, щоб межу перетинали лише оголошення, потрібні уповноваженому користувачеві.
Виявлення й використання залишаються окремими результатами. Клієнт може бачити оголошення служби, оголошена адреса якої недосяжна з місця, де перебуває клієнт, або порт якої відхиляє його політика доступу. Підтвердьте з'єднання зі службою після появи оголошення, і якщо застосунок підтримує стабільне DNS-ім'я або явну адресу сервера, віддайте перевагу цьому замість розширення локального виявлення з'єднання. Опис маршрутизації за криптоключем охоплює вибір пера за призначенням, від якого все це залежить.