Qual interface recebe o NAT interno e externo numa saída VPN IOS

Os routers que fornecem uma saída de Internet por túnel completo desempenham duas funções que parecem uma só. Termina o túnel e encaminha o pacote de cliente desencriptado para a Internet. Só a segunda função precisa de tradução, e a tradução tem de corresponder ao fluxo interno. Essa distinção determina quais interfaces assumem as funções NAT e que intervalo de endereços aparece na regra.

Siga um pacote através do router

Considere um cliente em 10.90.0.25 a abrir um serviço HTTPS público. Se esse destino chega a entrar no túnel é uma decisão da política do próprio cliente. Quando entra, o router desencripta o pacote e entrega-o a uma interface virtual, de onde é encaminhado para o uplink público.

Essa interface virtual é o lado interno da tradução. O uplink público é o lado externo. Se as funções estiverem invertidas ou ausentes, o pacote sai com uma origem privada ou é descartado antes de ser traduzido.

Adapte a política de tradução ao pool de clientes

A regra NAT tem de indicar o intervalo que os clientes recebem de facto, não a LAN do escritório que por acaso partilha o uplink. Uma regra que abrange apenas a sub-rede local perde os clientes remotos mesmo quando ambos saem pela mesma interface.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Mantenha as exceções para sites privados à parte. O tráfego para destinos internos tem de conservar a sua origem original, caso contrário o destino responde para um endereço que não consegue alcançar e o percurso de retorno falha de uma forma que parece um ciclo de encaminhamento.

Aplique as funções às interfaces reais do projeto implementado. Um fragmento de Virtual-Template copiado de uma resposta antiga de Easy VPN não é uma configuração atual completa, e o tipo de túnel em uso determina que interface recebe o pacote desencriptado.

Mantenha o transporte externo e a tradução interna separados

Traduzir uma origem de aplicação desencriptada não é a mesma operação que empurrar pacotes IKE ou protegidos através de um dispositivo NAT a montante. A primeira altera o que a Internet vê como origem do pedido do cliente; a segunda mantém um túnel vivo através de um middlebox.

Confundi-las produz duas falhas clássicas. Um router que traduz o seu próprio transporte de túnel quebra a relação de par, enquanto um router que nunca traduz o fluxo interno encaminha endereços privados para a Internet. Leia qual fluxo está a observar antes de editar uma regra e verifique se o túnel se manteve ativo após a alteração. Uma regra que corrige a navegação mas derruba o túnel deslocou o problema em vez de o resolver.

Nenhuma das falhas se corrige alterando a outra. Leia qual fluxo está a observar antes de editar uma regra.

Verifique nas duas fronteiras

Leia a origem da aplicação na fronteira da Internet e o destino restaurado no percurso de retorno. A primeira diz se a tradução ocorreu; a segunda diz se o mapeamento inverso voltou ao cliente certo.

Depois teste um cliente que utilize um caminho de túnel dividido aprovado. Esse cliente nunca aciona a tradução de Internet deste router, por isso deve comportar-se de forma diferente, e a diferença confirma que caminho o tráfego seguiu.

Se ambos os clientes se comportarem de forma idêntica, a política de túnel dividido não está a fazer o que o projeto diz. Corrija isso antes de acrescentar mais regras de tradução, porque uma regra escrita para um caminho que não está em uso esconde o problema real.