Smart TV na VPN: por que o casting e o DNS fallan por separado

O teu televisor amosa o catálogo estranxeiro, e o botón de casting do teléfono xa non o lista. As dúas queixas comezan cunha frase que nomea catro axustes en catro páxinas do router. Arranxa a saída e a descuberta rompe; arranxa a descuberta e o seguinte arrendamento entrega a saída a outro dispositivo. A orde seguinte vai do selector á ruta de casting.

Onde vive cada unha das catro decisións

Anota as catro antes de abrir un menú, porque cada unha vive nunha páxina distinta e falla nun sitio distinto. O selector elixe a que cliente se aplica o túnel, o resolutor decide onde se responden os nomes, a familia de enderezos decide se IPv6 queda cuberto ou non, e a ruta local decide se o teléfono e o televisor aínda se ven. Un cambio nunha parece completo desde a páxina na que estás. O dano das outras tres aparece máis tarde, noutro menú, como outra queixa.

Os menús do firmware varían, pero as catro localizacións raramente. O selector é unha asignación estática no servidor DHCP máis unha regra de devasamento que coincide con ela. O resolutor está xunto ao servizo DNS, onde unha entrada de reenviador ou unha lista de servidores ascendentes decide que nomes responde o router e de onde saen as consultas. O axuste de familia pertence á propia interface, onde IPv4 e IPv6 se configuran por separado e unha política só pode cubrir a primeira. A ruta local é un conmutador do punto de acceso, xa sexa illamento de clientes ou unha rede de convidados co seu propio devasamento.

Fai que o selector sobreviva ao arrendamento

Tanto unha política por dispositivo como un segmento dedicado funcionan, e a mellor elección é a que o firmware pode manter sen que unha segunda persoa a lembre. A trampa é unha regra fixada a un enderezo que o servidor DHCP entregou segundo o seu propio calendario: segue funcionando ata que o arrendamento se move, e entón encamiña un portátil por outro país por razóns que o seu dono non pode ver. A persistencia, non a orde, é a propiedade que paga a pena optimizar.

Envía a reserva e a regra como un só cambio, porque unha regra que sobrevive á súa reserva é unha regra dirixida ao hardware doutra persoa. Unha regra de segmento enteiro é o selector máis duradeiro e o máis contundente, xa que cada dispositivo detrás desa interface herda a saída, necesitásea ou non. Elixas o selector que elixas, a pregunta da cobertura vén despois: unha política só IPv4 é media decisión, e a familia non cuberta é a que se marcha sen que ninguén o note.

Averigua que resolutor usa realmente o televisor

Abre os axustes de rede do propio televisor antes de tocar o router, porque o dispositivo resolve esta discusión. Un campo DNS posto en manual segue usando ese servidor ofreza o que ofreza o DHCP, e un receptor configurado unha vez para outra rexión aínda pode apuntar a un enderezo que xa non responde. Se o campo é automático, decide a opción DHCP do router, e o resolutor propio do router pasa a ser a seguinte pregunta. En calquera caso a resposta está na pantalla do dispositivo, non no manual do firmware.

Do lado do router, a distinción que importa é entre nomes que o router responde el mesmo e nomes que reenvía, porque esas dúas rutas poden saír por interfaces distintas. Por iso unha consulta que se resolve ben non di nada sobre onde vai unha petición de medios, e nunha pasarela Linux a táboa de políticas máis unha soa consulta de ruta responden ambas as preguntas sen capturar nada no televisor:

ip rule show
ip route get 203.0.113.10

Le o primeiro comando para a regra que marca o tráfico do televisor e o segundo para a interface que usaría realmente un paquete ao enderezo de exemplo. Cando os dous non coinciden, o resolutor non ten a culpa; a política si. Cambia unha cousa, e despois executa o par outra vez, porque unha lista de regras é sensible á orde e unha entrada nova pode facer sombra á regra que levaba o tráfico. O destino está reservado para documentación, así que unha saída pegada lese como unha mostra.

O casting rompe na descuberta, non no fluxo

O casting son polo menos tres conversas e só unha delas leva vídeo. O teléfono descobre o televisor por multicast ou broadcast no segmento local, abre unha canle de control para dicir que reproducir, e despois o televisor ou ben descarga o fluxo el mesmo ou recíbeo retransmitido desde o teléfono. A descuberta nunca cruza un router que non reenvía ese tráfico, e así é como un televisor pode ir encamiñado exactamente como se pretendía e aínda así non aparecer nunca na lista de casting.

As redes de convidados e o illamento de clientes son a causa habitual, e ambos fan exactamente aquilo para o que se configuraron. Desactivar o illamento en toda a rede sen fíos para que un dispositivo reapareza é a sobrecorrección habitual, e reabre cada ruta teléfono-a-teléfono que o axuste existía para pechar. Hai respostas máis estreitas: unha regra de paso para o tráfico de descuberta e control entre dous enderezos, un SSID aparte para os televisores, ou unha excepción documentada na rede de convidados.

Proba o casting coa regra de illamento aínda no seu sitio, e despois engade só a excepción de descuberta e proba de novo. Se o segundo intento atopa o televisor, a excepción é a solución e o resto do segmento pode quedar como estaba.

Detén o túnel e observa cara a onde falla

A última comprobación é a que a maioría das instalacións se salta: baixa o túnel e observa se o televisor se detén ou se marcha en silencio pola conexión local. Unha política que expresa unha preferencia falla aberta, e ese fallo é fácil de pasar por alto porque a reprodución continúa mentres a saída volve ao ISP. Unha regra de kill-switch falla pechada, en cambio, e o televisor non informa de nada ata que o túnel regresa. Ningún dos dous comportamentos é incorrecto; non saber cal configurou si o é.

Volve comprobar catro cousas tras calquera cambio, nesta orde. O selector segue coincidindo co dispositivo tras o seguinte arrendamento ou reinicio. O resolutor responde pola ruta que a política pretende, non desde un servidor que o dispositivo lembraba. A familia de enderezos da política cobre cada familia que o televisor e a rede de acceso usan realmente. O casting segue atopando o televisor desde o teléfono que de verdade se usará, non desde un teléfono de proba no mesmo SSID.

Mantén esas catro liñas xunto á configuración do router e non nun fío de chat: que coincide a regra, que resolutor pregunta o televisor, que familia queda cuberta e que ruta local necesita o casting. A seguinte persoa que abra o devasamento lerá a configuración moito antes de ler un tícket. Para entón, esa persoa podes ser ti.