mDNS preko WireGuarda: tri vrata prije nego što peer odgovori
Avahi treba podobno sučelje, rutu do grupe i peera koji posjeduje odredište. Tri vrata, tri odvojene provjere i nikakvo grananje.
Postavljanje multicast zastavice na WireGuard uređaju čini sučelje podobnim za softver za otkrivanje i to je sve što zastavica radi. Ona ne govori protokolu kamo grupni paket treba ići, a na uređaju s više peera nema jednog očitog odgovora. Između pokrenutog demonskog procesa i otkrivene usluge stoje troja odvojena vrata.
Testirajte ih po redu, jer prolazak jednih ne govori ništa o sljedećima.
Prva vrata: zastavica i politika demona
Linux WireGuard uređaj stvara se kao point-to-point veza bez ARP-a i prema zadanim postavkama ne nosi multicast zastavicu. Dodavanje zastavice lokalna je promjena sučelja 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 sučelja. Zato se prije nego što se pomakne i jedan paket primjenjuju dva neovisna testa podobnosti.
Dakle, demonu je potrebna izričita odluka, a ne samo pokrenut proces. Njegove dokumentirane 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 parsira li se konfiguracija demona uopće:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkDemon koji je uspješno pokrenut nije nužno otvorio sockete na sučelju koje vas zanima. Čitajte njegovu efektivnu konfiguraciju umjesto da pretpostavljate da je status usluge jednak pokrivenosti.
Druga vrata: ruta do grupe
Druga su vrata 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čko LAN sučelje, nikakva WireGuard konfiguracija to neće promijeniti. Popravite prvo rutu i ostatak istrage postaje kraći. Pogledajte što 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 promet treba izaći kroz tunel. Kvar je tih sa strane pošiljatelja: 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 dopuštenih 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 dopuštenim popisima 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 točke to je upravo ono što želite, jer postoji jedan namjeravani primatelj za svjesno preneseni grupni promet. Na sučelju s pet peera to je ograničenje, a ne značajka, i popravak 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 toč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 dopuštenog popisa autentificiranog peera. Dodavanje multicast odredišta tamo ne zamjenjuje stvarno vlasništvo izvora pošiljatelja.
Refleksija je granica, a ne most
Avahijev reflektor reproducira mDNS poruke između sučelja koja 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 odabrana sučelja 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 poslužitelja, 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.