mDNS WireGuard fölött: három kapu, míg egy peer válaszol
Az Avahinak alkalmas interfészre, a csoporthoz vezető útvonalra és a célt birtokló peerre van szüksége. Három kapu, három külön ellenőrzés és semmiféle szétosztás.
A multicast jelző beállítása egy WireGuard-eszközön alkalmassá teszi az interfészt felderítő szoftverek számára, és a jelző ennyit tesz. Nem mondja meg a protokollnak, hova menjen egy csoportos csomag, és egy több peerrel rendelkező eszközön nincs egyetlen kézenfekvő válasz. Három külön kapu áll egy futó démon és egy felderített szolgáltatás között.
Sorrendben tesztelje őket, mert az egyik átlépése semmit sem mond a következőről.
Első kapu: a jelző és a démon irányelve
A Linux WireGuard-eszköz pont-pont kapcsolatként jön létre ARP nélkül, és alapértelmezésben nem viseli a multicast jelzőt. A jelző hozzáadása helyi interfész-változtatás, amelyet az eszközt kezelő bármi végez. Az Avahinak e fölött saját világképe van, és alapértelmezett irányelve teljesen kihagyja a pont-pont interfészeket. Ezért két független alkalmassági teszt érvényes, mielőtt egyetlen csomag is elmozdulna.
A démonnak tehát kifejezett döntésre van szüksége, nem csupán futó folyamatra. Dokumentált vezérlői közé tartozik a allow-interfaces, a deny-interfaces és a allow-point-to-point, és az utóbbi az a beállítás, amelyet az emberek kihagynak.
Az alábbi ellenőrzések a kapcsolat jelzőit, a multicast útvonalat és azt jelentik, hogy a démon konfigurációja egyáltalán feldolgozható-e:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEgy sikeresen elindult démon nem feltétlenül nyitott socketeket azon az interfészen, amely fontos Önnek. Olvassa el a tényleges konfigurációját, ahelyett hogy feltételezné, hogy a szolgáltatás állapota egyenlő a lefedettséggel.
Második kapu: az útvonal a csoporthoz
A második kapu a közönséges útválasztás. A 224.0.0.251 címre küldött csomag minden más csomaghoz hasonlóan követi a továbbítási táblát, és ha a tábla a fizikai LAN-interfészen küldi ki, semmilyen WireGuard-konfiguráció nem változtat ezen. Először az útvonalat javítsa, és a vizsgálat többi része rövidebb lesz. Nézze meg, mit jelent a kernel a csoportcímről, mielőtt bármely peer-kulcshoz hozzányúlna.
| 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 |
Konkrét útvonal nélkül a kernel a kapcsolat saját multicast-kezelésére esik vissza, ezért tűnik az alapértelmezés helyesnek egy lapos LAN-on, és helytelennek, amint ugyanannak a csoportos forgalomnak alagúton kellene elhagynia a hálózatot. A hiba a küldő oldaláról nézve csendes: a lekérdezés valahová elmegy, és a válasz soha nem érkezik meg.
Harmadik kapu: a WireGuard egy peert választ csomagonként
A WireGuard a kimenő peert úgy választja ki, hogy a célt az engedélyezett címkészletekben keresi, és a Linux továbbítási útvonala ezt a keresést csomagonként egyszer végzi el. Egyetlen eredmény van, és a csomag az adott peer számára titkosított. Ugyanaz a csoport-előtag, amely több peer engedélyezett listáján megjelenik, nem hoz létre tagságot vagy replikációt; kétértelmű keresést hoz létre, amely az egyiküknél dől el.
Két végpontos dedikált kapcsolaton ez pontosan az, amit szeretne, mert a szándékosan átvitt csoportos forgalomnak egyetlen szánt címzettje van. Öt peerrel rendelkező interfészen ez korlátozás, nem funkció, és a javítás a tervezésbe tartozik, nem egyetlen peer konfigurációjába.
A szétosztott tervezés kifejezett relét, külön kapcsolatokat vagy teljesen más felderítési mechanizmust igényel. A két végpontos receptet sok kliensre szóló megoldásként publikálni, mert minden kliens pingelheti az átjárót, az az út, ahogyan ezt rosszul telepítik.
A bejövő irányt másképp ellenőrzik: a fogadott csomag forrásának a hitelesített peer engedélyezett listáján belül kell lennie. Multicast célt oda felvenni nem pótolja a küldő valódi forrásbirtoklását.
A tükrözés határ, nem híd
Az Avahi tükrözője az általa kiválasztott interfészek között reprodukálja az mDNS-üzeneteket, alkalmazási szinten. Felderítési határ hálózatok között, nem Ethernet-híd és nem általános multicast-útválasztó. Két tükröző, amely ugyanazokhoz a hálózatokhoz csatlakozik, jókedvűen hoz létre ismétlődő bejelentések hurkát.
A tükrözés a szolgáltatásneveket és metaadataikat is átadja egy másik hálózatnak, ami ugyanannyira adatvédelmi döntés, mint útválasztási. Korlátozza a kiválasztott interfészeket, és használjon szolgáltatásszűrőket ott, ahol a telepített verzió támogatja őket, hogy csak az engedélyezett felhasználó által igényelt bejelentések lépjék át a határt.
A felderítés és a használat külön eredmény marad. Egy kliens láthat egy bejelentést olyan szolgáltatásról, amelynek hirdetett címe a kliens helyéről elérhetetlen, vagy amelynek portját a hozzáférési irányelve elutasítja. Erősítse meg a szolgáltatás kapcsolatát, miután a bejelentés megjelenik, és ha az alkalmazás támogat stabil DNS-nevet vagy kifejezett kiszolgálócímet, részesítse előnyben azt a link-lokális felderítés kiterjesztésével szemben. A kriptokulcsos útválasztás leírása lefedi a célalapú peer-választást, amelyen mindez nyugszik.