Smart TV sulla VPN: perché casting e DNS si rompono separatamente

Il tuo televisore mostra il catalogo estero, e il pulsante di casting del telefono non lo elenca più. Entrambe le lamentele iniziano con una frase che nomina quattro impostazioni su quattro pagine del router. Ripara l'uscita e la scoperta si rompe; ripara la scoperta e il lease successivo affida l'uscita a un altro dispositivo. L'ordine seguente va dal selettore al percorso di casting.

Dove vive ciascuna delle quattro decisioni

Scrivi le quattro prima di aprire un menu, perché ciascuna vive su una pagina diversa e fallisce in un punto diverso. Il selettore sceglie a quale client si applica il tunnel, il resolver decide dove vengono risolti i nomi, la famiglia di indirizzi decide se IPv6 è coperto del tutto, e il percorso locale decide se il telefono e il televisore si vedono ancora. Una modifica a una sembra completa dalla pagina in cui ti trovi. Il danno delle altre tre compare più tardi, in un altro menu, come un'altra lamentela.

I menu del firmware differiscono, ma le quattro posizioni raramente. Il selettore è una mappatura statica sul server DHCP più una regola del firewall che vi corrisponde. Il resolver siede con il servizio DNS, dove una voce di forwarder o un elenco di server upstream decide quali nomi il router risolve e da dove partono le query. L'impostazione della famiglia appartiene all'interfaccia stessa, dove IPv4 e IPv6 si configurano separatamente e una policy può coprire solo la prima. Il percorso locale è uno switch del punto di accesso, o l'isolamento dei client o una rete ospiti con il proprio firewall.

Fai durare il selettore più del lease

Funzionano sia una policy per dispositivo sia un segmento dedicato, e la scelta migliore è quella che il firmware può mantenere senza che una seconda persona la ricordi. La trappola è una regola fissata a un indirizzo che il server DHCP ha assegnato secondo il proprio calendario: funziona finché il lease si sposta, poi instrada un portatile attraverso un altro paese per ragioni che il proprietario non può vedere. La persistenza, non l'ordine, è la proprietà che vale la pena ottimizzare.

Invia la prenotazione e la regola come un'unica modifica, perché una regola che sopravvive alla sua prenotazione è una regola puntata sull'hardware di qualcun altro. Una regola di segmento intero è il selettore più duraturo e il più grossolano, dato che ogni dispositivo dietro quell'interfaccia eredita l'uscita, che ne avesse bisogno o no. Qualunque selettore scegli, la domanda della copertura viene dopo: una policy solo IPv4 è mezza decisione, e la famiglia non coperta è quella che se ne va senza che nessuno lo noti.

Scopri quale resolver usa davvero il televisore

Apri le impostazioni di rete del televisore stesso prima di toccare il router, perché il dispositivo risolve questa discussione. Un campo DNS impostato manualmente continua a usare quel server qualunque cosa offra il DHCP, e un set-top box configurato una volta per un'altra regione può ancora puntare a un indirizzo che non risponde più. Se il campo è automatico, decide l'opzione DHCP del router, e il resolver del router diventa la domanda successiva. In ogni caso la risposta è sullo schermo del dispositivo, non nel manuale del firmware.

Lato router, la distinzione che conta è tra nomi a cui il router risponde da sé e nomi che inoltra, perché quei due percorsi possono uscire da interfacce diverse. Quindi una risoluzione che funziona non dice nulla su dove vada una richiesta media, e su un gateway Linux la tabella delle policy più una sola ricerca di rotta rispondono a entrambe le domande senza catturare nulla sul televisore:

ip rule show
ip route get 203.0.113.10

Leggi il primo comando per la regola che marca il traffico del televisore e il secondo per l'interfaccia che un pacchetto verso l'indirizzo di esempio userebbe davvero. Quando i due non concordano, il resolver non è la causa; lo è la policy. Cambia una cosa, poi esegui di nuovo la coppia, perché un elenco di regole è sensibile all'ordine e una nuova voce può oscurare la regola che portava il traffico. La destinazione è riservata alla documentazione, quindi un output incollato si legge come un esempio.

Il casting si rompe alla scoperta, non allo stream

Il casting è almeno tre conversazioni e solo una porta video. Il telefono scopre il televisore via multicast o broadcast sul segmento locale, apre un canale di controllo per dire cosa riprodurre, e poi il televisore o scarica lo stream da sé o lo riceve ritrasmesso dal telefono. La scoperta non attraversa mai un router che non inoltra quel traffico, ed è così che un televisore può essere instradato esattamente come previsto e comunque non comparire mai nell'elenco di casting.

Le reti ospiti e l'isolamento dei client sono la causa abituale, e entrambi fanno esattamente ciò per cui sono stati configurati. Disattivare l'isolamento su tutta la rete wireless perché un dispositivo ricompaia è la solita sovracorrezione, e riapre ogni percorso telefono-a-telefono che l'impostazione esisteva per chiudere. Esistono risposte più strette: una regola di passaggio per il traffico di scoperta e controllo tra due indirizzi, un SSID separato per i televisori, o un'eccezione documentata sulla rete ospiti.

Prova il casting con la regola di isolamento ancora al suo posto, poi aggiungi solo l'eccezione di scoperta e prova di nuovo. Se il secondo tentativo trova il televisore, l'eccezione è la soluzione e il resto del segmento può restare com'era.

Ferma il tunnel e guarda da che parte fallisce

L'ultimo controllo è quello che la maggior parte delle installazioni salta: abbassa il tunnel e guarda se il televisore si ferma o se ne va silenziosamente dalla connessione locale. Una policy che esprime una preferenza fallisce aperta, e quel guasto è facile da mancare perché la riproduzione continua mentre l'uscita torna all'ISP. Una regola di kill-switch fallisce chiusa invece, e il televisore non segnala nulla finché il tunnel non ritorna. Nessuno dei due comportamenti è sbagliato; non sapere quale hai configurato lo è.

Ricontrolla quattro cose dopo ogni modifica, in questo ordine. Il selettore corrisponde ancora al dispositivo dopo il lease o il riavvio successivo. Il resolver risponde sul percorso che la policy intende, non da un server che il dispositivo ricordava. La famiglia di indirizzi nella policy copre ogni famiglia che il televisore e la rete di accesso usano davvero. Il casting trova ancora il televisore dal telefono che sarà realmente usato, non da un telefono di prova sullo stesso SSID.

Tieni quelle quattro righe accanto alla configurazione del router invece che in un thread di chat: cosa abbina la regola, quale resolver interroga il televisore, quale famiglia è coperta e quale percorso locale serve al casting. La prossima persona che aprirà il firewall leggerà la configurazione molto prima di leggere un ticket. A quel punto, quella persona potresti essere tu.