mDNS přes WireGuard: tři brány, než peer odpoví
Avahi potřebuje vhodné rozhraní, trasu ke skupině a peera, který vlastní cílovou adresu. Tři brány, tři samostatné kontroly a žádné větvení.
Nastavení příznaku multicastu na zařízení WireGuard zpřístupní rozhraní pro software pro objevování, a tím účinek příznaku končí. Neříká protokolu, kam má skupinový paket jít, a na zařízení s několika peery neexistuje jediná zřejmá odpověď. Mezi běžícím démonem a objevenou službou stojí tři samostatné brány.
Testujte je popořadě, protože projití jedné nic neříká o té další.
První brána: příznak a politika démona
Zařízení WireGuard v Linuxu se vytváří jako spojení typu point-to-point bez ARP a ve výchozím nastavení nenosí příznak multicastu. Přidání příznaku je místní změna rozhraní, kterou provádí cokoli, co zařízení spravuje. Avahi má nad tím svůj vlastní pohled na svět a jeho výchozí politika rozhraní point-to-point zcela přeskakuje. Před pohybem jediného paketu tedy platí dva nezávislé testy vhodnosti.
Démon tedy potřebuje výslovné rozhodnutí, ne jen běžící proces. Jeho dokumentované ovládací prvky zahrnují allow-interfaces, deny-interfaces a allow-point-to-point, přičemž poslední je nastavení, které lidé přehlížejí.
Níže uvedené kontroly hlásí příznaky spoje, multicastovou trasu a to, zda se konfigurace démona vůbec parsuje:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkDémon, který se úspěšně spustil, nemusí nutně otevřít sockety na rozhraní, na kterém vám záleží. Čtěte jeho efektivní konfiguraci, místo abyste předpokládali, že stav služby se rovná pokrytí.
Druhá brána: trasa ke skupině
Druhou branou je běžné směrování. Paket adresovaný na 224.0.0.251 sleduje forwardovací tabulku jako všechno ostatní, a pokud jej tabulka odešle přes fyzické rozhraní LAN, žádná konfigurace WireGuard na tom nic nezmění. Nejdřív opravte trasu a zbytek vyšetřování se zkrátí. Podívejte se, co jádro hlásí pro skupinovou adresu, než se dotknete jakýchkoli klíčů peerů.
| 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 |
Bez konkrétní trasy se jádro vrací k vlastnímu zpracování multicastu spoje, a proto se výchozí chování jeví správně na ploché síti LAN a špatně, jakmile má stejný skupinový provoz odejít tunelem. Selhání je z pohledu odesílatele tiché: dotaz někam odejde a odpověď nikdy nedorazí.
Třetí brána: WireGuard volí jednoho peera na paket
WireGuard vybírá odchozího peera vyhledáním cíle v sadách povolených adres a linuxová cesta odesílání toto hledání provádí jednou na paket. Výsledek je jeden a paket se šifruje pro tohoto peera. Stejný skupinový prefix v povolených seznamech několika peerů nevytváří členství ani replikaci; vytváří nejednoznačné hledání, které se rozhodne pro jednoho z nich.
Na vyhrazeném spoji se dvěma konci je to přesně to, co chcete, protože existuje jeden zamýšlený příjemce pro záměrně přenášený skupinový provoz. Na rozhraní s pěti peery je to omezení, ne funkce, a oprava patří do návrhu, ne do konfigurace kteréhokoli jednotlivého peera.
Návrh s větvením potřebuje výslovný relay, samostatné spoje nebo úplně jiný mechanismus objevování. Zveřejnit recept pro dva konce jako řešení pro mnoho klientů proto, že každý klient může otestovat bránu, je způsob, jak to nasadit špatně.
Příchozí směr se kontroluje jinak: zdroj přijatého paketu musí spadat do povoleného seznamu ověřeného peera. Přidání multicastové cílové adresy tam nenahrazuje skutečné vlastnictví zdroje odesílatele.
Reflexe je hranice, ne most
Reflektor Avahi reprodukuje zprávy mDNS mezi rozhraními, která vybere, na aplikační vrstvě. Je to hranice objevování mezi sítěmi, ne Ethernetový most a ne obecný multicastový router. Dva reflektory propojené se stejnými sítěmi snadno vytvoří smyčku opakovaných oznámení.
Reflexe také předává názvy služeb a jejich metadata jiné síti, což je rozhodnutí o soukromí stejně jako o směrování. Omezte vybraná rozhraní a použijte filtry služeb tam, kde je nainstalovaná verze podporuje, aby hranici přecházela jen oznámení, která oprávněný uživatel potřebuje.
Objevování a použití zůstávají oddělenými výsledky. Klient může vidět oznámení služby, jejíž inzerovaná adresa je z místa klienta nedostupná, nebo jejíž port jeho přístupová politika odmítá. Po zobrazení oznámení potvrďte spojení se službou, a pokud aplikace podporuje stabilní název DNS nebo explicitní adresu serveru, dejte jim přednost před rozšiřováním link-local objevování. Popis směrování kryptoklíčem pokrývá výběr peera podle cíle, na kterém to všechno stojí.