Il rilevamento di Chromecast e DLNA non attraversa mai una VPN instradata

Il pulsante di trasmissione non elenca nulla, VLC DLNA resta vuoto e la macchina all'altro capo risponde al ping senza lamentarsi. Questa combinazione non è un problema di larghezza di banda né un mistero del firewall. Il rilevamento in questi protocolli è uno scambio di gruppo sul segmento locale, e un tunnel instradato non trasporta traffico con indirizzo di gruppo. La sessione che state cercando di avviare non viene mai offerta.

La raggiungibilità va bene. Manca il rilevamento.

Il mito: il tunnel ha bisogno di un'impostazione o di più capacità

I suggerimenti abituali sono abilitare il traffico peer-to-peer, alzare l'MTU o cambiare il tipo di dispositivo del tunnel. Nessuno di essi aggiunge un dominio di broadcast. Il multicast è consegnato dagli switch e dallo stack di rete locale, e un'interfaccia TUN punto a punto non ha alcun indirizzo di gruppo da inondare.

Cambiare le impostazioni può rendere il guasto più rumoroso. Non può far comparire un annuncio dove il protocollo non ne ha mai inviato uno.

Che cos'è davvero lo scambio di rilevamento

Tre schemi coprono quasi tutto ciò che incontrerete. mDNS invia a 224.0.0.251 su UDP 5353, SSDP invia a 239.255.255.250 su UDP 1900, e le vecchie liste di esplorazione SMB andavano all'indirizzo di broadcast della sottorete. Ognuna è indirizzata a un gruppo e non a un host, e ognuna si aspetta un ascoltatore sullo stesso segmento. Un ricevitore oltre un tunnel instradato non è su quel segmento, quindi non arriva nulla.

Anche un annuncio inoltrato porta un carico utile: di solito l'indirizzo LAN e la porta del mittente, che lo spettatore remoto deve poi poter raggiungere.

Leggete una cattura prima di cambiare il tunnel

Catturate sull'interfaccia del tunnel mentre l'app esegue la scansione. Una cattura vuota significa che l'annuncio non ha mai superato il confine, e nessuna regolazione del tunnel lo cambia. I pacchetti che compaiono comunque mentre l'app non mostra ancora nulla di solito significano che l'indirizzo annunciato non è raggiungibile dallo spettatore: è un problema di instradamento in costume da rilevamento.

Due minuti di cattura sostituiscono un'ora di congetture sulle porte: tcpdump -ni tun0 udp port 5353 or udp port 1900.

Tre soluzioni, la più economica per prima

Puntate il client direttamente all'indirizzo del servizio. Per DLNA, SMB e semplici server multimediali questo salta del tutto il rilevamento e dimostra che il percorso del carico utile funziona, il che lo rende il miglior primo test e anche una soluzione temporanea utilizzabile. Chromecast è l'eccezione, perché il ricevitore si aspetta di essere trovato e non indirizzato.

Inoltrate il protocollo al gateway. Un riflettore mDNS ripete gli annunci tra il tunnel e la LAN, e Avahi fornisce una sezione riflettore che accetta un elenco esplicito di interfacce. Mantenete l'inoltro stretto e confermate che l'indirizzo annunciato sia raggiungibile da entrambi i lati, altrimenti la risposta punta ancora a una sottorete verso cui lo spettatore non può instradare.

Fate un bridge invece di instradare. Un segmento TAP in cui il server collega in bridge il dispositivo tap alla LAN mette entrambe le estremità nello stesso dominio di broadcast, così gli annunci passano invariati. È anche l'opzione più costosa, perché una sola sottorete significa un solo dominio di guasto e ogni servizio multicast della LAN ora raggiunge ogni peer.

Cosa non aiuta, per quanto spesso venga suggerito

Passare da dev tun a dev tap senza un bridge lascia un dispositivo TAP ancora instradato, quindi il comportamento non cambia. client-to-client consente l'unicast tra peer e non inonda i broadcast. Inoltrare una porta di rilevamento a un solo host non consegna traffico con indirizzo di gruppo. Un server multimediale legato a un indirizzo continua a rispondere su quell'indirizzo finché la sua configurazione non elenca l'interfaccia VPN.

Provate una richiesta unicast diretta, poi una richiesta annunciata. Se la prima funziona e la seconda no, il tunnel è sano e il rilevamento è tutto il problema.