A emisión detense cunha VPN: descuberta, control ou fluxo?
Un receptor ausente, unha sesión rexeitada e un fluxo que se atasca fallan en lugares distintos. Nomea a etapa antes de cambiar a política de VPN do teléfono ou a rede.
A emisión rompe en tres lugares que desde o sofá parecen idénticos. Pode que o teléfono nunca vexa o receptor, que o receptor apareza e logo rexeite a sesión, ou que a sesión comece e se atascase un minuto despois. Un túnel no teléfono cambia cada un deses camiños de forma distinta, e nun deles non cambia nada de nada. Nomea primeiro a etapa que falla e logo decide se cambiar a política é sequera a panca correcta.
Nomea a etapa que falla antes de cambiar a política
Observa que fai o teléfono xusto despois de tocar a icona de emisión. Unha lista baleira é un resultado de descuberta, un toque que informa dun fallo é un resultado de control, e unha sesión que comeza antes de atascarse é un resultado de reprodución. Eses tres teñen donos distintos, e normalmente só os dous primeiros afectan a configuración do túnel do 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 a etapa antes de cambiar nada. Unha corrección aplicada á etapa equivocada fai ilexible a seguinte proba, e a maior parte da lenda sobre a emisión vén exactamente desa confusión.
A descuberta é tráfico local, e un túnel escóndea
Os receptores anúncianse mediante anuncios locais e o teléfono atópaos con consultas na mesma ligazón, así que calquera cousa que quite o teléfono desa ligazón quita o receptor da lista. Un túnel que encamiña todo o tráfico fóra da LAN pode ocultar eses intercambios, e un permiso de rede local a nivel de aplicación pode bloquealos mesmo cando a ruta existe. Un Wi-Fi de invitados con illamento de clientes produce a mesma lista baleira sen ningún VPN. Demostra que os dous dispositivos comparten segmento antes de culpar o túnel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRO primeiro comando enumera o que se anuncia no segmento da máquina auxiliar, e o segundo pregunta directamente ao grupo de DNS multicast. Un receptor ausente en ambos tampouco aparecerá nunha aplicación do teléfono, calquera que sexa o estado do túnel. Se o receptor é visible desde un dispositivo co túnel apagado e invisible desde un co túnel acendido, atopaches a etapa e a causa á vez.
Unha excepción de LAN mantén o túnel activo
Moitos clientes ofrecen unha excepción de rede local que deixa o túnel activo mentres permite enderezos locais. Usa esa opción documentada en lugar de desactivar o kill switch ou todo o cortalumes, porque eses cambian moito máis do que a emisión necesita. Se a rede separa os dispositivos intelixentes a propósito, pide ao propietario o tráfico concreto de descuberta, control e retorno en lugar dun acceso plano.
nc -vz 192.168.1.50 8009Unha proba de control contra o receptor separa o permiso da accesibilidade: un porto que responde significa que a ruta existe, mentres que un rexeitamento significa que se permitiu ao teléfono descubrir o dispositivo e aínda así non pode falar con el. Os portos 8008 e 8009 son os portos habituais de emisión, e unha aplicación pode usar outros, así que trata un só porto rexeitado como unha pista e non como un veredicto. A excepción e o permiso da aplicación seguen sendo independentes, porque conceder acceso local non crea unha ruta e engadir unha ruta non concede permiso. Un kill switch tamén pode tirar o tráfico local tras unha reconexión, e por iso a descuberta debe volver probarse cando o túnel regresa.
A reprodución pode non usar a conexión do teléfono
Nunha sesión dirixida pola aplicación, o teléfono entrega ao receptor un enderezo de medios e o receptor descárgao pola súa propia conexión, así que cambiar o enderezo público do teléfono non fai nada polo fluxo. Un título restrinxido por conta pode fallar igualmente polos seus propios motivos, e os requisitos de emisión de Google cobren a compatibilidade de aplicación e dispositivo, non a ruta de rede. Encamiñar o televisor mesmo por un túnel é unha configuración aparte con cadansúas cuestións de política.
Dúas pistas distinguen os modos. Unha emisión que sobrevive ao bloqueo da pantalla do teléfono está dirixida pola aplicación, porque o receptor descarga pola súa conta; unha réplica que se detén cando se bloquea a pantalla do emisor é un fluxo continuo desde o teléfono. Cando a descuberta e o control funcionan pero a reprodución se atasca, mira en cambio a ligazón Wi-Fi do receptor e a súa ruta a internet, porque unha proba de velocidade no teléfono describe o teléfono e non o televisor.
Desfai a excepción e volve probar
Todo cambio temporal necesita un camiño de volta, e a orde importa. Quita a excepción de LAN, volve conectar o túnel para que o cliente reaplique a súa política, logo repite o paso de descuberta e anota se o receptor volve desaparecer. Esa secuencia diche se a excepción facía o traballo ou se algo máis cambiou 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 despois as tres etapas por separado, porque aprobar unha non di nada das outras. Logo comproba que as aplicacións do teléfono non relacionadas seguen a ruta prevista, porque unha excepción local que se converteu en silencio nunha evasión completa é un resultado peor que unha emisión que necesita un toque extra.