Casa e escritório usam ambos 192.168.1.x: e agora?

Percorra quatro verificações: para que endereço o nome resolve, que prefixo a rede local usa, que rota o kernel escolhe para esse destino e o que responde na outra ponta. O login da VPN não é uma delas, porque se conclui independentemente de qual rede vence. Faça as verificações em ordem e a sobreposição torna-se visível no segundo passo em vez do quarto.

Um login bem-sucedido diz que o túnel está ativo; não diz nada sobre para onde um determinado endereço aponta.

Um endereço, duas máquinas

Um host escolhe um caminho da sua tabela de roteamento e das regras de política, usando o endereço de destino. Nada lhe diz que um pedido ao salto 192.168.1.20 se destina ao servidor do escritório e não a um dispositivo na sala ao lado. Quando as duas redes estão no mesmo intervalo privado, a rota mais específica vence e tudo o resto depende de qual entrada uma reconexão instalou por acaso. Nada no próprio endereço carrega essa distinção.

ip route get 192.168.1.20

Essa consulta indica a interface e o próximo salto que o kernel escolheu, que é a segunda verificação da lista. Compare os prefixos local e remoto antes de fazer qualquer outra coisa. Se a LAN local for 192.168.1.0/24 e o site remoto também for 192.168.1.0/24, a sobreposição é o achado, e nenhuma opção do cliente a corrige.

Renumere o lado que controla

Um router pessoal costuma ser o lado mais fácil de mover. Escolha um intervalo que não colida com as redes remotas que realmente usa, e note que 10.x.x.x também não está livre automaticamente, porque muitos sites o usam. Planeie a mudança: concessões DHCP, endereços reservados, filas de impressão e tudo com um endereço fixo precisam de atenção. Faça a renumeração numa janela em que possa recuperar o router sem a VPN.

Verifique a lista de prefixos remotos primeiro, não depois. Escolher um novo intervalo que colida com outro site de escritório produz o mesmo problema com mais trabalho investido.

Quando nenhum dos lados pode mudar

Se nenhuma das redes puder ser renumerada, as opções restantes vivem no servidor. Um gateway pode traduzir uma rede remota para outra sub-rede para os clientes VPN, usando NAT baseado em políticas ou uma variante bidirecional, para que o cliente veja um endereço único. Isso é um desenho de gateway e não um comutador que todo o cliente de ambiente de trabalho fornece, e altera que endereço os utilizadores escrevem e que nomes têm de coincidir. Uma rota copiada de um fórum não consegue distinguir dois destinos idênticos.

Os intervalos de endereços privados continuam privados; o problema é a reutilização, não os intervalos em si.

Prove que máquina respondeu

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

Após qualquer alteração, teste o recurso do escritório e os dispositivos locais em conjunto. Se um dispositivo doméstico conhecido responder onde deveria estar o servidor do escritório, ou o certificado TLS indicar o host errado, pare e identifique o destino antes de continuar. Obter uma resposta desse endereço não estabelece que máquina a enviou. Verificar o assunto do certificado é um dos poucos sinais fiáveis disponíveis nesse momento.

Não substitua os endereços privados do escritório por endereços públicos arbitrários que não controla. Isso troca uma sobreposição por um problema de encaminhamento e propriedade pior e mais difícil de explicar.

Registe o prefixo local, o prefixo remoto e a alteração que o resolveu. A próxima sobreposição parecerá diferente mas seguirá o mesmo padrão.