mDNS WireGuardi kohal: kolm väravat enne, kui peer vastab
Avahi vajab sobivat liidest, marsruuti gruppi ja peeri, kellele sihtkoht kuulub. Kolm väravat, kolm eraldi kontrolli ja mingit hargnemist.
Multicast-lipu seadmine WireGuardi seadmel muudab liidese avastustarkvarale sobivaks ja see on kõik, mida lipp teeb. See ei ütle protokollile, kuhu grupipakett peab minema, ja seadmel, kus on mitu peeri, pole ühtki ilmset vastust. Töötava deemon ja avastatud teenuse vahel seisab kolm eraldi väravat.
Katsetage neid järjekorras, sest ühe läbimine ei ütle teise kohta midagi.
Esimene värav: lipp ja deemon poliitika
Linuxi WireGuardi seade luuakse punkt-punkti ühendusena ilma ARP-ta ja see ei kanna multicast-lippu vaikimisi. Lipu lisamine on kohalik liidese muudatus, mille teeb see, mis seadet haldab. Avahil on selle peal oma maailmavaade ja selle vaikepoliitika jätab punkt-punkti liidesed täielikult vahele. Seega kehtib enne ühegi paketi liikumist kaks sõltumatut sobivustesti.
Nii et deemon vajab selget otsust, mitte ainult töötavat protsessi. Selle dokumenteeritud juhtelementide hulka kuuluvad allow-interfaces, deny-interfaces ja allow-point-to-point ning viimane on seade, mille inimesed jätavad märkamata.
Allolevad kontrollid teatavad lingi lipud, multicast-marsruudi ja selle, kas deemon konfiguratsioon üldse parsitakse:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkEdukalt käivitatud deemon pole tingimata avanud sokleid liidesel, mis teile oluline on. Lugege selle kehtivat konfiguratsiooni, selle asemel et eeldada, et teenuse olek võrdub katvusega.
Teine värav: marsruut gruppi
Teine värav on tavaline marsruutimine. Aadressile 224.0.0.251 saadetud pakett järgib edastustabelit nagu kõik muu, ja kui tabel saadab selle välja füüsilise LAN-liidese kaudu, ei muuda seda ükski WireGuardi konfiguratsioon. Parandage esmalt marsruut ja ülejäänud uurimine muutub lühemaks. Vaadake, mida kernel grupiaadressi kohta teatab, enne kui puudutate ükskõik milliseid peeri võtmeid.
| 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 |
Konkreetse marsruudi puudumisel laskub kernel lingi enda multicast-käsitlusse, mistõttu vaikeväärtus tundub lamedas LAN-is õige ja vale niipea, kui sama grupiliiklus peaks tunnelist väljuma. Tõrge on saatja poolt vaikne: päring läheb kuhugi ja vastus ei jõua kunagi kohale.
Kolmas värav: WireGuard valib ühe peeri paketi kohta
WireGuard valib väljamineva peeri, otsides sihtkohta lubatud aadressikogumitest, ja Linuxi saatmisteekond teeb seda otsingut üks kord paketi kohta. Tulemus on üks ja pakett krüpteeritakse selle peeri jaoks. Sama grupi eesliide mitme peeri lubatud loendites ei loo liikmelisust ega kordamist; see loob mitmetähendusliku otsingu, mis laheneb ühele neist.
Kahe otspunktiga sihtotstarbelisel ühendusel on see täpselt see, mida soovite, sest teadlikult kantaval grupiliiklusel on üks kavatsetud vastuvõtja. Viie peeriga liidesel on see piirang, mitte omadus, ja parandus kuulub disaini, mitte ühegi üksiku peeri konfiguratsiooni.
Hargnev disain vajab selget releed, eraldi ühendusi või hoopis teistsugust avastusmehhanismi. Kahe otspunkti retsepti avaldamine mitme kliendi lahendusena, sest iga klient saab lüüsi pingida, on viis, kuidas seda valesti juurutatakse.
Sissetulev suund on kontrollitud teisiti: vastuvõetud paketi allikas peab jääma autenditud peeri lubatud loendi sisse. Multicast-sihtkoha lisamine sinna ei asenda saatja tegelikku allikaomandit.
Peegeldus on piir, mitte sild
Avahi peegeldi kordab mDNS-sõnumeid valitud liideste vahel rakenduskihis. See on avastuspiir võrkude vahel, mitte Etherneti sild ja mitte üldine multicast-ruuter. Kaks samadesse võrkudesse ühendatud peegeldit loovad kergesti korduvate teadete ahela.
Peegeldus annab ka teenuste nimed ja nende metaandmed teisele võrgule üle, mis on privaatsusotsus sama palju kui marsruutimisotsus. Piirake valitud liideseid ja kasutage teenusefiltreid seal, kus paigaldatud versioon neid toetab, et piiri ületaksid ainult need teated, mida volitatud kasutaja vajab.
Avastamine ja kasutamine jäävad eraldi tulemusteks. Klient võib näha teadet teenuse kohta, mille kuulutatud aadress on kliendi asukohast kättesaamatu või mille porti tema juurdepääsupoliitika keeldub. Kinnitage teenuseühendus pärast teate ilmumist ja kui rakendus toetab püsivat DNS-nime või selget serveriaadressi, eelistage seda lingi-kohaliku avastuse laiendamisele. Krüptovõtme marsruutimise kirjeldus katab sihtkohapõhise peeri valiku, millest see kõik sõltub.