mDNS sobre WireGuard: tres puertas antes de que un par responda
Avahi necesita una interfaz elegible, una ruta hacia el grupo y un par que posea el destino. Tres puertas, tres comprobaciones separadas y ninguna distribución en abanico.
Establecer la bandera de multicast en un dispositivo WireGuard hace que la interfaz sea elegible para el software de descubrimiento, y eso es todo lo que hace la bandera. No le dice al protocolo adónde debe ir un paquete de grupo, y en un dispositivo con varios pares no hay una única respuesta obvia. Tres puertas separadas se interponen entre un demonio en ejecución y un servicio descubierto.
Pruébelas en orden, porque superar una no le dice nada sobre la siguiente.
Primera puerta: la bandera y la política del demonio
Un dispositivo WireGuard de Linux se crea como un enlace punto a punto sin ARP, y no lleva la bandera de multicast de forma predeterminada. Añadir la bandera es un cambio local de la interfaz, realizado por lo que sea que gestione el dispositivo. Avahi tiene su propia visión del mundo por encima de eso, y su política predeterminada omite por completo las interfaces punto a punto. Por lo tanto, se aplican dos pruebas de elegibilidad independientes antes de que se mueva un solo paquete.
Así que el demonio necesita una decisión explícita, no solo un proceso en ejecución. Sus controles documentados incluyen allow-interfaces, deny-interfaces y allow-point-to-point, y el último es el ajuste que la gente pasa por alto.
Las comprobaciones siguientes informan de las banderas del enlace, la ruta de multicast y si la configuración del demonio se analiza siquiera:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkUn demonio que se inició correctamente no necesariamente ha abierto sockets en la interfaz que le importa. Lea su configuración efectiva en lugar de suponer que el estado del servicio equivale a cobertura.
Segunda puerta: la ruta hacia el grupo
La segunda puerta es el enrutamiento ordinario. Un paquete dirigido a 224.0.0.251 sigue la tabla de reenvío como cualquier otra cosa, y si la tabla lo envía por la interfaz LAN física, ninguna configuración de WireGuard lo cambiará. Arregle primero la ruta y el resto de la investigación se acorta. Mire lo que el kernel informa para la dirección de grupo antes de tocar cualquier 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 |
Sin una ruta específica, el kernel recurre al propio tratamiento de multicast del enlace, y por eso el comportamiento predeterminado parece correcto en una LAN plana e incorrecto en cuanto el mismo tráfico de grupo debe salir por un túnel. El fallo es silencioso desde el lado del emisor: la consulta va a algún sitio y la respuesta nunca llega.
Tercera puerta: WireGuard elige un par por paquete
WireGuard selecciona un par de salida buscando el destino en los conjuntos de direcciones permitidas, y la ruta de transmisión de Linux realiza esa búsqueda una vez por paquete. Hay un solo resultado, y el paquete se cifra para ese par. El mismo prefijo de grupo que aparece en las listas permitidas de varios pares no crea pertenencia ni replicación; crea una búsqueda ambigua que se resuelve en uno de ellos.
En un enlace dedicado de dos extremos esto es exactamente lo que quiere, porque hay un único destinatario previsto para el tráfico de grupo transportado deliberadamente. En una interfaz con cinco pares es una limitación, no una característica, y la corrección pertenece al diseño y no a la configuración de un par concreto.
Un diseño en abanico necesita un relé explícito, enlaces separados o un mecanismo de descubrimiento completamente distinto. Publicar una receta de dos extremos como solución para muchos clientes porque cada cliente puede hacer ping a la puerta de enlace es la forma en que esto se despliega mal.
La dirección entrante se comprueba de otra manera: el origen de un paquete recibido debe caer dentro de la lista permitida del par autenticado. Añadir allí un destino de multicast no sustituye la propiedad real del origen del emisor.
La reflexión es una frontera, no un puente
El reflector de Avahi reproduce mensajes mDNS entre las interfaces que selecciona, en la capa de aplicación. Es una frontera de descubrimiento entre redes, no un puente Ethernet ni un enrutador de multicast general. Dos reflectores conectados a las mismas redes crearán fácilmente un bucle de anuncios repetidos.
La reflexión también entrega nombres de servicio y sus metadatos a otra red, lo que es una decisión de privacidad tanto como de enrutamiento. Restrinja las interfaces seleccionadas y utilice filtros de servicio donde la versión instalada los admita, para que solo los anuncios que necesita un usuario autorizado crucen la frontera.
El descubrimiento y el uso siguen siendo resultados separados. Un cliente puede ver el anuncio de un servicio cuya dirección anunciada es inalcanzable desde donde está el cliente, o cuyo puerto su política de acceso rechaza. Confirme la conexión al servicio una vez que aparezca el anuncio, y si la aplicación admite un nombre DNS estable o una dirección de servidor explícita, prefiera eso a extender el descubrimiento local del enlace. La descripción del enrutamiento por clave criptográfica cubre la selección de par basada en el destino de la que depende todo esto.