Alcançar uma /24 remota por um túnel: NETMAP, DNAT ou rota?

Você pode alcançar uma sub-rede atrás de um endpoint de túnel de três maneiras, e um minuto de levantamento de fatos costuma desqualificar duas. Os fatos são se os servidores do outro lado precisam distinguir usuários, se alguém lá algum dia vai discar para o seu intervalo, e quem pode editar o roteador remoto. Responda a esses três e o projeto se escolhe sozinho. O resto assume que você opera o endpoint e pode editar o firewall dele.

Três opções, e o que cada uma realmente muda

Mapeamento de prefixo, DNAT por host e um prefixo roteado movem pacotes entre os mesmos dois intervalos, mas mudam coisas diferentes. O mapeamento inventa um intervalo alias e reescreve endereços aritmeticamente em voo. Regras por host também reescrevem, só que cada destino é nomeado à mão. Um prefixo roteado não reescreve nada: os pacotes mantêm os endereços reais e as duas pontas concordam sobre onde esses endereços vivem.

Comece a eliminação pelo lado remoto, onde as restrições são mais difíceis de mudar. Se um servidor de lá grava endereços de clientes em logs, compara-os com uma lista de permissões ou os entrega a outro sistema, traduzir a origem destrói seu único identificador. Se o lado remoto também precisa discar para dentro, a tradução fica totalmente excluída, porque ninguém lá sabe que o alias existe. Só quando o lado remoto apenas responde a solicitações as opções mais baratas ficam seguras.

Pares de prefixos, e por que os tamanhos precisam coincidir

NETMAP é um alvo da tabela nat que funciona em um par de prefixos de comprimento idêntico. Não tem tabela por endereço dentro: remove o prefixo, mantém os bits de host e os reanexa ao novo prefixo, e é por isso que uma /24 mapeia para uma /24 e nunca para uma /25. A posição decide a direção: uma correspondência de destino em PREROUTING reescreve para onde um pacote vai, e uma correspondência de origem em POSTROUTING reescreve de onde ele veio.

Um host em 192.168.2.17 aparece para seus clientes como 10.50.1.17, e o último octeto não é decoração — é o mesmo número dos dois lados. Adicione amanhã um host em 192.168.2.40 e o alias dele é 10.50.1.40, sem regra para editar.

Os clientes ainda precisam de uma rota para o intervalo alias apontando para a sua caixa, a menos que o alias caia numa sub-rede que eles já alcançam. O gateway não precisa de rota para o alias, porque a tradução de destino ocorre em PREROUTING, antes da consulta de rota. O encaminhamento também precisa estar ligado, senão o kernel descarta o pacote depois da reescrita. Os três comandos abaixo são a configuração inteira num gateway estilo Debian com clientes em br0, o alias em 10.50.1.0/24 e o túnel em tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

A resposta precisa achar o próprio caminho de volta

Reescrever o destino só decide onde um pacote é entregue. O servidor remoto ainda precisa responder a um endereço que alcança, e há duas maneiras de organizar isso. Traduza a origem para que as respostas voltem à sua caixa, ou deixe a origem e dê ao lado remoto uma rota para o intervalo dos clientes.

O masquerading na saída é o caminho mais curto: uma regra em POSTROUTING e o lado remoto vê o seu endereço de túnel, então não precisa de rota própria. O custo é que todo usuário colapsa num único endereço, e os logs por usuário deixam de significar qualquer coisa. Deixar a origem intacta preserva essa informação, mas então o site remoto precisa devolver as respostas do intervalo dos clientes pelo túnel.OpenVPN servidor isso é um push "route 10.50.9.0 255.255.255.0", mais uma route 192.168.2.0 255.255.255.0 linha.

A falha cara é fazer metade de cada. Se você mascara parte do tráfego enquanto o lado remoto também carrega uma rota de volta para outro tráfego, as respostas chegam numa interface onde a entrada de rastreamento de conexão nunca foi vista. O cliente relata timeout para uma solicitação que o servidor registrou como atendida. As duas direções de um fluxo precisam atravessar a mesma instância do netfilter: um gateway traduzindo, não dois firewalls em série.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Leia a entrada nas duas direções: a tupla original mantém seu alias no destino, enquanto a tupla de resposta carrega o endereço real. Se a tupla de resposta falta, o problema é o caminho de volta, não a regra. Se os contadores de PREROUTING nunca se moveram, o pacote nunca chegou àquele hook.

Colisões e a consulta que roda primeiro

Dois intervalos diferentes podem colidir, e ambas as falhas parecem um túnel quebrado em vez de uma regra ruim. O alias que você inventa precisa estar sem uso ao longo de todo o caminho, e o intervalo remoto real não pode já existir na sua rede. Uma duplicata produz tráfego intermitente para o host errado, mais difícil de diagnosticar do que uma conexão recusada. Pergunte à tabela de rotas antes de adicionar uma regra.

No gateway, ip route get 192.168.2.17 deve nomear o dispositivo do túnel; uma bridge local significa que o intervalo remoto está obscurecido e nenhuma regra nat o conserta. Se a sua rede já usa 192.168.2.0/24, renumere o site remoto em vez de empilhar um mapeamento sobre a colisão.

Testar de um cliente real, e depois manter

Teste de uma máquina que realmente usará o alias, não do gateway, porque o tráfego gerado localmente nunca atravessa PREROUTING da mesma forma. Abra uma conexão para um host com alias e observe os contadores e a entrada conntrack aparecerem juntos, depois feche e confirme que a entrada some. Uma entrada obsoleta aponta para uma conexão meio aberta, o que geralmente significa que a resposta nunca voltou.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Duas ou três conexões bem-sucedidas provam a aritmética, mas não dizem nada sobre persistência ou sobre o próximo engenheiro. Salve as regras onde o processo de boot as lê, o que no Debian e no Ubuntu significa iptables-save > /etc/iptables/rules.v4 com netfilter-persistent habilitado. Um mapeamento que some no reboot é pior que nenhum, porque a interrupção chega sem nenhuma mudança recente para culpar.

Deixe uma nota ao lado das regras: o intervalo alias, o intervalo real, o motivo do par e qual lado pode iniciar. Essa nota separa um projeto de uma pilha de regras que ninguém ousa apagar. Ela também resolve a pergunta posterior, quando o site remoto adiciona um host e um endereço que ninguém configurou já responde. Se a nota disser que o lado remoto precisa de uma rota de volta, a próxima pessoa sabe que remover a regra de masquerade quebra a conectividade. Documentação é barata aqui; redescobrir uma dependência de NAT às três da manhã não é.