Por qué el casting deja de funcionar al activar la VPN del router
El descubrimiento viaja por multicast local mientras el televisor descarga los medios por su cuenta. Una política predeterminada puede capturar la petición de la LAN y enviarla al túnel.
El casting funcionaba antes de activar la VPN del router y falla justo después, mientras la navegación normal en el teléfono sigue funcionando. Los dos hechos son compatibles, porque el casting no es una sola conexión. El teléfono descubre y controla el receptor por la red local, y luego el receptor descarga los medios por su propia conexión.
Dos caminos que fallan de forma distinta
El camino de control es local. Un teléfono encuentra un receptor preguntando a la red local y luego abre una conexión de control a la dirección que ha aprendido. Si el receptor nunca aparece en la lista, el paso de descubrimiento falló antes de solicitar ningún medio.
El camino de los medios no es necesariamente local. Muchos receptores descargan el flujo ellos mismos, por su propia conexión y con sus propias credenciales, así que la ruta del teléfono no describe la ruta del receptor. Un teléfono que parece usar una salida no dice nada sobre adónde va el tráfico del televisor.
Esa separación es la razón de que el fallo parezca extraño. El túnel cambió la tabla de rutas del teléfono y no la del televisor, así que un síntoma que aparece en un lado de la pareja debe rastrearse en ese lado. Rastrear el dispositivo equivocado es la causa habitual de que una solución parezca no hacer nada.
Por qué el descubrimiento falla primero
El descubrimiento suele viajar por multicast de enlace local. mDNS envía a 224.0.0.251 en el puerto UDP 5353, y SSDP envía a 239.255.255.250 en el puerto UDP 1900. Ambos están limitados a un enlace por diseño, y por eso un router no los reenvía entre segmentos sin ayuda de un repetidor o un proxy. Una VPN enrutada no extiende un grupo multicast, y una ruta de política no puede hacer que un grupo que nunca salió del enlace aparezca en otro.
Así que el primer fallo no tiene nada que ver con el cifrado. El multicast del teléfono sale de la interfaz por la que se envió, el receptor está en un segmento que nunca lo ve, y la lista de dispositivos vuelve vacía. Una lista vacía no es prueba de que el televisor haya perdido el acceso a internet.
El aislamiento produce un síntoma idéntico sin ninguna VPN. Las redes de invitados y el aislamiento de clientes en los puntos de acceso impiden deliberadamente que los dispositivos hablen entre sí, y activar una VPN de router sobre un segmento aislado no cambia nada de eso. Comprueba el ajuste de aislamiento antes de comprobar el túnel. Es la respuesta más barata y la más frecuente.
La disposición de los segmentos es la otra mitad. Un segundo router, un nodo mesh en otro modo o un segmento cableado detrás de otro NAT sitúan al receptor donde el tráfico de descubrimiento del teléfono no llega.
Por qué una política predeterminada puede tragarse una petición local
Un router que enruta todo el tráfico hacia un túnel instala una ruta predeterminada en la interfaz del túnel. Si el prefijo de la LAN no queda excluido de esa política, un paquete dirigido a un dispositivo a dos metros ahora coincide con la predeterminada, y el router envía la petición de control al túnel en lugar de al conmutador.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
El orden de las reglas decide el resultado. El enrutamiento por política evalúa las reglas por orden de prioridad, así que una excepción para el prefijo local debe aparecer antes de la regla que selecciona la tabla del túnel. Añadir la excepción después de la regla del túnel no tiene efecto, y por eso una configuración que parece correcta puede seguir enviando tráfico de la LAN a una salida remota.
La reparación es estrecha: permite los destinos locales concretos que necesita el flujo de casting y deja el resto del aislamiento en paz. Quitar el aislamiento de clientes como primer paso arregla el síntoma, pero descarta un control que la red estaba diseñada para tener.
Una consulta rápida en el teléfono aclara cuál de los dos fallos tienes. Si la ruta hacia el receptor apunta al túnel, el problema es la política. Si apunta a la LAN y el descubrimiento sigue fallando, el problema es el multicast o el aislamiento, y ningún cambio de ruta ayudará.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpPrueba el paso que cambió, no el país
Las observaciones registradas valen más que los experimentos repetidos. Anota si el receptor aparece en la lista de dispositivos, si le llega una petición de control y si la reproducción empieza al elegir un flujo. Cada respuesta quita un paso de la sospecha.
Después prueba cada paso directamente en lugar de cambiar de salida. Cambiar de país de VPN prueba el camino de los medios y deja intactos los pasos de descubrimiento y control, así que puede parecer que ayuda por casualidad sin enseñarte nada.
En el lado del receptor, comprueba su propia ruta y el estado de su cuenta. Un televisor que descarga medios por una salida distinta a la del teléfono es un diseño normal, y un fallo ahí es una cuestión sobre la política de red del receptor, no sobre el túnel del teléfono.
Escribe el resultado como una sola frase sobre qué paso se rompió y qué lo cambió. Esa frase vale más que una semana de cambiar de país, y sobrevive a la próxima actualización de firmware.
El casting es un buen caso de prueba para una regla general sobre túneles. Cuando se añade uno a una red, la primera pregunta es qué destinos nunca deberían haber entrado en él. La segunda es cuáles de ellos aceptó la política en silencio de todos modos.