NAT de identidade en ASA fronte á exclusión de NAT en IOS para o tráfico VPN

Unha sucursal mantén PAT de internet e unha VPN de sitio a sitio na mesma pasarela Cisco, e a VPN deixa de funcionar no momento en que se engade NAT. Os enderezos dentro do túnel xa non coinciden co que protexe a crypto ACL, ou o par ve enderezos traducidos para os que non ten ruta. Cisco resólveo en dous lugares: o ASA selecciona unha regra NAT que asigna un enderezo a si mesmo, mentres que IOS mantén o fluxo fóra dunha regra de tradución mediante un deny na ACL. Ambos conservan os enderezos orixinais e ningún é unha elusión do procesamento de NAT.

Rexistre o fluxo antes de escoller unha regra

Comece escribindo o fluxo que espera protexer: a orixe da LAN, o destino remoto e o par exacto de enderezos que protexe a política IPsec. Fágao antes de editar unha regra, porque a tupla indica que clasificador ou regra NAT debería ter coincidido.

Despois busque a regra que realmente coincidiu, non a que pretendía. En ambas as plataformas o NAT avalíase nunha orde, e unha regra anterior pode gañar antes de que se consulte a súa excepción. Unha excepción que parece correcta pero perde fronte a outra regra nunca entrega o paquete esperado á política de protección. O síntoma é idéntico ao dunha excepción ausente, por iso hai que ler a orde das regras antes de cambiar a configuración.

O NAT de identidade en ASA é unha regra, non unha elusión

No ASA, o NAT de identidade é unha regra NAT cuxo enderezo traducido é igual ao orixinal. Selecciónase como calquera outra regra e segue instalando unha entrada de tradución, así que o paquete non se salta o procesamento de NAT. O que cambia é que os enderezos no cable seguen sendo os mesmos, e iso é o que necesita a política IPsec.

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

As interfaces da regra e o seu axuste route-lookup deben coincidir co deseño de reenvío. Unha regra que asigna o enderezo correctamente pero se aplica ao par de interfaces equivocado non se seleccionará para o seu fluxo. Route-lookup decide se o paquete traducido se encamiña ou se usa o destino orixinal, e iso determina se o tráfico de retorno volve polo túnel.

O acceso de xestión ao propio ASA é un caso aparte. Se usa NAT de identidade para o tráfico de xestión, aplícase o requisito de route-lookup específico da versión, e unha excepción ampla copiada dun exemplo de VPN non arranxará SSH.

Un deny na ACL NAT de IOS significa non seleccionado aquí

En IOS, o NAT de internet réxese por unha lista de orixe, e esa ACL é un clasificador, non un filtro. Unha liña permit selecciona tráfico para a tradución; unha liña deny significa que o paquete non se selecciona aquí. Ese deny non é unha orde de descartar o paquete como o é un deny nunha ACL de interface.

Non seleccionado aquí tamén é máis estreito que nunca traducido en ningún sitio. Outra regra NAT, outra interface ou un route-map aínda poden traducir o fluxo, así que hai que ler toda a táboa NAT. O paquete tamén necesita unha ruta, unha crypto ACL que coincida e permiso nos límites reais de control de acceso.

Unha disposición mínima en IOS coloca o deny por riba do permit na mesma lista e apunta a regra overload a esa lista. Entón a crypto ACL protexe o mesmo par que o deny exclúe da tradución.

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

Unha pregunta comprobable para ambos os modelos

Ambos os modelos responden á mesma pregunta: que regra coincidiu con este fluxo e que enderezos saíron da interface? Capture na interface externa e compare o enderezo de orixe antes e despois da pasarela. Logo revise a visión do par sobre o túnel, porque a SA pode estar levantada mentres o fluxo protexido se traduce noutro lugar.

No ASA mostre nat detail e a táboa de tradución; en IOS mostre ip nat translations e os contadores da ACL correspondente. Unha regra que nunca incrementa nunca foi seleccionada, e iso apunta á orde, á interface ou á dirección máis que á configuración de crypto.

Onde adoita fallar a configuración

Os fallos habituais son mecánicos. O deny está debaixo do permit e nunca coincide. O clasificador aplícase na dirección equivocada, así que se traduce o fluxo de retorno. A regra de identidade cobre os enderezos correctos pero o par de interfaces equivocado. A crypto ACL protexe unha subrede que xa non coincide co que presenta a regra NAT.

Rexistre o par de enderezos orixinal e presentado xunto ao propietario da regra, para que o seguinte enxeñeiro vexa por que un clasificador denega a tradución mentres a devasa permite a aplicación. Gárdeo no tícket de cambio, non nunha nota persoal. Despois volva executar o fluxo tras calquera cambio de NAT, porque a orde das regras forma parte da configuración aínda que o texto da regra non cambie. Un túnel que sobe non demostra que os enderezos sobrevivisen; só o fan o paquete capturado e a visión desencapsulada do par.