mDNS preko WireGuarda: troja vrata prije nego što peer odgovori
Avahi treba podoban interfejs, rutu do grupe i peera koji posjeduje odredište. Troja vrata, tri odvojene provjere i nikakvo grananje.
Postavljanje multicast zastavice na WireGuard uređaju čini interfejs podobnim za softver za otkrivanje i to je sve što zastavica radi. Ona ne govori protokolu kuda grupni paket treba ići, a na uređaju s više peera nema jednog očiglednog odgovora. Između pokrenutog demonskog procesa i otkrivene usluge stoje troja odvojena vrata.
Testirajte ih po redu, jer prolazak kroz jedna ne govori ništa o sljedećim.
Prva vrata: zastavica i politika demona
Linux WireGuard uređaj se stvara kao point-to-point veza bez ARP-a i prema zadanim postavkama ne nosi multicast zastavicu. Dodavanje zastavice je lokalna promjena interfejsa koju izvodi sve što upravlja uređajem. Avahi ima svoj pogled na svijet iznad toga, a njegova zadana politika potpuno preskače point-to-point interfejse. Zato se prije nego što se pomjeri i jedan paket primjenjuju dva nezavisna testa podobnosti.
Dakle, demonu je potrebna izričita odluka, a ne samo pokrenut proces. Njegove dokumentovane kontrole uključuju allow-interfaces, deny-interfaces i allow-point-to-point, a posljednja je postavka koju ljudi propuštaju.
Provjere u nastavku prijavljuju zastavice veze, multicast rutu i to da li se konfiguracija demona uopšte parsira:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkDemon koji je uspješno pokrenut nije nužno otvorio sokete na interfejsu koji vas zanima. Čitajte njegovu efektivnu konfiguraciju umjesto da pretpostavljate da je status usluge jednak pokrivenosti.
Druga vrata: ruta do grupe
Druga vrata su obično rutiranje. Paket upućen na 224.0.0.251 slijedi tablicu prosljeđivanja kao i sve drugo, a ako ga tablica šalje kroz fizički LAN interfejs, nikakva WireGuard konfiguracija to neće promijeniti. Popravite prvo rutu i ostatak istrage postaje kraći. Pogledajte šta kernel prijavljuje za grupnu adresu prije nego što dotaknete bilo koje ključeve peera.
| 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 posebne rute kernel se vraća na vlastitu multicast obradu veze, zbog čega zadano izgleda ispravno na ravnoj LAN mreži, a pogrešno čim isti grupni saobraćaj treba izaći kroz tunel. Kvar je tih sa strane pošiljaoca: upit negdje ode, a odgovor nikada ne stigne.
Treća vrata: WireGuard bira jednog peera po paketu
WireGuard bira odlaznog peera traženjem odredišta u skupovima dozvoljenih adresa, a Linux putanja prijenosa obavlja to traženje jednom po paketu. Rezultat je jedan i paket se šifrira za tog peera. Isti grupni prefiks u dozvoljenim listama više peera ne stvara članstvo ni replikaciju; stvara dvosmisleno traženje koje se razrješava na jednog od njih.
Na namjenskoj vezi s dvije krajnje tačke to je upravo ono što želite, jer postoji jedan namjeravani primalac za svjesno preneseni grupni saobraćaj. Na interfejsu s pet peera to je ograničenje, a ne karakteristika, i popravka pripada dizajnu, a ne konfiguraciji bilo kojeg pojedinačnog peera.
Dizajn s grananjem zahtijeva izričit relej, odvojene veze ili potpuno drugačiji mehanizam otkrivanja. Objavljivanje recepta za dvije krajnje tačke kao rješenja za mnogo klijenata zato što svaki klijent može testirati gateway jest način da se to pogrešno postavi.
Dolazni smjer provjerava se drugačije: izvor primljenog paketa mora pasti unutar dozvoljene liste autentificiranog peera. Dodavanje multicast odredišta tamo ne zamjenjuje stvarno vlasništvo izvora pošiljaoca.
Refleksija je granica, a ne most
Avahijev reflektor reprodukuje mDNS poruke između interfejsa koje odabere, na aplikacijskom sloju. To je granica otkrivanja između mreža, a ne Ethernet most i ne opći multicast ruter. Dva reflektora spojena na iste mreže rado će stvoriti petlju ponovljenih objava.
Refleksija također predaje imena usluga i njihove metapodatke drugoj mreži, što je odluka o privatnosti koliko i odluka o rutiranju. Ograničite odabrane interfejse i koristite filtre usluga gdje ih instalirana verzija podržava, kako bi granicu prelazile samo objave koje ovlašteni korisnik treba.
Otkrivanje i korištenje ostaju odvojeni rezultati. Klijent može vidjeti objavu usluge čija je oglašena adresa nedostupna s mjesta na kojem klijent jest, ili čija vrata njegova politika pristupa odbija. Potvrdite vezu s uslugom nakon što se objava pojavi, i ako aplikacija podržava stabilno DNS ime ili izričitu adresu servera, dajte tome prednost umjesto proširenja link-local otkrivanja. Opis kriptoključnog rutiranja pokriva odabir peera prema odredištu na kojem sve ovo počiva.