NAT de identidade no ASA versus exclusão de NAT no IOS para tráfego VPN

Uma filial mantém PAT de internet e uma VPN site-to-site no mesmo gateway Cisco, e a VPN deixa de funcionar no momento em que se adiciona NAT. Os endereços dentro do túnel já não coincidem com o que a crypto ACL protege, ou o par vê endereços traduzidos para os quais não tem rota. A Cisco resolve isto em dois lugares: o ASA seleciona uma regra NAT que mapeia um endereço para si mesmo, enquanto o IOS mantém o fluxo fora de uma regra de tradução através de um deny na ACL. Ambos preservam os endereços originais, e nenhum é uma evasão do processamento de NAT.

Registe o fluxo antes de escolher uma regra

Comece por escrever o fluxo que espera proteger: a origem da LAN, o destino remoto e o par exato de endereços que a política IPsec protege. Faça-o antes de editar uma regra, porque a tupla indica qual classificador ou regra NAT deveria ter coincidido.

Depois encontre a regra que realmente coincidiu, não a que pretendia. Em ambas as plataformas o NAT é avaliado numa ordem, e uma regra anterior pode vencer antes de a sua exceção ser consultada. Uma exceção que parece correta mas perde para outra regra nunca entrega o pacote esperado à política de proteção. O sintoma é idêntico ao de uma exceção em falta, por isso a ordem das regras tem de ser lida antes de alterar a configuração.

O NAT de identidade no ASA é uma regra, não uma evasão

No ASA, o NAT de identidade é uma regra NAT cujo endereço traduzido é igual ao original. É selecionada como qualquer outra regra e continua a instalar uma entrada de tradução, pelo que o pacote não salta o processamento de NAT. O que muda é que os endereços no cabo permanecem os mesmos, e é disso que a política IPsec precisa.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

As interfaces da regra e a sua definição route-lookup têm de corresponder ao desenho de encaminhamento. Uma regra que mapeia o endereço corretamente mas é aplicada ao par de interfaces errado não será selecionada para o seu fluxo. O route-lookup decide se o pacote traduzido é encaminhado ou se é usado o destino original, e isso determina se o tráfego de retorno regressa pelo túnel.

O acesso de gestão ao próprio ASA é um caso separado. Se usar NAT de identidade para tráfego de gestão, aplica-se o requisito route-lookup específico da versão, e uma exceção ampla copiada de um exemplo de VPN não corrige o SSH.

Um deny na ACL NAT do IOS significa não selecionado aqui

No IOS, o NAT de internet é conduzido por uma lista de origem, e essa ACL é um classificador, não um filtro. Uma linha permit seleciona tráfego para tradução; uma linha deny significa que o pacote não é selecionado aqui. Esse deny não é uma ordem para descartar o pacote como é um deny numa ACL de interface.

Não selecionado aqui também é mais estreito do que nunca traduzido em lado nenhum. Outra regra NAT, outra interface ou um route-map ainda podem traduzir o fluxo, por isso a tabela NAT completa tem de ser lida. O pacote também continua a precisar de rota, de uma crypto ACL correspondente e de permissão nos limites reais de controlo de acesso.

Uma disposição mínima no IOS coloca o deny acima do permit na mesma lista e aponta a regra overload para essa lista. Então a crypto ACL protege o mesmo par que o deny exclui da tradução.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Uma pergunta testável para ambos os modelos

Ambos os modelos respondem à mesma pergunta: que regra coincidiu com este fluxo e que endereços saíram da interface? Capture na interface externa e compare o endereço de origem antes e depois do gateway. Depois verifique a visão do par sobre o túnel, porque a SA pode estar levantada enquanto o fluxo protegido é traduzido noutro lugar.

No ASA mostre nat detail e a tabela de tradução; no IOS mostre ip nat translations e os contadores da ACL correspondente. Uma regra que nunca incrementa nunca foi selecionada, e isso aponta para a ordem, a interface ou a direção e não para a configuração de crypto.

Onde a configuração costuma falhar

As falhas comuns são mecânicas. O deny está abaixo do permit e nunca coincide. O classificador é aplicado na direção errada, pelo que o fluxo de retorno é traduzido. A regra de identidade cobre os endereços certos mas o par de interfaces errado. A crypto ACL protege uma sub-rede que já não corresponde ao que a regra NAT apresenta.

Registe o par de endereços original e apresentado junto do responsável pela regra, para que o próximo engenheiro veja porque um classificador recusa a tradução enquanto a firewall permite a aplicação. Guarde isso no ticket de mudança, não numa nota pessoal. Depois volte a executar o fluxo após qualquer alteração de NAT, porque a ordem das regras faz parte da configuração mesmo quando o texto da regra não muda. Um túnel que sobe não prova que os endereços sobreviveram; só o pacote capturado e a visão desencapsulada do par o provam.