Smart TV na VPN: por que o casting e o DNS quebram separadamente

A sua televisão mostra o catálogo estrangeiro, e o botão de casting do telefone já não a lista. As duas queixas começam com uma frase que nomeia quatro definições em quatro páginas do roteador. Corrija a saída e a descoberta quebra; corrija a descoberta e o próximo lease entrega a saída a outro dispositivo. A ordem abaixo vai do seletor até ao caminho de casting.

Onde vive cada uma das quatro decisões

Anote as quatro antes de abrir um menu, porque cada uma vive numa página diferente e falha num sítio diferente. O seletor escolhe a que cliente o túnel se aplica, o resolvedor decide onde os nomes são respondidos, a família de endereços decide se o IPv6 é sequer coberto, e o caminho local decide se o telefone e a televisão ainda se veem. Uma alteração numa parece completa a partir da página onde está. O dano das outras três aparece mais tarde, noutro menu, como outra queixa.

Os menus do firmware variam, mas as quatro localizações raramente. O seletor é um mapeamento estático no servidor DHCP mais uma regra de firewall que lhe corresponde. O resolvedor fica junto ao serviço DNS, onde uma entrada de encaminhador ou uma lista de servidores a montante decide que nomes o roteador responde e de onde saem as consultas. A definição de família pertence à própria interface, onde IPv4 e IPv6 são configurados em separado e uma política só pode cobrir a primeira. O caminho local é um comutador do ponto de acesso, ou isolamento de clientes ou uma rede de convidados com a sua própria firewall.

Faça o seletor durar mais que o lease

Tanto uma política por dispositivo como um segmento dedicado funcionam, e a melhor escolha é a que o firmware consegue manter sem que uma segunda pessoa se lembre dela. A armadilha é uma regra fixada a um endereço que o servidor DHCP atribuiu segundo o seu próprio calendário: funciona até o lease mudar, e depois encaminha um portátil por outro país por razões que o dono não consegue ver. A persistência, não a arrumação, é a propriedade que vale a pena otimizar.

Envie a reserva e a regra como uma só alteração, porque uma regra que sobrevive à sua reserva é uma regra apontada ao hardware de outra pessoa. Uma regra de segmento inteiro é o seletor mais duradouro e o mais grosseiro, já que cada dispositivo atrás dessa interface herda a saída, precisasse dela ou não. Seja qual for o seletor, a pergunta da cobertura vem a seguir: uma política só IPv4 é meia decisão, e a família não coberta é a que sai sem ser notada.

Descubra que resolvedor a televisão realmente usa

Abra as definições de rede da própria televisão antes de tocar no roteador, porque é o dispositivo que resolve esta discussão. Um campo DNS definido manualmente continua a usar esse servidor, ofereça o DHCP o que oferecer, e uma box set-top configurada uma vez para outra região pode ainda apontar para um endereço que já não responde. Se o campo for automático, decide a opção DHCP do roteador, e o resolvedor do próprio roteador passa a ser a pergunta seguinte. De qualquer forma, a resposta está no ecrã do dispositivo, não no manual do firmware.

Do lado do roteador, a distinção que importa é entre nomes que o roteador responde ele próprio e nomes que reencaminha, porque esses dois caminhos podem sair por interfaces diferentes. Por isso uma consulta que resolve corretamente não diz nada sobre para onde vai um pedido de multimédia, e num gateway Linux a tabela de políticas mais uma única pesquisa de rota respondem às duas perguntas sem capturar nada na televisão:

ip rule show
ip route get 203.0.113.10

Leia o primeiro comando para a regra que marca o tráfego da televisão e o segundo para a interface que um pacote para o endereço de exemplo realmente usaria. Quando os dois discordam, o resolvedor não é o culpado; a política é. Altere uma coisa e depois execute o par novamente, porque uma lista de regras é sensível à ordem e uma entrada nova pode ensombrar a regra que transportava o tráfego. O destino está reservado para documentação, por isso uma saída colada lê-se como um exemplo.

O casting quebra na descoberta, não no fluxo

O casting são pelo menos três conversas e só uma delas transporta vídeo. O telefone descobre a televisão por multicast ou broadcast no segmento local, abre um canal de controlo para dizer o que reproduzir, e depois a televisão ou vai buscar o fluxo sozinha ou recebe-o reencaminhado do telefone. A descoberta nunca atravessa um roteador que não reencaminha esse tráfego, e é assim que uma televisão pode ser encaminhada exatamente como pretendido e ainda assim nunca aparecer na lista de casting.

As redes de convidados e o isolamento de clientes são a causa habitual, e ambos fazem exatamente aquilo para que foram configurados. Desligar o isolamento em toda a rede sem fios para que um dispositivo reapareça é a sobrecorreção habitual, e reabre todos os caminhos telefone-a-telefone que a definição existia para fechar. Há respostas mais estreitas: uma regra de passagem para o tráfego de descoberta e controlo entre dois endereços, um SSID separado para as televisões, ou uma exceção documentada na rede de convidados.

Teste o casting com a regra de isolamento ainda no lugar, depois acrescente apenas a exceção de descoberta e teste de novo. Se a segunda tentativa encontrar a televisão, a exceção é a solução e o resto do segmento pode ficar como estava.

Pare o túnel e observe para que lado falha

A última verificação é a que a maioria das instalações salta: desligue o túnel e observe se a televisão para ou sai discretamente pela ligação local. Uma política que exprime uma preferência falha aberta, e essa falha é fácil de não ver porque a reprodução continua enquanto a saída regressa ao ISP. Uma regra de kill-switch falha fechada, em vez disso, e a televisão não relata nada até o túnel voltar. Nenhum dos dois comportamentos é errado; não saber qual configurou é que é.

Verifique novamente quatro coisas após qualquer alteração, nesta ordem. O seletor ainda corresponde ao dispositivo após o próximo lease ou reinício. O resolvedor responde no caminho que a política pretende, e não a partir de um servidor que o dispositivo memorizou. A família de endereços na política cobre todas as famílias que a televisão e a rede de acesso realmente usam. O casting ainda encontra a televisão a partir do telefone que será realmente usado, e não de um telefone de teste no mesmo SSID.

Guarde essas quatro linhas junto à configuração do roteador e não num fio de conversa: o que a regra corresponde, que resolvedor a televisão pergunta, que família está coberta e que caminho local o casting precisa. A próxima pessoa que abrir a firewall lerá a configuração muito antes de ler um ticket. Até lá, essa pessoa pode ser você.