El descubrimiento de Chromecast y DLNA nunca cruza una VPN enrutada

El botón de transmisión no muestra nada, VLC DLNA se queda vacío y la máquina del otro extremo responde al ping sin quejarse. Esa combinación no es un problema de ancho de banda ni un misterio del cortafuegos. El descubrimiento en estos protocolos es un intercambio de grupo en el segmento local, y un túnel enrutado no transporta tráfico dirigido a grupos. La sesión que intenta iniciar nunca se ofrece.

La accesibilidad está bien. Falta el descubrimiento.

El mito: el túnel necesita un ajuste o más capacidad

Las sugerencias habituales son habilitar el tráfico entre pares, subir la MTU o cambiar el tipo de dispositivo del túnel. Ninguna añade un dominio de difusión. El multicast lo entregan los conmutadores y la pila de red local, y una interfaz TUN punto a punto no tiene ninguna dirección de grupo que inundar.

Cambiar ajustes puede hacer el fallo más ruidoso. No puede hacer que aparezca un anuncio donde el protocolo nunca envió uno.

Qué es en realidad el intercambio de descubrimiento

Tres patrones cubren casi todo lo que encontrará. mDNS envía a 224.0.0.251 por UDP 5353, SSDP envía a 239.255.255.250 por UDP 1900, y las listas de exploración SMB más antiguas iban a la dirección de difusión de la subred. Cada una se dirige a un grupo y no a un host, y cada una espera un oyente en el mismo segmento. Un receptor al otro lado de un túnel enrutado no está en ese segmento, así que no llega nada.

Incluso un anuncio retransmitido lleva una carga útil: normalmente la dirección LAN y el puerto del emisor, que el visor remoto debe poder alcanzar después.

Lea una captura antes de cambiar el túnel

Capture en la interfaz del túnel mientras la aplicación escanea. Una captura vacía significa que el anuncio nunca cruzó el límite, y ningún ajuste del túnel lo cambia. Los paquetes que sí aparecen mientras la aplicación sigue sin mostrar nada suelen significar que la dirección anunciada no es alcanzable desde el visor, lo que es un problema de enrutamiento disfrazado de descubrimiento.

Dos minutos de captura sustituyen una hora de conjeturas sobre puertos: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tres soluciones, la más barata primero

Apunte el cliente directamente a la dirección del servicio. Para DLNA, SMB y servidores multimedia sencillos esto se salta el descubrimiento por completo y demuestra que la ruta de la carga útil funciona, lo que lo convierte en la mejor primera prueba y también en una solución provisional utilizable. Chromecast es la excepción, porque el receptor espera que lo encuentren y no que lo direccionen.

Retransmita el protocolo en la puerta de enlace. Un reflector mDNS repite los anuncios entre el túnel y la LAN, y Avahi incluye una sección de reflector que toma una lista explícita de interfaces. Mantenga la retransmisión estrecha y confirme que la dirección anunciada es alcanzable desde ambos lados, o la respuesta seguirá apuntando a una subred a la que el visor no puede enrutar.

Puente en lugar de enrutamiento. Un segmento TAP con el servidor puenteando el dispositivo tap en la LAN pone ambos extremos en un solo dominio de difusión, así que los anuncios cruzan sin cambios. Es también la opción más cara, porque una sola subred significa un solo dominio de fallo y cada servicio multicast de la LAN llega ahora a cada par.

Qué no ayuda, por mucho que se recomiende

Cambiar dev tun por dev tap sin un puente deja un dispositivo TAP que sigue enrutado, así que el comportamiento no cambia. client-to-client permite unicast entre pares y no inunda las difusiones. Reenviar un puerto de descubrimiento a un solo host no entrega tráfico dirigido a grupos. Un servidor multimedia vinculado a una dirección sigue respondiendo en esa dirección hasta que su propia configuración incluya la interfaz VPN.

Pruebe una petición unicast directa y luego una petición anunciada. Si la primera funciona y la segunda no, el túnel está sano y el descubrimiento es todo el problema.