mDNS sobre WireGuard: tres portas antes de que un par responda
Avahi necesita unha interface elixible, unha ruta cara ao grupo e un par que posúa o destino. Tres portas, tres comprobacións separadas e ningunha distribución en abano.
Establecer a bandeira de multicast nun dispositivo WireGuard fai que a interface sexa elixible para o software de descubrimento, e iso é todo o que fai a bandeira. Non lle di ao protocolo cara a onde debe ir un paquete de grupo, e nun dispositivo con varios pares non hai unha única resposta obvia. Tres portas separadas se interpoñen entre un daemon en execución e un servizo descuberto.
Próbeas en orde, porque superar unha non lle di nada sobre a seguinte.
Primeira porta: a bandeira e a política do daemon
Un dispositivo WireGuard de Linux créase como unha ligazón punto a punto sen ARP, e non leva a bandeira de multicast por defecto. Engadir a bandeira é un cambio local da interface, realizado por calquera cousa que xestione o dispositivo. Avahi ten a súa propia visión do mundo por riba diso, e a súa política por defecto omite por completo as interfaces punto a punto. Por iso se aplican dúas probas de elixibilidade independentes antes de que se mova un só paquete.
Así que o daemon necesita unha decisión explícita, non só un proceso en execución. Os seus controis documentados inclúen allow-interfaces, deny-interfaces e allow-point-to-point, e o último é o axuste que a xente pasa por alto.
As comprobacións seguintes informan das bandeiras da ligazón, da ruta de multicast e de se a configuración do daemon se analiza ou non:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkUn daemon que se iniciou correctamente non necesariamente abriu sockets na interface que lle importa. Lea a súa configuración efectiva en lugar de supor que o estado do servizo equivale á cobertura.
Segunda porta: a ruta cara ao grupo
A segunda porta é o encamiñamento ordinario. Un paquete dirixido a 224.0.0.251 segue a táboa de reenvío como calquera outra cousa, e se a táboa o envía pola interface LAN física, ningunha configuración de WireGuard o cambiará. Arranxe primeiro a ruta e o resto da investigación acúrtase. Mire o que o kernel informa para o enderezo de grupo antes de tocar calquera clave de par.
| 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 |
Sen unha ruta específica, o kernel recorre ao propio tratamento de multicast da ligazón, e por iso o comportamento por defecto parece correcto nunha LAN plana e incorrecto en canto o mesmo tráfico de grupo debe saír por un túnel. O fallo é silencioso desde o lado do emisor: a consulta vai a algunha parte e a resposta nunca chega.
Terceira porta: WireGuard elixe un par por paquete
WireGuard selecciona un par de saída buscando o destino nos conxuntos de enderezos permitidos, e a ruta de transmisión de Linux realiza esa busca unha vez por paquete. Hai un só resultado, e o paquete cifrase para ese par. O mesmo prefixo de grupo que aparece nas listas permitidas de varios pares non crea pertenza nin replicación; crea unha busca ambigua que se resolve nun deles.
Nunha ligazón dedicada de dous extremos isto é exactamente o que quere, porque hai un único destinatario previsto para o tráfico de grupo transportado deliberadamente. Nunha interface con cinco pares é unha limitación, non unha característica, e a corrección pertence ao deseño e non á configuración dun par concreto.
Un deseño en abano necesita un relé explícito, ligazóns separadas ou un mecanismo de descubrimento completamente distinto. Publicar unha receita de dous extremos como solución para moitos clientes porque cada cliente pode facer ping á pasarela é a forma en que isto se despregou mal.
A dirección de entrada compróbase doutro xeito: a orixe dun paquete recibido debe caer dentro da lista permitida do par autenticado. Engadir alí un destino de multicast non substitúe a propiedade real da orixe do emisor.
A reflexión é unha fronteira, non unha ponte
O reflector de Avahi reproduce mensaxes mDNS entre as interfaces que selecciona, na capa de aplicación. É unha fronteira de descubrimento entre redes, non unha ponte Ethernet nin un encamiñador de multicast xeral. Dous reflectores conectados ás mesmas redes crearán facilmente un bucle de anuncios repetidos.
A reflexión tamén entrega nomes de servizo e os seus metadatos a outra rede, o que é unha decisión de privacidade tanto como de encamiñamento. Restrinxa as interfaces seleccionadas e utilice filtros de servizo onde a versión instalada os admita, para que só os anuncios que necesita un usuario autorizado crucen a fronteira.
O descubrimento e o uso seguen sendo resultados separados. Un cliente pode ver o anuncio dun servizo cuxo enderezo anunciado é inalcanzable desde onde está o cliente, ou cuxo porto a súa política de acceso rexeita. Confirme a conexión ao servizo unha vez que apareza o anuncio, e se a aplicación admite un nome DNS estable ou un enderezo de servidor explícito, prefira iso a estender o descubrimento local da ligazón. A descrición do encamiñamento por clave criptográfica cobre a selección de par baseada no destino da que depende todo isto.