mDNS WireGuardin yli: kolme porttia ennen kuin peer vastaa
Avahi tarvitsee kelvollisen liitännän, reitin ryhmään ja peerin, joka omistaa kohteen. Kolme porttia, kolme erillistä tarkistusta eikä lainkaan hajautusta.
Multicast-lipun asettaminen WireGuard-laitteeseen tekee liitännästä kelvollisen löytöohjelmistoille, ja siihen lipun vaikutus loppuu. Se ei kerro protokollalle, minne ryhmäpaketin pitäisi mennä, eikä laitteessa, jossa on useita peerejä, ole yhtä ilmeistä vastausta. Käynnissä olevan daemonin ja löydetyn palvelun välissä on kolme erillistä porttia.
Testaa ne järjestyksessä, sillä yhden läpäiseminen ei kerro seuraavasta mitään.
Ensimmäinen portti: lippu ja daemonin käytäntö
Linuxin WireGuard-laite luodaan pisteestä pisteeseen -yhteytenä ilman ARP:ia, eikä se kanna multicast-lippua oletuksena. Lipun lisääminen on paikallinen liitännän muutos, jonka tekee mikä tahansa laitetta hallinnoiva taho. Avahilla on oma maailmankuvansa sen päällä, ja sen oletuskäytäntö ohittaa pisteestä pisteeseen -liitännät kokonaan. Ennen kuin yksikään paketti liikkuu, sovelletaan siis kahta riippumatonta kelpoisuustestiä.
Daemon tarvitsee siis nimenomaisen päätöksen, ei pelkkää käynnissä olevaa prosessia. Sen dokumentoituihin säätimiin kuuluvat allow-interfaces, deny-interfaces ja allow-point-to-point, ja viimeinen on asetus, jonka ihmiset jättävät huomaamatta.
Alla olevat tarkistukset raportoivat yhteyden liput, multicast-reitin ja sen, jäsennetäänkö daemonin kokoonpano ylipäätään:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkOnnistuneesti käynnistynyt daemon ei välttämättä ole avannut pistokkeita liitäntään, joka sinua kiinnostaa. Lue sen tehokas kokoonpano sen sijaan, että olettaisit palvelun tilan vastaavan kattavuutta.
Toinen portti: reitti ryhmään
Toinen portti on tavallinen reititys. Osoitteeseen 224.0.0.251 osoitettu paketti seuraa edelleenlähetystaulukkoa kuten kaikki muukin, ja jos taulukko lähettää sen fyysisen LAN-liitännän kautta ulos, mikään WireGuard-kokoonpano ei muuta sitä. Korjaa reitti ensin, niin tutkinnan loppu lyhenee. Katso, mitä ydin raportoi ryhmäosoitteesta, ennen kuin kosket mihinkään peer-avaimiin.
| 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 |
Ilman tiettyä reittiä ydin palaa yhteyden omaan multicast-käsittelyyn, minkä vuoksi oletus näyttää oikealta litteässä LAN:issa ja väärältä heti, kun saman ryhmän liikenteen pitäisi poistua tunnelin kautta. Virhe on lähettäjän puolelta hiljainen: kysely menee jonnekin, eikä vastausta koskaan saavu.
Kolmas portti: WireGuard valitsee yhden peerin pakettia kohden
WireGuard valitsee lähtevän peerin etsimällä kohdeosoitteen sallittujen osoitteiden joukoista, ja Linuxin lähetyspolku tekee tämän haun kerran pakettia kohden. Tuloksia on yksi, ja paketti salataan kyseiselle peerille. Sama ryhmäetuliite useiden peerien sallituissa luetteloissa ei luo jäsenyyttä eikä monistusta; se luo monitulkintaisen haun, joka ratkeaa yhteen niistä.
Kahden päätepisteen omistetulla yhteydellä tämä on juuri sitä, mitä haluat, koska tarkoituksella kuljetetulle ryhmäliikenteelle on yksi aiottu vastaanottaja. Viiden peerin liitännässä se on rajoitus, ei ominaisuus, ja korjaus kuuluu suunnitteluun, ei minkään yksittäisen peerin kokoonpanoon.
Hajautettu suunnittelu tarvitsee nimenomaisen releen, erilliset yhteydet tai kokonaan toisen löytömekanismin. Kahden päätepisteen reseptin julkaiseminen monen asiakkaan ratkaisuna siksi, että jokainen asiakas voi pingata yhdyskäytävää, on tapa, jolla tämä otetaan käyttöön väärin.
Saapuva suunta tarkistetaan eri tavalla: vastaanotetun paketin lähteen on kuuluttava todennetun peerin sallittuun luetteloon. Multicast-kohteen lisääminen sinne ei korvaa lähettäjän todellista lähteen omistajuutta.
Heijastus on raja, ei silta
Avahin heijastin toistaa mDNS-viestejä valitsemiensa liitäntöjen välillä sovelluskerroksessa. Se on löytöraja verkkojen välillä, ei Ethernet-silta eikä yleinen multicast-reititin. Kaksi samoihin verkkoihin liitettyä heijastinta luovat mielellään toistuvien ilmoitusten silmukan.
Heijastus luovuttaa myös palvelujen nimet ja niiden metatiedot toiselle verkolle, mikä on yksityisyyspäätös siinä missä reitityspäätös. Rajoita valittuja liitäntöjä ja käytä palvelusuodattimia siellä, missä asennettu versio tukee niitä, jotta vain valtuutetun käyttäjän tarvitsemat ilmoitukset ylittävät rajan.
Löytäminen ja käyttö pysyvät erillisinä tuloksina. Asiakas voi nähdä ilmoituksen palvelusta, jonka ilmoitettu osoite ei ole saavutettavissa asiakkaan sijainnista tai jonka portin sen käyttöoikeuskäytäntö hylkää. Vahvista palveluyhteys, kun ilmoitus ilmestyy, ja jos sovellus tukee pysyvää DNS-nimeä tai nimenomaista palvelinosoitetta, suosi sitä linkkipaikallisen löydön laajentamisen sijaan. Salausavainreitityksen kuvaus kattaa kohdeperusteisen peer-valinnan, josta kaikki tämä riippuu.