Dispositivos locais desaparecem na VPN: três falhas separadas

Uma impressora que desaparece da lista de dispositivos quando a VPN sobe pode continuar a responder no seu endereço. A lista é preenchida pela descoberta, o nome pode vir de um resolver e o próprio serviço é alcançado através de um socket, e os três podem falhar de forma independente. Comparar o que funciona em cada camada diz-lhe que funcionalidade alterar. Ativar primeiro todas as exceções de acesso local elimina as provas.

Essa é a diferença entre um dispositivo em falta e um dispositivo que simplesmente não é anunciado.

Descoberta, nomes e acessibilidade são três camadas

Os protocolos de descoberta dependem de multicast ou broadcast, e estes não atravessam um túnel encaminhado por predefinição, razão pela qual um dispositivo pode desaparecer de uma lista continuando perfeitamente acessível. A resolução de nomes é uma segunda camada: uma VPN pode mudar o resolver, e um nome que antes era respondido pela rede local pode agora ser respondido noutro lugar ou não ser respondido de todo. A acessibilidade é a terceira: uma rota, uma regra de firewall e um serviço à escuta. Cada camada pode falhar enquanto as outras duas estão bem.

Teste-as de baixo para cima. Uma única verificação de acessibilidade torna a separação óbvia: nc -vz 192.168.1.20 443 ou tem sucesso, o que significa que o caminho e o serviço estão bem e o nome é o suspeito, ou falha, o que desloca a questão para o encaminhamento e a política. Depois pergunte pelo nome. A primeira falha que encontrar é a camada onde trabalhar, e as camadas acima não a podem compensar.

Pergunte primeiro pelo endereço, depois pelo nome do anfitrião

Se o endereço responde e o nome não, o problema é a resolução e não o encaminhamento. Um cliente VPN que instala o seu próprio resolver pode mudar qual servidor responde a nomes locais, e um que não reencaminha o domínio local deixa o nome sem resposta. Se o endereço também falhar, o problema é o caminho: uma rota predefinida pelo túnel, um bloqueio do tráfego local do lado do cliente ou uma regra de firewall que só permite a interface física.

Se ambos funcionam mas a descoberta automática não, o dispositivo simplesmente não se anuncia através do túnel. É o comportamento esperado para a descoberta baseada em multicast, não uma falha de configuração. Adicionar o dispositivo por endereço costuma ser a solução honesta.

O que o interruptor de acesso local altera realmente

Uma definição de acesso à rede local normalmente permite que o tráfego para a sub-rede ligada diretamente contorne o túnel, e faz coisas diferentes em clientes diferentes. Não configura o reencaminhamento para um escritório remoto e não altera a firewall do anfitrião nem as permissões próprias da aplicação. Também não torna inequívoca uma sub-rede sobreposta. Leia a documentação do cliente sobre o que a definição abrange antes de a ativar de forma ampla.

Uma exceção estreita para um único dispositivo de confiança é melhor do que uma autorização geral, sobretudo numa rede de convidados onde o bloqueio pode ser deliberado. Um endereço privado não é uma verificação de identidade, por isso a escolha depende da rede em que está.

Quando as redes se sobrepõem

Se a rede doméstica e a remota usarem o mesmo intervalo, o encaminhamento torna-se ambíguo e nem o interruptor de acesso local nem uma exceção o resolvem. Dois serviços no mesmo endereço não podem ser ambos alcançados, e qual ganha depende da especificidade da rota e da ordem, não da intenção. A solução é o planeamento de endereços, não uma definição do cliente. Verifique os intervalos antes de passar uma noite com a impressora.

Para um dispositivo atrás da gateway remota, o operador é dono do reencaminhamento, da política do anfitrião e da rota de retorno. Uma caixa de seleção local no cliente não pode fornecer nenhuma delas, e pedi-la é mais produtivo do que experimentar interruptores.

Registe qual camada falhou e o que alterou. O próximo dispositivo falhará num dos mesmos três locais.