Roteador em modo cliente VPN: por que os dispositivos LAN desaparecem

A crença de que o modo cliente por si só mata o acesso à LAN leva as pessoas ao menu de configuração errado, e as causas reais costumam ser duas. O túnel não remove a ponte LAN nem impede que clientes com e sem fio se alcancem. O que quebra o acesso local é uma função de inspeção no caminho de encaminhamento do roteador ou um intervalo de endereços LAN que se moveu quando o firmware o fez. Ambos produzem a mesma queixa, e nenhum é corrigido reinstalando o perfil VPN.

O mito e o que o modo cliente realmente muda

O modo cliente adiciona uma interface de túnel e uma rota padrão que passa por ela, e então encaminha o tráfego LAN para esse túnel. A ponte entre as portas cabeadas e os rádios sem fio permanece intacta, assim como a comutação local. O que muda é a política: qual tráfego é encaminhado, onde é traduzido e qual resolvedor os clientes recebem.

Essa distinção importa porque uma LAN quebrada geralmente significa que uma dessas três políticas mudou, não que o roteador deixou de ser um switch. Um roteador que ainda responde à própria página de administração é prova de que a interface LAN está viva. Um roteador que não responde a nada tem outro problema, como um endereço LAN alterado ou um cliente na sub-rede errada.

Então o primeiro passo útil é descobrir qual camada quebrou, não mudar a camada que você suspeita.

Teste três alvos antes de tocar em uma configuração

De um cliente cabeado, teste três alvos separadamente e anote cada resultado: o endereço LAN do próprio roteador, outro dispositivo no mesmo switch por IP e algo acessível apenas pelo túnel. Faça nessa ordem, porque cada resultado elimina uma camada diferente. Use endereços em vez de nomes na primeira passagem, já que uma falha de nome mistura DNS a uma questão de conectividade.

O padrão das respostas é o diagnóstico. Um roteador que responde enquanto os dispositivos locais não o fazem aponta para comutação local ou uma função de filtragem, não para roteamento. Os dispositivos locais que respondem enquanto o lado do túnel não o faz apontam para a rota do túnel ou o firewall remoto. Tudo responde por endereço enquanto os nomes falham é uma questão de resolvedor, e nenhuma edição de rotas vai corrigir isso.

Mantenha a tabela ao lado dos resultados dos testes. Ela transforma uma queixa vaga em uma linha sobre a qual você pode agir.

A camada de segurança dentro do caminho de encaminhamento

Os roteadores de consumo incluem cada vez mais uma função de inspeção que vigia o tráfego encaminhado, e ela roda no mesmo caminho que transporta os pacotes da LAN para o túnel. Quando essa inspeção não consegue classificar o tráfego do túnel, o encaminhamento pode travar enquanto o túnel continua ativo e o roteador relata uma conexão saudável. Nada no log do VPN mostra isso, porque a VPN de fato conectou.

O diagnóstico é um experimento controlado, não uma mudança permanente. Anote a configuração atual, desative a função durante um teste, suba o túnel novamente e teste um único host local por endereço. O encaminhamento que volta é a prova de que você precisava, e o compromisso então se torna uma decisão em vez de um palpite. Se nada mudar, reative-a imediatamente e passe para a causa do endereçamento.

Deixar uma função de segurança paga desativada para que um túnel continue funcionando é um compromisso a ser feito deliberadamente e anotado. Também vale perguntar se o túnel pertence a outro dispositivo, porque um roteador que precisa inspecionar tudo e um roteador que precisa encaminhar tudo são dois trabalhos diferentes.

A segunda causa: o intervalo LAN se moveu

As atualizações de firmware frequentemente devolvem o endereço LAN ao padrão do fabricante, e alguns roteadores têm um interruptor de modo explícito que decide se a LAN mantém um intervalo privado ou herda um do equipamento acima. Um cliente que espera 192.168.8.x pode acabar em 10.64.0.x, e então uma sessão SSH para um host expira mesmo com o túnel perfeitamente saudável.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Leia o prefixo e o gateway da concessão antes de abrir a página do roteador. Os dois primeiros comandos mostram o que o cliente realmente recebeu, e o terceiro mostra qual interface o cliente usaria para um endereço local, e é assim que uma rota remanescente ou uma sub-rede obsoleta se revela. Depois compare com a página LAN e o modo em que o roteador está.

Se o intervalo não puder voltar, atualize cada objeto que o nomeia: reservas DHCP, qualquer rota estática para a sub-rede antiga e cada regra de firewall que carregue o prefixo anterior. Um intervalo que colide com a sub-rede remota do túnel é a variante pior, porque os dispositivos locais continuam acessíveis enquanto os destinos remotos são silenciosamente roteados errado para a LAN.

Reconecte e teste novamente em ordem de pacotes

Depois de qualquer uma das duas mudanças, reconecte o túnel e repita os testes em ordem de pacotes: roteador, host local, host remoto, depois nomes, depois a aplicação. Testar a aplicação primeiro esconde qual camada ainda está quebrada, e uma nova tentativa do navegador contra um nome em cache pode parecer uma falha de roteamento.

Anote a versão do firmware, o prefixo LAN e o estado da função de inspeção ao lado do perfil VPN. Os três são configuração que a próxima atualização pode sobrescrever, e duas linhas de notas economizam a hora que você acabou de passar.