Por que o casting deixa de funcionar ao activar a VPN do router
O descubrimento viaxa por multicast local mentres o televisor descarga os medios por si mesmo. Unha política predeterminada pode capturar a petición da LAN e enviala ao túnel.
O casting funcionaba antes de activar a VPN do router e falla xusto despois, mentres a navegación normal no teléfono segue funcionando. Os dous feitos son compatibles, porque o casting non é unha soa conexión. O teléfono descobre e controla o receptor pola rede local, e despois o receptor descarga os medios pola súa propia conexión.
Dous camiños que fallan de forma distinta
O camiño de control é local. Un teléfono atopa un receptor preguntando á rede local e despois abre unha conexión de control á dirección que aprendeu. Se o receptor nunca aparece na lista, o paso de descubrimento fallou antes de solicitar ningún medio.
O camiño dos medios non é necesariamente local. Moitos receptores descargan o fluxo eles mesmos, pola súa propia conexión e coas súas propias credenciais, así que a ruta do teléfono non describe a ruta do receptor. Un teléfono que parece usar unha saída non di nada sobre onde vai o tráfico do televisor.
Esa separación é a razón de que o fallo pareza estraño. O túnel cambiou a táboa de rutas do teléfono e non a do televisor, así que un síntoma que aparece nun lado da parella debe rastrexarse nese lado. Rastrexar o dispositivo equivocado é a causa habitual de que unha solución pareza non facer nada.
Por que o descubrimento falla primeiro
O descubrimento adoita viaxar por multicast de enlace local. mDNS envía a 224.0.0.251 no porto UDP 5353, e SSDP envía a 239.255.255.250 no porto UDP 1900. Ambos están limitados a un enlace por deseño, e por iso un router non os reenvía entre segmentos sen axuda dun repetidor ou un proxy. Unha VPN encamiñada non estende un grupo multicast, e unha ruta de política non pode facer que un grupo que nunca saíu do enlace apareza noutro.
Así que o primeiro fallo non ten nada que ver co cifrado. O multicast do teléfono sae da interface pola que se enviou, o receptor está nun segmento que nunca o ve, e a lista de dispositivos volve baleira. Unha lista baleira non é proba de que o televisor perdese o acceso a internet.
O illamento produce un síntoma idéntico sen ningunha VPN. As redes de convidados e o illamento de clientes nos puntos de acceso impiden deliberadamente que os dispositivos falen entre si, e activar unha VPN de router sobre un segmento illado non cambia nada diso. Comproba o axuste de illamento antes de comprobar o túnel. É a resposta máis barata e a máis frecuente.
A disposición dos segmentos é a outra metade. Un segundo router, un nodo mesh noutro modo ou un segmento con cable detrás doutro NAT sitúan o receptor onde o tráfico de descubrimento do teléfono non chega.
Por que unha política predeterminada pode tragar unha petición local
Un router que encamiña todo o tráfico cara a un túnel instala unha ruta predeterminada na interface do túnel. Se o prefixo da LAN non queda excluído desa política, un paquete dirixido a un dispositivo a dous metros agora coincide coa predeterminada, e o router envía a petición de control ao túnel en lugar de ao 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 |
A orde das regras decide o resultado. O encamiñamento por política avalía as regras por orde de prioridade, así que unha excepción para o prefixo local debe aparecer antes da regra que selecciona a táboa do túnel. Engadir a excepción despois da regra do túnel non ten efecto, e por iso unha configuración que parece correcta pode seguir enviando tráfico da LAN a unha saída remota.
A reparación é estreita: permite os destinos locais concretos que necesita o fluxo de casting e deixa o resto do illamento en paz. Quitar o illamento de clientes como primeiro paso arranxa o síntoma, pero descarta un control que a rede estaba deseñada para ter.
Unha consulta rápida no teléfono aclara cal dos dous fallos tes. Se a ruta cara ao receptor apunta ao túnel, o problema é a política. Se apunta á LAN e o descubrimento segue fallando, o problema é o multicast ou o illamento, e ningún cambio de ruta axudará.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpProba o paso que cambiou, non o país
As observacións rexistradas valen máis que os experimentos repetidos. Anota se o receptor aparece na lista de dispositivos, se lle chega unha petición de control e se a reprodución comeza ao elixir un fluxo. Cada resposta quita un paso da sospeita.
Despois proba cada paso directamente en lugar de cambiar de saída. Cambiar de país de VPN proba o camiño dos medios e deixa intactos os pasos de descubrimento e control, así que pode parecer que axuda por casualidade sen ensinarte nada.
No lado do receptor, comproba a súa propia ruta e o estado da súa conta. Un televisor que descarga medios por unha saída distinta á do teléfono é un deseño normal, e un fallo alí é unha cuestión sobre a política de rede do receptor, non sobre o túnel do teléfono.
Escribe o resultado como unha soa frase sobre que paso se rompeu e que o cambiou. Esa frase vale máis que unha semana de cambiar de país, e sobrevive á próxima actualización de firmware.
O casting é un bo caso de proba para unha regra xeral sobre túneles. Cando se engade un a unha rede, a primeira pregunta é que destinos nunca deberían ter entrado nel. A segunda é cales deles aceptou a política en silencio de todos os xeitos.