Quando o NAT dentro de uma VPN site a site conquista o seu lugar

Dois sites usam o mesmo intervalo privado, e o túnel sobe enquanto nada útil o atravessa. A tradução é a resposta habitual, e é uma resposta real: apresentar um intervalo diferente ao lado remoto pode resolver uma sobreposição ou um caminho de retorno que a outra rede não consegue encaminhar. A parte que se salta é que a tradução muda os endereços que cada decisão posterior vê. Trate-a como uma decisão de design documentada com um mapeamento escrito, não como uma regra adicionada até um ping ter sucesso.

Decida qual endereço é reescrito

A tradução de origem muda o que o serviço remoto e os seus registos veem como cliente, pelo que um host de sucursal se torna um endereço de gateway à chegada. A tradução de destino ou de prefixo apresenta, em vez disso, um endereço alternativo para um recurso remoto. Algumas implementações precisam de tradução coordenada nos dois lados para separar duas redes de outro modo idênticas, e é na combinação que começa a maior parte da confusão.

Anote a origem antes da tradução, o destino como a aplicação o nomeia e o par de endereços com que cada gateway corresponde. Três colunas bastam, e a terceira coluna é a que as pessoas omitem.

A ordem dos seletores também importa. A seleção e a tradução de políticas IPsec ocorrem em fases definidas, pelo que um seletor escrito para endereços anteriores à tradução pode nunca corresponder ao pacote na fase que assumiu. Verifique a política instalada em vez da política que pretendia instalar, porque as duas divergem exatamente quando uma regra é aceite por um componente e ignorada por outro:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Siga o payload e o caminho de retorno

Um servidor que registe a origem traduzida em vez do host de sucursal individual vai quebrar qualquer regra ou relatório ligado ao endereço original. Antes de mudar o mapeamento, descubra se algo a jusante toma uma decisão a partir desse campo: listas de acesso, relatórios de auditoria, limites de velocidade, verificações de licença. Cada um deles é um ponto onde a tradução aparece mais tarde como uma falha inexplicada.

Os protocolos que transportam endereços dentro do payload precisam de planeamento separado, porque reescrever o cabeçalho externo não toca na referência interna. FTP ativo, SIP e alguns produtos de acesso remoto são os casos clássicos, e um design que os ignore funcionará para o tráfego web e falhará para a aplicação que importava.

O tráfego de retorno depende de mapeamentos com estado. A comutação por falha do gateway pode perder esse estado, o encaminhamento assimétrico pode contorná-lo e um reinício pode apagá-lo enquanto as sessões permanecem abertas no lado remoto. É por isso que um pedido que chega ao destino e uma sessão que se completa são dois resultados de aceitação diferentes.

Pese isto face à renumeração de um site

Renumerar um site em conflito remove o mapeamento por completo e deixa um plano de endereços que pode ser lido sem tabelas de tradução. É caro operacionalmente: os registos DNS, as atribuições estáticas, as regras da firewall e cada endereço documentado têm de mudar em conjunto. O custo chega uma vez, numa janela planeada, com um estado final claro. O que compra é a capacidade de ler uma captura de pacotes anos depois sem uma tabela de consulta.

A tradução evita a maioria das alterações locais e cria um mapeamento que tem de ser mantido em DNS, documentação e resolução de problemas para sempre. O custo chega continuamente, sob a forma de cada futuro engenheiro que tem de aprender que um prefixo significa outra coisa dentro do túnel.

Para uma ligação temporária ou uma rede de parceiro que não controla, o custo contínuo costuma valer a pena. Para dois sites que possui e possuirá durante anos, a renumeração é muitas vezes a decisão mais barata quando a migração é contada com honestidade.

Prove ambos os sentidos com uma sessão real

Teste uma sessão de aplicação em vez de uma sonda única. Um pedido de eco bem-sucedido prova que um sentido de um protocolo funciona, e é totalmente compatível com um caminho de retorno que falha para tudo o que tem estado. Use o serviço que motivou o design e leia o seu registo no extremo remoto para ver que endereço de origem registou.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Depois confirme que apenas os serviços previstos são alcançáveis através do mapeamento. A tradução muda o endereçamento e não faz nada pela autorização, pelo que a política da firewall continua a decidir o que é permitido. Um design que se apoia num prefixo traduzido obscuro como controlo de acesso não tem controlo de acesso nenhum.

Registe o mapeamento, a sessão testada e os endereços que cada lado observou. A próxima pessoa que depurar este túnel precisa desses três factos mais do que do ficheiro de configuração.