A mesma sub-rede nas duas pontas: mapeie a LAN remota para um intervalo livre

A casa e o escritório usam os dois 192.168.1.0/24, então um pedido para 192.168.1.1 tem duas respostas possíveis e o cliente escolhe uma sem perguntar. Renumerar uma rede de escritório em funcionamento raramente é popular, e os endereços do roteador costumam estar gravados em impressoras, câmeras e documentação. O mapeamento de endereços no lado do cliente pode apresentar a rede remota sob um intervalo livre em vez disso, e a parte do host pode permanecer igual para que 192.168.1.20 apareça como 10.203.41.20. A pegadinha é que só alguns clientes o implementam, e não faz nada pelo caminho de volta.

Duas visões do mesmo host

O mapeamento mantém a parte do host e altera apenas a parte de rede. A mesma máquina responde então em dois endereços conforme onde você está. Anotar as duas colunas antes de configurar qualquer coisa evita uma leitura errada posterior dos logs e das regras do firewall.

Os dispositivos locais de casa mantêm os próprios endereços 192.168.1.x, e é esse o objetivo do exercício. A impressora da sala ao lado continua acessível enquanto o escritório aparece sob um intervalo que não colide.

A ordem dos argumentos é toda a manha

A opção recebe uma direção, uma rede e máscara, e um alias: a primeira rede é o que o cliente vê, o alias é o que o servidor vê. Para recursos que vivem atrás do gateway remoto, a direção é a forma de destino. Inverter as duas redes porque o último argumento se chama alias é o erro que produz um túnel que conecta e não mapeia nada.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

A rota é o que envia os pacotes do cliente para o novo intervalo ao túnel; a tradução reescreve o destino no caminho. Uma resposta de 192.168.1.20 é reescrita de volta para 10.203.41.20 para que o socket no cliente permaneça coerente. Um único host funciona da mesma forma com uma máscara de comprimento total, desde que a rota e o mapeamento descrevam o mesmo endereço.

Isto é um mapeamento de endereços, não um mapeamento de portas. Dois serviços num mesmo host não podem ser separados com ele, e um protocolo que embute endereços IP na sua carga útil ainda verá os reais.

O mapeamento não cria um caminho de volta

A tradução acontece no cliente, então o servidor ainda precisa encaminhar as respostas para o túnel e seu firewall ainda precisa permiti-las. Se o gateway remoto não sabe como alcançar a sub-rede do túnel, o pedido chega e a resposta sai pela porta errada; o mapeamento só faz a falha parecer um problema do cliente.

As regras do lado do servidor deveriam descrever os endereços que existem no servidor depois da tradução, não o intervalo visível ao cliente. Copiar o alias para uma regra de permissão desperdiça uma tarde, porque nenhum pacote desse lado o carrega.

Escolha um intervalo de alias que não colida com nada mais que o cliente encaminhe: outra VPN, uma rede de contêineres, um segundo escritório. Uma colisão aqui reintroduz a ambiguidade original sob outro número e é mais difícil de ver porque os endereços parecem desconhecidos.

Nomes e cargas úteis sobrevivem à tradução

Um nome de host que resolve para o 192.168.1.20 real envia o navegador ao dispositivo local em vez do remoto, diga o que disser a tabela de roteamento. A resposta do DNS privado precisa apontar para o intervalo visível ao cliente, enquanto o certificado TLS ainda carrega o nome que a aplicação espera. Teste com o nome em vez do endereço, porque o endereço pode funcionar enquanto o nome resolve em silêncio na direção errada. Quando o gateway remoto também serve essa zona, seus próprios registros também precisam do intervalo visível ao cliente.

Redirecionamentos, URLs embutidas e aplicações que entregam o próprio endereço numa carga útil podem quebrar de formas que nenhum mapeamento de pacotes consegue reparar. Trate-as como problema de aplicação e dimensione o esforço de acordo antes de prometer que renumerar não é necessário.

Três verificações antes de se comprometer

Primeiro, confirme a implementação do cliente. O Community OpenVPN suporta esta opção; a base de código do OpenVPN 3 lista-a entre os recursos não suportados, então um perfil enviado a um cliente no estilo Connect pode simplesmente ignorá-la. Uma diretiva que é aceita e nunca aplicada é pior que um erro, porque o túnel parece saudável.

Segundo, verifique a rota e a tradução separadamente com uma janela de diagnóstico curta em alta verbosidade, e então teste o serviço real em vez de um ping. Terceiro, confirme que o roteador local e o recurso remoto continuam distinguíveis do cliente, pois esse era o objetivo original.

Se o cliente não puder fazer a tradução, peça ajuda ao lado do gateway ou aceite uma renumeração. Adicionar mais rotas para o mesmo endereço não é um projeto.