Smart TV en la VPN: por qué el casting y el DNS fallan por separado

Tu televisor muestra el catálogo extranjero, y el botón de casting del teléfono ya no lo lista. Ambas quejas empiezan con una frase que nombra cuatro ajustes en cuatro páginas del router. Arregla la salida y la detección se rompe; arregla la detección y el siguiente arrendamiento entrega la salida a otro dispositivo. El orden siguiente va del selector a la ruta de casting.

Dónde vive cada una de las cuatro decisiones

Anota las cuatro antes de abrir un menú, porque cada una vive en una página distinta y falla en un sitio distinto. El selector elige a qué cliente se aplica el túnel, el resolutor decide dónde se responden los nombres, la familia de direcciones decide si IPv6 queda cubierto o no, y la ruta local decide si el teléfono y el televisor todavía se ven. Un cambio en una parece completo desde la página en la que estás. El daño de las otras tres aparece más tarde, en otro menú, como otra queja.

Los menús del firmware varían, pero las cuatro ubicaciones rara vez. El selector es un mapeo estático en el servidor DHCP más una regla de cortafuegos que coincide con él. El resolutor está junto al servicio DNS, donde una entrada de reenviador o una lista de servidores ascendentes decide qué nombres responde el router y de dónde salen las consultas. El ajuste de familia pertenece a la propia interfaz, donde IPv4 e IPv6 se configuran por separado y una política solo puede cubrir la primera. La ruta local es un conmutador del punto de acceso, ya sea aislamiento de clientes o una red de invitados con su propio cortafuegos.

Haz que el selector sobreviva al arrendamiento

Tanto una política por dispositivo como un segmento dedicado funcionan, y la mejor elección es la que el firmware puede mantener sin que una segunda persona la recuerde. La trampa es una regla fijada a una dirección que el servidor DHCP entregó según su propio calendario: sigue funcionando hasta que el arrendamiento se mueve, y entonces encamina un portátil por otro país por razones que su dueño no puede ver. La persistencia, no el orden, es la propiedad que vale la pena optimizar.

Envía la reserva y la regla como un solo cambio, porque una regla que sobrevive a su reserva es una regla dirigida al hardware de otra persona. Una regla de segmento entero es el selector más duradero y el más contundente, ya que cada dispositivo detrás de esa interfaz hereda la salida, la necesitara o no. Elijas el selector que elijas, la pregunta de cobertura viene después: una política solo IPv4 es media decisión, y la familia no cubierta es la que se marcha sin que nadie lo note.

Averigua qué resolutor usa realmente el televisor

Abre los ajustes de red del propio televisor antes de tocar el router, porque el dispositivo zanja esta discusión. Un campo DNS puesto en manual sigue usando ese servidor ofrezca lo que ofrezca el DHCP, y un receptor configurado una vez para otra región todavía puede apuntar a una dirección que ya no responde. Si el campo es automático, decide la opción DHCP del router, y el resolutor propio del router pasa a ser la siguiente pregunta. En cualquier caso la respuesta está en la pantalla del dispositivo, no en el manual del firmware.

Del lado del router, la distinción que importa es entre nombres que el router responde él mismo y nombres que reenvía, porque esas dos rutas pueden salir por interfaces distintas. Por eso una consulta que se resuelve bien no dice nada sobre adónde va una petición de medios, y en una puerta de enlace Linux la tabla de políticas más una sola consulta de ruta responden ambas preguntas sin capturar nada en el televisor:

ip rule show
ip route get 203.0.113.10

Lee el primer comando para la regla que marca el tráfico del televisor y el segundo para la interfaz que usaría realmente un paquete a la dirección de ejemplo. Cuando los dos no coinciden, el resolutor no tiene la culpa; la política sí. Cambia una cosa, y luego ejecuta el par otra vez, porque una lista de reglas es sensible al orden y una entrada nueva puede hacer sombra a la regla que llevaba el tráfico. El destino está reservado para documentación, así que una salida pegada se lee como una muestra.

El casting se rompe en la detección, no en el flujo

El casting son al menos tres conversaciones y solo una de ellas lleva vídeo. El teléfono descubre el televisor por multicast o broadcast en el segmento local, abre un canal de control para decir qué reproducir, y luego el televisor o bien descarga el flujo él mismo o lo recibe retransmitido desde el teléfono. La detección nunca cruza un router que no reenvía ese tráfico, y así es como un televisor puede ir encaminado exactamente como se pretendía y aun así no aparecer nunca en la lista de casting.

Las redes de invitados y el aislamiento de clientes son la causa habitual, y ambos hacen exactamente aquello para lo que se configuraron. Desactivar el aislamiento en toda la red inalámbrica para que un dispositivo reaparezca es la sobrecorrección habitual, y reabre cada ruta teléfono-a-teléfono que el ajuste existía para cerrar. Hay respuestas más estrechas: una regla de paso para el tráfico de detección y control entre dos direcciones, un SSID aparte para los televisores, o una excepción documentada en la red de invitados.

Prueba el casting con la regla de aislamiento todavía en su sitio, y luego añade solo la excepción de detección y prueba de nuevo. Si el segundo intento encuentra el televisor, la excepción es la solución y el resto del segmento puede quedarse como estaba.

Detén el túnel y observa hacia dónde falla

La última comprobación es la que la mayoría de las instalaciones se salta: baja el túnel y observa si el televisor se detiene o se marcha en silencio por la conexión local. Una política que expresa una preferencia falla abierta, y ese fallo es fácil de pasar por alto porque la reproducción continúa mientras la salida vuelve al ISP. Una regla de kill-switch falla cerrada, en cambio, y el televisor no informa de nada hasta que el túnel regresa. Ninguno de los dos comportamientos es incorrecto; no saber cuál has configurado sí lo es.

Vuelve a comprobar cuatro cosas tras cualquier cambio, en este orden. El selector sigue coincidiendo con el dispositivo tras el siguiente arrendamiento o reinicio. El resolutor responde por la ruta que la política pretende, no desde un servidor que el dispositivo recordaba. La familia de direcciones de la política cubre cada familia que el televisor y la red de acceso usan realmente. El casting sigue encontrando el televisor desde el teléfono que de verdad se usará, no desde un teléfono de prueba en el mismo SSID.

Mantén esas cuatro líneas junto a la configuración del router y no en un hilo de chat: qué coincide la regla, qué resolutor pregunta el televisor, qué familia queda cubierta y qué ruta local necesita el casting. La siguiente persona que abra el cortafuegos leerá la configuración mucho antes de leer un tique. Para entonces, esa persona puedes ser tú.