Porque é que a transmissão deixa de funcionar depois de ativar a VPN do router
A descoberta passa por multicast link-local, enquanto a TV vai buscar os media sozinha. Uma regra predefinida da política pode capturar o pedido LAN e enviá-lo para o túnel.
A transmissão funcionava antes de a VPN do router ser ativada e falha imediatamente depois, enquanto a navegação normal no telemóvel continua a funcionar. Os dois factos são coerentes, porque a transmissão não é uma única ligação. O telemóvel descobre e controla o recetor na rede local, e depois o recetor vai buscar os media pela sua própria ligação.
Dois caminhos que falham de forma diferente
O caminho de controlo é local. O telemóvel encontra um recetor perguntando à rede local, e depois abre uma ligação de controlo para o endereço que aprendeu. Se o recetor nunca aparecer na lista, o passo de descoberta falhou antes de ter sido pedido qualquer media.
O caminho dos media não é necessariamente local. Muitos recetores vão buscar o fluxo sozinhos, pela sua própria ligação e com as suas próprias credenciais, por isso a rota do telemóvel não descreve a rota do recetor. Um telemóvel que parece usar uma saída não diz nada sobre para onde vai o tráfego da TV.
É esta separação que faz a falha parecer estranha. O túnel alterou a tabela de rotas do telemóvel e não alterou a da TV, por isso um sintoma que aparece de um lado do par tem de ser seguido desse lado. Investigar o dispositivo errado é a razão habitual para uma correção parecer não fazer nada.
Porque é que a descoberta falha primeiro
A descoberta passa normalmente por multicast link-local. O mDNS envia para 224.0.0.251 no porto UDP 5353, e o SSDP envia para 239.255.255.250 no porto UDP 1900. Ambos estão limitados a uma única ligação por conceção, e é por isso que o router não os reencaminha entre segmentos sem ajuda de um repetidor ou proxy. Uma VPN encaminhada não estende um grupo multicast, e uma rota de política não consegue fazer aparecer noutra ligação um grupo que nunca saiu da sua.
Portanto a primeira falha não tem nada a ver com encriptação. O multicast do telemóvel sai da interface em que foi enviado, o recetor está num segmento que nunca o vê, e a lista de dispositivos volta vazia. Uma lista vazia não é prova de que a TV perdeu o acesso à internet.
O isolamento produz um sintoma idêntico sem qualquer VPN. As redes de convidados e o isolamento de clientes do ponto de acesso impedem deliberadamente que os dispositivos falem entre si, e ativar uma VPN no router sobre um segmento isolado não muda nada nisso. Verifique a definição de isolamento antes de verificar o túnel. É a resposta mais barata e a mais comum.
A disposição dos segmentos é a outra metade. Um segundo router, um nó mesh noutro modo ou um segmento com fios atrás de outro NAT colocam o recetor onde o tráfego de descoberta do telemóvel não chega.
Porque uma regra predefinida da política pode engolir um pedido local
Um router que encaminha todo o tráfego para um túnel instala uma rota predefinida na interface do túnel. Se o prefixo LAN não for excluído dessa política, um pacote endereçado a um dispositivo a dois metros passa agora a corresponder à rota predefinida, e o router envia o pedido de controlo para o túnel em vez de para o switch.
| 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 ordem das regras decide o resultado. O encaminhamento por política avalia as regras por ordem de prioridade, por isso uma exceção para o prefixo local tem de estar antes da regra que seleciona a tabela do túnel. Acrescentar a exceção depois da regra do túnel não tem efeito, e é por isso que uma configuração com bom aspeto ainda pode enviar tráfego LAN para uma saída remota.
A correção é estreita: permita os destinos locais específicos de que o fluxo de transmissão precisa, e deixe o resto do isolamento em paz. Remover o isolamento de clientes como primeiro passo cura o sintoma, mas deita fora um controlo que a rede foi concebida para ter.
Uma verificação rápida no telemóvel determina qual das duas falhas tem. Se a rota para o recetor aponta para o túnel, o problema é a política. Se aponta para a LAN e a descoberta continua a falhar, o problema é o multicast ou o isolamento, e nenhuma alteração de rota ajudará.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTeste a fase que mudou, não o país
As observações registadas valem mais do que experiências repetidas. Anote se o recetor aparece na lista de dispositivos, se um pedido de controlo chega até ele e se a reprodução começa depois de escolher um fluxo. Cada resposta retira um passo das suspeitas.
Depois teste cada passo diretamente em vez de trocar de local de saída. Mudar de país da VPN testa o caminho dos media e deixa os passos de descoberta e controlo intactos, por isso pode parecer ajudar por acaso sem lhe ensinar nada.
Do lado do recetor, verifique a sua própria rota e o estado da sua própria conta. Uma TV que vai buscar media por uma saída diferente da do telemóvel é um desenho normal, e uma falha aí é uma questão sobre a política de rede do recetor, não sobre o túnel do telemóvel.
Escreva o resultado numa única frase sobre que passo se partiu e o que o alterou. Essa frase vale mais do que uma semana a mudar de país, e sobrevive à próxima atualização de firmware.
A transmissão é um bom caso de teste para uma regra geral sobre túneis. Quando se acrescenta um a uma rede, a primeira pergunta é que destinos nunca deveriam ter entrado nele. A segunda é quais deles a política acabou por aceitar em silêncio.