La trasmissione si ferma con la VPN: scoperta, controllo o flusso?

La trasmissione si rompe in tre punti che dal divano sembrano identici. Il telefono può non vedere mai il ricevitore, il ricevitore può comparire e poi rifiutare la sessione, oppure la sessione può partire e bloccarsi un minuto dopo. Un tunnel sul telefono cambia ciascuno di quei percorsi in modo diverso, e per uno di essi non cambia proprio nulla. Nomina prima la fase che fallisce, poi decidi se cambiare la politica sia davvero la leva giusta.

Nomina la fase che fallisce prima di cambiare la politica

Osserva cosa fa il telefono subito dopo aver toccato l'icona della trasmissione. Un elenco vuoto è un risultato di scoperta, un tocco che segnala un errore è un risultato di controllo, e una sessione che parte prima di bloccarsi è un risultato di riproduzione. Questi tre hanno proprietari diversi, e di solito solo i primi due riguardano le impostazioni del tunnel del telefono.

Annota la fase prima di cambiare qualsiasi cosa. Una correzione applicata alla fase sbagliata rende illeggibile il test successivo, e la maggior parte delle leggende sulla trasmissione nasce proprio da questa confusione.

La scoperta è traffico locale, e un tunnel la nasconde

I ricevitori si annunciano con annunci locali e il telefono li trova con query sullo stesso collegamento, quindi qualsiasi cosa tolga il telefono da quel collegamento toglie il ricevitore dall'elenco. Un tunnel che instrada tutto il traffico fuori dalla LAN può nascondere questi scambi, e un permesso di rete locale a livello di applicazione può bloccarli anche quando la rotta esiste. Un Wi-Fi per ospiti con isolamento dei client produce lo stesso elenco vuoto senza alcuna VPN. Dimostra che i due dispositivi condividono un segmento prima di dare la colpa al tunnel.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

Il primo comando elenca ciò che si annuncia nel segmento della macchina ausiliaria, e il secondo interroga direttamente il gruppo DNS multicast. Un ricevitore assente da entrambi non comparirà nemmeno in un'app del telefono, qualunque sia lo stato del tunnel. Se il ricevitore è visibile da un dispositivo con il tunnel spento e invisibile da uno con il tunnel acceso, hai trovato insieme la fase e la causa.

Un'eccezione LAN tiene attivo il tunnel

Molti client offrono un'eccezione di rete locale che lascia attivo il tunnel consentendo gli indirizzi locali. Usa quell'impostazione documentata invece di disattivare il kill switch o l'intero firewall, perché quelli cambiano molto più di quanto serva alla trasmissione. Se la rete separa di proposito i dispositivi intelligenti, chiedi al proprietario il traffico specifico di scoperta, controllo e ritorno invece di un accesso piatto.

nc -vz 192.168.1.50 8009

Un test di controllo verso il ricevitore separa il permesso dalla raggiungibilità: una porta che risponde significa che il percorso esiste, mentre un rifiuto significa che al telefono è stato permesso di scoprire il dispositivo e comunque non riesce a parlargli. Le porte 8008 e 8009 sono le porte di trasmissione abituali, e un'app può usarne altre, quindi tratta una sola porta rifiutata come un indizio e non come un verdetto. L'eccezione e il permesso dell'app restano indipendenti, perché concedere l'accesso locale non crea una rotta e aggiungere una rotta non concede il permesso. Un kill switch può anche far cadere il traffico locale dopo una riconnessione, ed è per questo che la scoperta va ritestata appena il tunnel torna.

La riproduzione potrebbe non usare la connessione del telefono

In una sessione guidata dall'app, il telefono consegna al ricevitore un indirizzo multimediale e il ricevitore lo scarica tramite la propria connessione, quindi cambiare l'indirizzo pubblico del telefono non fa nulla per il flusso. Un titolo vincolato all'account può comunque fallire per motivi propri, e i requisiti di trasmissione di Google coprono la compatibilità di app e dispositivo, non il percorso di rete. Instradare il televisore stesso attraverso un tunnel è una configurazione separata, con le sue domande di politica.

Due indizi distinguono le modalità. Una trasmissione che sopravvive al blocco dello schermo del telefono è guidata dall'app, perché il ricevitore scarica da solo; una replica che si ferma quando si blocca lo schermo del mittente è un flusso continuo dal telefono. Quando scoperta e controllo riescono ma la riproduzione si blocca, guarda invece il collegamento Wi-Fi del ricevitore e il suo percorso internet, perché un test di velocità sul telefono descrive il telefono e non il televisore.

Annulla l'eccezione e ritesta

Ogni modifica temporanea ha bisogno di una via di ritorno, e l'ordine conta. Rimuovi l'eccezione LAN, riconnetti il tunnel perché il client riapplichi la sua politica, poi ripeti il passo di scoperta e annota se il ricevitore scompare di nuovo. Quella sequenza ti dice se era l'eccezione a fare il lavoro o se qualcos'altro è cambiato nel frattempo.

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

Verifica poi le tre fasi separatamente, perché superarne una non dice nulla sulle altre. Poi controlla che le app del telefono non correlate seguano ancora il percorso previsto, perché un'eccezione locale diventata silenziosamente un bypass completo è un esito peggiore di una trasmissione che richiede un tocco in più.