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 име или изричен адрес на сървър, предпочитайте това пред разширяването на локалното откриване. Описанието на маршрутизацията с криптоключ покрива избора на партньор по дестинация, на който всичко това се основава.