mDNS preko WireGuarda: tri kapije prije nego što peer odgovori
Avahi treba podoban interfejs, rutu do grupe i peera koji posjeduje odredište. Tri kapije, 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 tri odvojene kapije.
Testirajte ih po redu, jer prolazak jedne ne govori ništa o sljedećoj.
Prva kapija: 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će 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 kapija: ruta do grupe
Druga kapija je 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. Prvo popravite rutu i ostatak istrage postaje kraći. Pogledajte šta kernel prijavljuje za grupnu adresu prije nego što dodirnete 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 kapija: WireGuard bira jednog peera po paketu
WireGuard bira odlazni peer tako što traži odredište 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 značka, 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 jeste način da se to pogrešno postavi.
Dolazni smjer se provjerava 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.