O descubrimento de Chromecast e DLNA nunca cruza unha VPN encamiñada

O botón de transmisión non mostra nada, VLC DLNA queda baleiro e a máquina do outro extremo responde ao ping sen queixarse. Esa combinación non é un problema de ancho de banda nin un misterio do cortalumes. O descubrimento nestes protocolos é un intercambio de grupo no segmento local, e un túnel encamiñado non transporta tráfico dirixido a grupos. A sesión que intenta iniciar nunca se ofrece.

A accesibilidade está ben. Falta o descubrimento.

O mito: o túnel necesita un axuste ou máis capacidade

As suxestións habituais son habilitar o tráfico entre pares, subir a MTU ou cambiar o tipo de dispositivo do túnel. Ningunha engade un dominio de difusión. O multicast entrégano os conmutadores e a pila de rede local, e unha interface TUN punto a punto non ten ningunha dirección de grupo que inundar.

Cambiar axustes pode facer o fallo máis ruidoso. Non pode facer que apareza un anuncio onde o protocolo nunca enviou un.

Que é en realidade o intercambio de descubrimento

Tres patróns cobren case todo o que atopará. mDNS envía a 224.0.0.251 por UDP 5353, SSDP envía a 239.255.255.250 por UDP 1900, e as listas de exploración SMB máis antigas ían á dirección de difusión da subrede. Cada unha diríxese a un grupo e non a un host, e cada unha espera un oínte no mesmo segmento. Un receptor alén dun túnel encamiñado non está nese segmento, así que non chega nada.

Mesmo un anuncio retransmitido leva unha carga útil: normalmente a dirección LAN e o porto do emisor, que o visor remoto debe poder alcanzar despois.

Lea unha captura antes de cambiar o túnel

Capture na interface do túnel mentres a aplicación escanea. Unha captura baleira significa que o anuncio nunca cruzou o límite, e ningún axuste do túnel o cambia. Os paquetes que si aparecen mentres a aplicación segue sen mostrar nada adoitan significar que a dirección anunciada non é alcanzable desde o visor, o que é un problema de encamiñamento disfrazado de descubrimento.

Dous minutos de captura substitúen unha hora de conxecturas sobre portos: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tres solucións, a máis barata primeiro

Apunte o cliente directamente á dirección do servizo. Para DLNA, SMB e servidores multimedia sinxelos isto salta o descubrimento por completo e demostra que a ruta da carga útil funciona, o que o converte na mellor primeira proba e tamén nunha solución provisional utilizábel. Chromecast é a excepción, porque o receptor espera ser atopado e non dirixido.

Retransmita o protocolo na pasarela. Un reflector mDNS repite os anuncios entre o túnel e a LAN, e Avahi inclúe unha sección de reflector que toma unha lista explícita de interfaces. Manteña a retransmisión estreita e confirme que a dirección anunciada é alcanzable desde ambos os lados, ou a resposta seguirá apuntando a unha subrede á que o visor non pode encamiñar.

Ponte en lugar de encamiñamento. Un segmento TAP co servidor poñendo o dispositivo tap na LAN coloca ambos os extremos nun só dominio de difusión, así que os anuncios cruzan sen cambios. É tamén a opción máis cara, porque unha soa subrede significa un só dominio de fallo e cada servizo multicast da LAN chega agora a cada par.

Que non axuda, por moito que se recomende

Cambiar dev tun por dev tap sen unha ponte deixa un dispositivo TAP que segue encamiñado, así que o comportamento non cambia. client-to-client permite unicast entre pares e non inunda as difusións. Reenviar un porto de descubrimento a un só host non entrega tráfico dirixido a grupos. Un servidor multimedia ligado a unha dirección segue respondendo nesa dirección ata que a súa propia configuración inclúa a interface VPN.

Probe unha petición unicast directa e despois unha petición anunciada. Se a primeira funciona e a segunda non, o túnel está san e o descubrimento é todo o problema.