La emisión se detiene con VPN: ¿descubrimiento, control o flujo?
Un receptor ausente, una sesión rechazada y un flujo que se atasca fallan en lugares distintos. Nombra la etapa antes de cambiar la política de VPN del teléfono o la red.
La emisión se rompe en tres lugares que desde el sofá parecen idénticos. Puede que el teléfono nunca vea el receptor, que el receptor aparezca y luego rechace la sesión, o que la sesión empiece y se atasque un minuto después. Un túnel en el teléfono cambia cada uno de esos caminos de forma distinta, y en uno de ellos no cambia nada en absoluto. Nombra primero la etapa que falla y luego decide si cambiar la política es siquiera la palanca correcta.
Nombra la etapa que falla antes de cambiar la política
Observa qué hace el teléfono justo después de tocar el icono de emisión. Una lista vacía es un resultado de descubrimiento, un toque que informa de un fallo es un resultado de control, y una sesión que empieza antes de atascarse es un resultado de reproducción. Esos tres tienen dueños distintos, y normalmente solo los dos primeros implican la configuración del túnel del teléfono.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Anota la etapa antes de cambiar nada. Una corrección aplicada a la etapa equivocada hace ilegible la siguiente prueba, y la mayor parte de la leyenda sobre la emisión nace exactamente de esa confusión.
El descubrimiento es tráfico local, y un túnel lo esconde
Los receptores se anuncian mediante anuncios locales y el teléfono los encuentra con consultas en el mismo enlace, así que cualquier cosa que saque el teléfono de ese enlace saca el receptor de la lista. Un túnel que encamina todo el tráfico fuera de la LAN puede ocultar esos intercambios, y un permiso de red local a nivel de aplicación puede bloquearlos incluso cuando la ruta existe. Un Wi-Fi de invitados con aislamiento de clientes produce la misma lista vacía sin ningún VPN. Demuestra que los dos dispositivos comparten segmento antes de culpar al túnel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTREl primer comando enumera lo que se anuncia en el segmento de la máquina auxiliar, y el segundo pregunta directamente al grupo de DNS multicast. Un receptor ausente en ambos tampoco aparecerá en una aplicación del teléfono, sea cual sea el estado del túnel. Si el receptor es visible desde un dispositivo con el túnel apagado e invisible desde uno con el túnel encendido, has encontrado la etapa y la causa a la vez.
Una excepción de LAN mantiene el túnel activo
Muchos clientes ofrecen una excepción de red local que deja el túnel activo mientras permite direcciones locales. Usa esa opción documentada en lugar de desactivar el kill switch o todo el cortafuegos, porque esos cambian mucho más de lo que la emisión necesita. Si la red separa los dispositivos inteligentes a propósito, pide al propietario el tráfico concreto de descubrimiento, control y retorno en lugar de un acceso plano.
nc -vz 192.168.1.50 8009Una prueba de control contra el receptor separa el permiso de la accesibilidad: un puerto que responde significa que la ruta existe, mientras que un rechazo significa que se permitió al teléfono descubrir el dispositivo y aun así no puede hablar con él. Los puertos 8008 y 8009 son los puertos habituales de emisión, y una aplicación puede usar otros, así que trata un solo puerto rechazado como una pista y no como un veredicto. La excepción y el permiso de la aplicación siguen siendo independientes, porque conceder acceso local no crea una ruta y añadir una ruta no concede permiso. Un kill switch también puede tirar el tráfico local tras una reconexión, y por eso el descubrimiento debe volver a probarse cuando el túnel regresa.
La reproducción puede no usar la conexión del teléfono
En una sesión dirigida por la aplicación, el teléfono entrega al receptor una dirección de medios y el receptor la descarga por su propia conexión, así que cambiar la dirección pública del teléfono no hace nada por el flujo. Un título restringido por cuenta puede fallar igualmente por sus propios motivos, y los requisitos de emisión de Google cubren la compatibilidad de aplicación y dispositivo, no la ruta de red. Encaminar el televisor por un túnel es una configuración aparte con sus propias cuestiones de política.
Dos pistas distinguen los modos. Una emisión que sobrevive al bloqueo de la pantalla del teléfono está dirigida por la aplicación, porque el receptor descarga por su cuenta; una réplica que se detiene cuando se bloquea la pantalla del emisor es un flujo continuo desde el teléfono. Cuando el descubrimiento y el control funcionan pero la reproducción se atasca, mira en cambio el enlace Wi-Fi del receptor y su ruta a internet, porque una prueba de velocidad en el teléfono describe el teléfono y no el televisor.
Deshaz la excepción y vuelve a probar
Todo cambio temporal necesita un camino de vuelta, y el orden importa. Quita la excepción de LAN, vuelve a conectar el túnel para que el cliente reaplique su política, luego repite el paso de descubrimiento y anota si el receptor vuelve a desaparecer. Esa secuencia te dice si la excepción hacía el trabajo o si algo más cambió entre medias.
# 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 después las tres etapas por separado, porque aprobar una no dice nada de las otras. Luego comprueba que las aplicaciones del teléfono no relacionadas siguen la ruta prevista, porque una excepción local que se convirtió en silencio en un bypass completo es un resultado peor que una emisión que necesita un toque extra.