NAT d'identitat a l'ASA davant l'exclusió de NAT a IOS per al tràfic VPN

Una sucursal manté el PAT d'internet i una VPN de lloc a lloc a la mateixa passarel·la Cisco, i la VPN deixa de funcionar en el moment d'afegir NAT. Les adreces dins del túnel ja no coincideixen amb el que protegeix la crypto ACL, o l'extrem remot veu adreces traduïdes per a les quals no té ruta. Cisco ho resol en dos llocs: l'ASA selecciona una regla NAT que assigna una adreça a si mateixa, mentre que IOS manté el flux fora d'una regla de traducció mitjançant un deny de l'ACL. Tots dos conserven les adreces originals i cap dels dos no és una elusió del processament de NAT.

Registreu el flux abans de triar una regla

Comenceu escrivint el flux que espereu protegir: l'origen de la LAN, la destinació remota i el parell d'adreces exacte que protegeix la política IPsec. Feu-ho abans d'editar cap regla, perquè la tupla indica quin classificador o quina regla NAT hauria d'haver coincidit.

Després trobeu la regla que realment ha coincidit, no la que volíeu que coincidís. A les dues plataformes el NAT s'avalua en un ordre, i una regla anterior pot guanyar abans que es consulti la vostra excepció. Una exempció que sembla correcta però perd contra una altra regla no lliura mai el paquet esperat a la política de protecció. El símptoma és idèntic al d'una exempció absent, i per això cal llegir l'ordre de les regles abans de canviar la configuració.

El NAT d'identitat de l'ASA és una regla, no una elusió

A l'ASA, el NAT d'identitat és una regla NAT l'adreça traduïda de la qual és igual a l'original. Es selecciona com qualsevol altra regla i encara instal·la una entrada de traducció, així que el paquet no s'estalvia el processament de NAT. El que canvia és que les adreces al cable es mantenen iguals, i això és el que necessita la política IPsec.

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

Les interfícies de la regla i la seva opció route-lookup han de coincidir amb el disseny de reenviament. Una regla que assigna l'adreça correctament però s'aplica a un parell d'interfícies equivocat no se seleccionarà per al vostre flux. Route-lookup decideix si el paquet traduït s'encamina o s'utilitza la destinació original, i això determina si el tràfic de retorn torna pel túnel.

L'accés de gestió a l'ASA és un cas a part. Si feu servir NAT d'identitat per al tràfic de gestió, s'aplica el requisit de route-lookup específic de la versió, i una excepció àmplia copiada d'un exemple de VPN no arreglarà l'SSH.

Un deny de l'ACL NAT a IOS vol dir que aquí no se selecciona

A IOS, el NAT d'internet es regeix per una llista d'orígens, i aquesta ACL és un classificador, no un filtre. Una línia permit selecciona tràfic per traduir; una línia deny vol dir que el paquet aquí no se selecciona. Aquest deny no és una ordre de descartar el paquet com ho és un deny en una ACL d'interfície.

Que aquí no se seleccioni també és més estret que que no es tradueixi enlloc. Una altra regla NAT, una altra interfície o un route-map poden traduir encara el flux, així que cal llegir tota la taula NAT. El paquet també necessita una ruta, una crypto ACL que hi coincideixi i permís a les fronteres reals de control d'accés.

Una disposició mínima a IOS posa el deny per sobre del permit a la mateixa llista i apunta la regla overload a aquesta llista. Llavors la crypto ACL protegeix el mateix parell que el deny exclou de la traducció.

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

Una pregunta comprovable per als dos models

Els dos models responen la mateixa pregunta: quina regla ha coincidit amb aquest flux i quines adreces han sortit de la interfície? Captureu a la interfície externa i compareu l'adreça d'origen abans i després de la passarel·la. Després mireu com veu l'extrem remot el túnel, perquè l'SA pot estar aixecada mentre el flux protegit es tradueix en un altre lloc.

A l'ASA mostreu nat detail i la taula de traducció; a IOS mostreu ip nat translations i els comptadors de l'ACL corresponent. Una regla que no incrementa mai no s'ha seleccionat mai, i això apunta a l'ordre, la interfície o la direcció més que a la configuració de crypto.

On sol fallar la configuració

Les fallades habituals són mecàniques. El deny és sota el permit i no coincideix mai. El classificador s'aplica en la direcció equivocada, així que es tradueix el flux de retorn. La regla d'identitat cobreix les adreces correctes però el parell d'interfícies equivocat. La crypto ACL protegeix una subxarxa que ja no coincideix amb el que presenta la regla NAT.

Registreu el parell d'adreces original i presentat al costat del propietari de la regla, perquè el següent enginyer vegi per què un classificador denega la traducció mentre el firewall permet l'aplicació. Guardeu-ho al tiquet de canvi, no en una nota personal. Després torneu a executar el flux després de qualsevol canvi de NAT, perquè l'ordre de les regles forma part de la configuració encara que el text de la regla no canviï. Un túnel que s'aixeca no demostra que les adreces hagin sobreviscut; només ho fan el paquet capturat i la visió desencapsulada de l'extrem remot.