Nenhuma rota repara um pool VPN que se sobrepõe à sua LAN

A aplicação afirma que o túnel está saudável e, no entanto, metade dos destinos de que precisa nunca responde. O reflexo é acrescentar uma rota ou baixar uma métrica, e esse reflexo é o mito que vale a pena matar primeiro. Quando a LAN do próprio cliente e o pool do túnel reclamam o mesmo prefixo, a tabela de rotas sustenta dois factos incompatíveis, e nem uma rota predefinida nem uma métrica os resolve. A reparação é uma decisão de endereçamento, e nenhuma edição de rotas a substitui.

Porque é que uma rota extra não pode dividir um prefixo

Uma rota não consegue separar duas reivindicações sobre um prefixo, por isso o gesto sensato é parar de procurar a linha de rota certa. A pilha não coloca um prefixo idêntico à frente da rota ligada, e uma entrada mais específica captura o endereço, mas torna o anfitrião local que o possui inalcançável. O que parece um problema de encaminhamento é uma colisão de endereçamento, e as duas reparações mudam endereços em vez de rotas. Teste a afirmação na sua própria máquina antes de a aceitar.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Pergunte ao sistema por um único endereço e repare em que interface é que ele nomeia. Linux, macOS e Windows respondem com uma consulta só de leitura que indica a interface escolhida e o salto seguinte sem transmitir nada. Quando a resposta aponta para o adaptador físico enquanto o túnel está ativo, o kernel trata o endereço como estando na ligação e não como algo que o túnel pudesse transportar.

Coloque o prefixo concedido pelo fornecedor ao lado do que o router de casa serve e compare-os como cadeias. A correspondência exata é o caso claro, e um pool mais amplo do fornecedor que contenha a sub-rede de casa falha da mesma forma, mas é mais fácil de deixar passar. Dois prefixos que apenas parecem semelhantes não são uma colisão, por isso anote ambos antes de mudar seja o que for.

Leia o pool que o cliente recebeu de facto

Leia o que o cliente recebeu, não a página de marketing do fornecedor. Aumente o detalhe do registo de um cliente OpenVPN e as rotas empurradas pelo servidor aparecem nele, revelando os prefixos do túnel; noutros locais o pool surge nos detalhes da ligação ou no próprio adaptador. Peça ao fornecedor a lista completa dos intervalos privados que utiliza, porque um único /24 hoje pode ser dois amanhã. Evitar os blocos RFC 1918 habituais não é o mesmo que evitar a atribuição que realmente lhe foi dada.

Um pool também pode encolher ou deslocar-se entre regiões, por isso a lista precisa de uma data e de um responsável. Trate qualquer resposta do fornecedor mais antiga do que a sua última alteração de plano como uma conjectura, não como um facto. Pergunte outra vez antes de se comprometer com um intervalo, e guarde a resposta com as notas de rede para que a pessoa seguinte herde a prova.

A renumeração é a reparação que pode fazer

Se o servidor VPN não for seu para alterar, mudar a LAN de casa é a única reparação disponível, e essa é a situação habitual com um fornecedor comercial. Escolha um intervalo fora do pool do fornecedor e fora dos intervalos de que possa precisar mais tarde, e verifique-o contra cada outro local a que chega por um túnel. Espere uma interrupção curta e uma cauda mais longa de dispositivos esquecidos: um que ainda guarda o endereço antigo parece funcionar até precisar do gateway.

1. Primeiro o inventário: o endereço do próprio router, o âmbito DHCP, as reservas, os reencaminhamentos de portas e qualquer dispositivo cujo endereço foi escrito à mão.
2. Depois altere o prefixo LAN do router e o âmbito DHCP em conjunto dentro de uma janela de manutenção, e renove os contratos com fios antes dos sem fios.
3. A seguir corrija os endereços estáticos: impressoras, armazenamento em rede, tudo com um gateway codificado.
4. Por fim, volte a ligar o cliente VPN e confirme que o endereço do túnel já não colide com a LAN.

Percorra os endereços nessa ordem e não todos de uma vez, e deixe o intervalo antigo documentado durante algum tempo para que um dispositivo obsoleto seja reconhecível em vez de misterioso. Um dispositivo que nunca renova anuncia-se ao não chegar ao gateway, o que é uma pista muito melhor do que uma chamada ao suporte. Se o router entrega contratos de mais de um dia, encurte-os durante a janela.

O que um alias pode e não pode fazer

Quando o servidor é seu, traduzir endereços no cliente pode expor o prefixo remoto dentro de um intervalo local livre, de modo que o mesmo anfitrião responde num segundo endereço. O OpenVPN comunitário fá-lo com client-nat, e essa diretiva é específica desse cliente, ausente nos clientes comerciais e móveis com que as pessoas costumam compará-la. A montagem exige uma rota que corresponda à tradução, um intervalo livre para o alias e um servidor disposto a responder ao endereço não traduzido do cliente. Nada disso ajuda quando o cliente pertence a um fornecedor gerido que não pode configurar.

Assim que a alteração entrar em vigor, chegue a um anfitrião local e a um remoto primeiro por endereço e depois por nome, anotando a rota que o sistema escolhe de cada vez. Um nome ainda pode resolver-se no intervalo antigo, por isso endereços e nomes merecem verificações independentes. Reinicie um cliente e um dispositivo do lado do servidor se algum deles ficou ligado durante a alteração, porque as entradas de vizinhança em cache sobrevivem à edição.

Escreva os prefixos em que ficou onde as pessoas realmente olham: as notas de rede, o campo de comentários do router, a página de boas-vindas. Alguém vai escolher 192.168.1.0/24 outra vez, e a colisão volta com essa pessoa.