Perché il casting smette di funzionare dopo aver attivato la VPN del router

Il casting funzionava prima di attivare la VPN del router e fallisce subito dopo, mentre la normale navigazione sul telefono continua a funzionare. I due fatti sono coerenti, perché il casting non è un’unica connessione. Il telefono scopre e controlla il ricevitore sulla rete locale, poi il ricevitore scarica i media tramite la propria connessione.

Due percorsi che falliscono in modo diverso

Il percorso di controllo è locale. Un telefono trova un ricevitore interrogando la rete locale e poi apre una connessione di controllo verso l’indirizzo che ha appreso. Se il ricevitore non compare mai nell’elenco, il passo di rilevamento è fallito prima che fosse richiesto qualsiasi media.

Il percorso dei media non è necessariamente locale. Molti ricevitori scaricano lo stream da soli, tramite la propria connessione e con le proprie credenziali, quindi la rotta del telefono non descrive la rotta del ricevitore. Un telefono che sembra usare una sola uscita non dice nulla su dove vada il traffico del televisore.

È questa separazione a rendere il guasto strano. Il tunnel ha cambiato la tabella di routing del telefono e non quella del televisore, quindi un sintomo che appare su un lato della coppia va tracciato su quel lato. Tracciare il dispositivo sbagliato è la ragione abituale per cui una correzione sembra non fare nulla.

Perché il rilevamento fallisce per primo

Il rilevamento viaggia di solito su multicast di collegamento locale. mDNS invia a 224.0.0.251 sulla porta UDP 5353, e SSDP invia a 239.255.255.250 sulla porta UDP 1900. Entrambi sono limitati a un collegamento per progetto, ed è per questo che un router non li inoltra tra segmenti senza l’aiuto di un ripetitore o di un proxy. Una VPN instradata non estende un gruppo multicast, e una rotta di policy non può far comparire su un altro collegamento un gruppo che non ha mai lasciato il suo.

Quindi il primo guasto non ha nulla a che vedere con la cifratura. Il multicast del telefono lascia l’interfaccia su cui è stato inviato, il ricevitore si trova su un segmento che non lo vede mai, e l’elenco dei dispositivi torna vuoto. Un elenco vuoto non è la prova che il televisore abbia perso l’accesso a internet.

L’isolamento produce un sintomo identico senza alcuna VPN. Le reti ospiti e l’isolamento dei client sugli access point impediscono di proposito ai dispositivi di parlarsi, e attivare una VPN del router sopra un segmento isolato non cambia nulla in proposito. Controllate l’impostazione di isolamento prima di controllare il tunnel. È la risposta più economica e la più frequente.

La disposizione dei segmenti è l’altra metà. Un secondo router, un nodo mesh in un’altra modalità o un segmento cablato dietro un altro NAT collocano il ricevitore dove il traffico di rilevamento del telefono non arriva.

Perché una policy predefinita può inghiottire una richiesta locale

Un router che instrada tutto il traffico in un tunnel installa una rotta predefinita sull’interfaccia del tunnel. Se il prefisso della LAN non è escluso da quella policy, un pacchetto indirizzato a un dispositivo a due metri ora corrisponde alla rotta predefinita, e il router manda la richiesta di controllo nel tunnel invece che allo switch.

L’ordine delle regole decide il risultato. Il routing basato su policy valuta le regole in ordine di priorità, quindi un’eccezione per il prefisso locale deve comparire prima della regola che seleziona la tabella del tunnel. Aggiungere l’eccezione dopo la regola del tunnel non ha alcun effetto, ed è per questo che una configurazione che sembra corretta può comunque mandare il traffico della LAN verso un’uscita remota.

La correzione è stretta: consentite le destinazioni locali precise di cui ha bisogno il flusso di casting e lasciate in pace il resto dell’isolamento. Rimuovere l’isolamento dei client come primo passo sistema il sintomo ma scarta un controllo che la rete era progettata per avere.

Un controllo rapido sul telefono chiarisce quale dei due guasti avete. Se la rotta verso il ricevitore punta al tunnel, il problema è la policy. Se punta alla LAN e il rilevamento continua a fallire, il problema è il multicast o l’isolamento, e nessun cambio di rotta aiuterà.

ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcp

Testate il passo che è cambiato, non il paese

Le osservazioni registrate valgono più degli esperimenti ripetuti. Annotate se il ricevitore compare nell’elenco dei dispositivi, se una richiesta di controllo lo raggiunge e se la riproduzione parte una volta scelto uno stream. Ogni risposta toglie un passo dai sospetti.

Poi testate ogni passo direttamente invece di cambiare uscita. Cambiare paese della VPN mette alla prova il percorso dei media e lascia intatti i passi di rilevamento e controllo, quindi può sembrare di aiutare per caso senza insegnarvi nulla.

Dal lato del ricevitore, controllate la sua rotta e lo stato del suo account. Un televisore che scarica i media attraverso un’uscita diversa da quella del telefono è un progetto normale, e un guasto lì è una questione di policy di rete del ricevitore, non del tunnel del telefono.

Scrivete il risultato come una sola frase su quale passo si è rotto e che cosa l’ha cambiato. Quella frase vale più di una settimana di cambi di paese, e sopravvive al prossimo aggiornamento del firmware.

Il casting è un buon caso di prova per una regola generale sui tunnel. Quando se ne aggiunge uno a una rete, la prima domanda è quali destinazioni non avrebbero mai dovuto entrarci. La seconda è quali di queste la policy ha comunque accettato in silenzio.