El descobriment de Chromecast i DLNA no travessa mai una VPN encaminada

El botó de transmissió no mostra res, el VLC DLNA queda buit, i la màquina de l'altre extrem respon al ping sense queixes. Aquesta combinació no és un problema d'amplada de banda ni un enigma del tallafoc. El descobriment en aquests protocols és un intercanvi de grup al segment local, i un túnel encaminat no transporta trànsit adreçat a grup. La sessió que intenteu iniciar mai no s'ofereix.

L'abast hi és. El descobriment falta.

El mite: el túnel necessita un paràmetre o més capacitat

Els suggeriments habituals són habilitar el trànsit entre iguals, apujar l'MTU o canviar el tipus de dispositiu del túnel. Cap d'ells afegeix un domini de difusió. El multicast el lliuren els commutadors i la pila de xarxa local, i una interfície TUN punt a punt no té cap adreça de grup per inundar.

Canviar paràmetres pot fer més sorollosa la fallada. No pot fer aparèixer un anunci on el protocol no n'ha enviat mai cap.

Què és realment l'intercanvi de descobriment

Tres patrons cobreixen gairebé tot el que trobareu. mDNS envia a 224.0.0.251 per UDP 5353, SSDP envia a 239.255.255.250 per UDP 1900, i les llistes de navegació SMB més antigues anaven a l'adreça de difusió de la subxarxa. Cadascuna s'adreça a un grup i no a un equip, i cadascuna espera un oient al mateix segment. Un receptor a l'altre costat d'un túnel encaminat no és en aquest segment, així que no arriba res.

Fins i tot un anunci repetit porta una càrrega: normalment l'adreça LAN i el port de l'emissor, que el visor remot ha de poder assolir després.

Llegiu una captura abans de canviar el túnel

Captureu a la interfície del túnel mentre l'aplicació escaneja. Una captura buida vol dir que l'anunci no ha travessat mai la frontera, i cap ajust del túnel ho canvia. Els paquets que sí que apareixen mentre l'aplicació encara no mostra res solen indicar que l'adreça anunciada no és abastable des del visor, que és un problema d'encaminament disfressat de descobriment.

Dos minuts de captura substitueixen una hora d'endevinar ports: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tres solucions, la més barata primer

Apunteu el client directament a l'adreça del servei. Per a DLNA, SMB i servidors multimèdia senzills això salta el descobriment del tot i demostra que el camí de la càrrega funciona, cosa que el converteix en la millor primera prova i també en una solució provisional utilitzable. Chromecast n'és l'excepció, perquè el receptor espera ser trobat i no adreçat.

Reenvieu el protocol a la passarel·la. Un reflector mDNS repeteix els anuncis entre el túnel i la LAN, i Avahi porta una secció de reflector que pren una llista explícita d'interfícies. Manteniu el reenviament estret i confirmeu que l'adreça anunciada és abastable des de tots dos costats, o la resposta encara apunta a una subxarxa a la qual el visor no pot encaminar.

Ponteu en lloc d'encaminar. Un segment TAP amb el servidor connectant el dispositiu tap a la LAN posa tots dos extrems en un sol domini de difusió, així que els anuncis passen sense canvis. És també l'opció més cara, perquè una subxarxa significa un sol domini de fallada i cada servei multicast de la LAN arriba ara a cada igual.

Què no ajuda, per molt que es recomani

Canviar dev tun per dev tap sense un pont deixa un dispositiu TAP que encara és encaminat, així que el comportament no canvia. client-to-client permet unicast entre iguals i no inunda la difusió. Reenviar un port de descobriment a un sol equip no lliura trànsit adreçat a grup. Un servidor multimèdia lligat a una adreça continua responent en aquesta adreça fins que la seva pròpia configuració inclogui la interfície VPN.

Proveu una petició unicast directa i després una petició anunciada. Si la primera funciona i la segona no, el túnel és sa i el descobriment és tot el problema.