mDNS sobre WireGuard: tres portes abans que un parell respongui
Avahi necessita una interfície elegible, una ruta cap al grup i un parell que posseeixi la destinació. Tres portes, tres comprovacions separades i cap desplegament en ventall.
Establir el flag de multicast en un dispositiu WireGuard fa que la interfície sigui elegible per al programari de descobriment, i això és tot el que fa el flag. No diu al protocol on ha d'anar un paquet de grup, i en un dispositiu amb diversos parells no hi ha cap resposta òbvia única. Tres portes separades s'interposen entre un dimoni en execució i un servei descobert.
Proveu-les en ordre, perquè superar-ne una no us diu res sobre la següent.
Porta u: el flag i la política del dimoni
Un dispositiu WireGuard de Linux es crea com un enllaç punt a punt sense ARP, i no porta el flag de multicast per defecte. Afegir el flag és un canvi local d'interfície, fet per qualsevol cosa que gestioni el dispositiu. Avahi té la seva pròpia visió del món a sobre, i la seva política per defecte omet completament les interfícies punt a punt. Per tant, s'apliquen dues proves d'elegibilitat independents abans que es mogui un sol paquet.
Així doncs, el dimoni necessita una decisió explícita, no només un procés en execució. Els seus controls documentats inclouen allow-interfaces, deny-interfaces i allow-point-to-point, i l'últim és el paràmetre que la gent passa per alt.
Les comprovacions següents informen dels flags de l'enllaç, de la ruta de multicast i de si la configuració del dimoni s'analitza o no:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkUn dimoni que s'ha iniciat correctament no necessàriament ha obert sockets a la interfície que us importa. Llegiu la seva configuració efectiva en lloc de suposar que l'estat del servei equival a cobertura.
Porta dos: la ruta cap al grup
La segona porta és l'encaminament ordinari. Un paquet adreçat a 224.0.0.251 segueix la taula de reenviament com qualsevol altra cosa, i si la taula l'envia per la interfície LAN física, cap configuració de WireGuard ho canviarà. Arregleu primer la ruta i la resta de la investigació es fa més curta. Mireu què informa el nucli sobre l'adreça de grup abans de tocar cap clau de parell.
| 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 |
Sense una ruta específica, el nucli recorre al propi tractament de multicast de l'enllaç, i per això el comportament per defecte sembla correcte en una LAN plana i incorrecte tan bon punt el mateix trànsit de grup ha de sortir per un túnel. La fallada és silenciosa des del costat de l'emissor: la consulta va en algun lloc i la resposta no arriba mai.
Porta tres: WireGuard tria un parell per paquet
WireGuard selecciona un parell de sortida cercant la destinació en els conjunts d'adreces permeses, i el camí de transmissió de Linux fa aquesta cerca una vegada per paquet. Hi ha un sol resultat, i el paquet es xifra per a aquell parell. El mateix prefix de grup que apareix a les llistes permeses de diversos parells no crea pertinença ni replicació; crea una cerca ambigua que es resol en un d'ells.
En un enllaç dedicat de dos extrems això és exactament el que voleu, perquè hi ha un sol destinatari previst per al trànsit de grup portat deliberadament. En una interfície amb cinc parells és una limitació, no una característica, i la solució pertany al disseny i no a la configuració de cap parell concret.
Un disseny en ventall necessita un relé explícit, enllaços separats o un mecanisme de descobriment completament diferent. Publicar una recepta de dos extrems com a solució per a molts clients perquè cada client pot fer ping a la passarel·la és com això es desplega malament.
La direcció d'entrada es comprova de manera diferent: l'origen d'un paquet rebut ha de caure dins de la llista permesa del parell autenticat. Afegir-hi una destinació de multicast no substitueix la propietat real de l'origen de l'emissor.
La reflexió és una frontera, no un pont
El reflector d'Avahi reprodueix missatges mDNS entre les interfícies que selecciona, a la capa d'aplicació. És una frontera de descobriment entre xarxes, no un pont Ethernet ni un encaminador de multicast general. Dos reflectors connectats a les mateixes xarxes crearan fàcilment un bucle d'anuncis repetits.
La reflexió també lliura noms de servei i les seves metadades a una altra xarxa, cosa que és una decisió de privadesa tant com d'encaminament. Restringiu les interfícies seleccionades i feu servir filtres de servei on la versió instal·lada els admeti, perquè només creuin la frontera els anuncis que un usuari autoritzat necessita.
El descobriment i l'ús continuen sent resultats separats. Un client pot veure l'anunci d'un servei l'adreça anunciada del qual és inabastable des d'on és el client, o el port del qual la seva política d'accés rebutja. Confirmeu la connexió al servei un cop aparegui l'anunci, i si l'aplicació admet un nom DNS estable o una adreça de servidor explícita, preferiu-ho a ampliar el descobriment d'enllaç local. La descripció de l'encaminament per clau criptogràfica cobreix la selecció de parell basada en la destinació de què depèn tot això.