Transmissão por VPN: descoberta, controlo ou stream?

A transmissão parte-se em três pontos que parecem idênticos do sofá. O telemóvel pode nunca ver o recetor, o recetor pode aparecer e depois recusar a sessão, ou a sessão pode começar e travar um minuto depois. Um túnel no telemóvel altera cada um desses caminhos de forma diferente, e para um deles não altera nada. Nomeie primeiro a etapa que falha e só depois decida se mudar a política é sequer a alavanca certa.

Nomeie a etapa que falha antes de mudar a política

Observe o que o telemóvel faz imediatamente depois de tocar no ícone de transmissão. Uma lista vazia é um resultado de descoberta, um toque que reporta falha é um resultado de controlo, e uma sessão que começa antes de travar é um resultado de reprodução. Esses três têm donos diferentes, e só os dois primeiros costumam envolver as definições de túnel do telemóvel.

Anote a etapa antes de mudar seja o que for. Uma correção aplicada na etapa errada torna o teste seguinte ilegível, e a maior parte do folclore sobre transmissão vem exatamente dessa confusão.

A descoberta é tráfego local, e um túnel esconde-a

Os recetores anunciam-se através de anúncios locais e o telemóvel encontra-os com consultas no mesmo link, por isso tudo o que retira o telemóvel desse link retira o recetor da lista. Um túnel que encaminha todo o tráfego para fora da LAN pode esconder essas trocas, e uma permissão de rede local ao nível da aplicação pode bloqueá-las mesmo quando a rota existe. Wi-Fi de convidados com isolamento de clientes produz a mesma lista vazia sem qualquer VPN. Prove que os dois dispositivos partilham o mesmo 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 PTR

O primeiro comando lista o que se anuncia no segmento da máquina auxiliar, e o segundo interroga o grupo de DNS multicast diretamente. Um recetor ausente de ambos também não aparecerá numa aplicação do telemóvel, seja qual for o estado do túnel. Se o recetor é visível a partir de um dispositivo com o túnel desligado e invisível a partir de um com o túnel ligado, encontrou a etapa e a causa ao mesmo tempo.

Uma exceção de LAN mantém o túnel ativo

Muitos clientes oferecem uma exceção de rede local que mantém o túnel ativo e permite endereços locais. Use essa definição documentada em vez de desligar o kill switch ou toda a firewall, porque esses mudam muito mais do que a transmissão precisa. Se a rede separa dispositivos inteligentes de propósito, peça ao proprietário o tráfego específico de descoberta, controlo e retorno em vez de acesso plano.

nc -vz 192.168.1.50 8009

Um teste de controlo ao recetor separa permissão de alcançabilidade: uma porta que responde significa que o caminho existe, enquanto uma recusa significa que o telemóvel pôde descobrir o dispositivo e continua sem lhe conseguir falar. As portas 8008 e 8009 são as portas de transmissão habituais, e uma aplicação pode usar outras, por isso trate uma porta recusada como pista e não como veredicto. A exceção e a permissão da aplicação continuam independentes, porque conceder acesso local não cria uma rota e acrescentar uma rota não concede permissão. Um kill switch também pode largar o tráfego local após uma reconexão, e é por isso que a descoberta tem de ser testada outra vez quando o túnel regressa.

A reprodução pode não usar a ligação do telemóvel

Numa sessão dirigida pela aplicação, o telemóvel entrega ao recetor um endereço de multimédia e o recetor vai buscá-lo pela sua própria ligação, por isso mudar o endereço público do telemóvel não faz nada ao stream. Um título limitado por conta pode continuar a falhar por razões próprias, e os requisitos de transmissão da Google cobrem a compatibilidade da aplicação e do dispositivo e não o caminho de rede. Encaminhar a própria televisão por um túnel é uma configuração separada, com as suas próprias questões de política.

Duas pistas distinguem os modos. Uma transmissão que sobrevive ao bloqueio do ecrã do telemóvel é dirigida pela aplicação, porque o recetor vai buscar sozinho; uma replicação que para quando o ecrã de quem envia se bloqueia é um stream contínuo a partir do telemóvel. Quando a descoberta e o controlo funcionam mas a reprodução trava, olhe para o link Wi-Fi do recetor e o seu caminho para a internet, porque um teste de velocidade no telemóvel descreve o telemóvel e não a televisão.

Desfaça a exceção e teste outra vez

Toda a mudança temporária precisa de um caminho de volta, e a ordem importa. Remova a exceção de LAN, volte a ligar o túnel para que o cliente reaplique a sua política, repita então o passo de descoberta e registe se o recetor desaparece outra vez. Essa sequência diz-lhe se era a exceção que estava a fazer o trabalho ou se algo mais mudou entretanto.

# 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'

Depois verifique as três etapas em separado, porque passar numa não diz nada sobre as outras. Verifique em seguida se aplicações do telemóvel sem relação continuam a seguir a rota pretendida, porque uma exceção local que se tornou silenciosamente num desvio total é um resultado pior do que uma transmissão que exige um toque extra.