ASA identity NAT kontra IOS NAT-undtagelse for VPN-trafik

En filial kører internet-PAT og en site-to-site VPN på samme Cisco-gateway, og VPN'et holder op med at virke i det øjeblik, NAT tilføjes. Adresserne inde i tunnelen matcher ikke længere det, crypto ACL'en beskytter, eller peer'en ser oversatte adresser, den ikke har nogen rute til. Cisco løser det to steder: ASA'en vælger en NAT-regel, der mapper en adresse til sig selv, mens IOS holder flowet uden for en oversættelsesregel via en deny i ACL'en. Begge bevarer de oprindelige adresser, og ingen af dem er en omgåelse af NAT-behandlingen.

Skriv flowet ned, før du vælger en regel

Begynd med at skrive det flow ned, du forventer at beskytte: LAN-kilden, fjernmålet og det præcise adressepar, som IPsec-politikken beskytter. Gør det, før du redigerer en regel, fordi tuplen viser, hvilken klassifikator eller NAT-regel der burde have matchet.

Find derefter den regel, der faktisk matchede, ikke den du havde tænkt på. På begge platforme evalueres NAT i en rækkefølge, og en tidligere regel kan vinde, før din undtagelse bliver set. En undtagelse, der ser rigtig ud, men taber til en anden regel, leverer aldrig det forventede paket til beskyttelsespolitikken. Symptomet er identisk med en manglende undtagelse, og derfor skal reglerækkefølgen læses, før konfigurationen ændres.

ASA identity NAT er en regel, ikke en omgåelse

På ASA'en er identity NAT en NAT-regel, hvis oversatte adresse er lig den oprindelige. Den vælges som enhver anden regel og installerer stadig en oversættelsespost, så pakken springer ikke NAT-behandlingen over. Det, der ændres, er, at adresserne på nettet forbliver de samme, og det er hvad IPsec-politikken har brug for.

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

Reglens interfaces og dens route-lookup-indstilling skal passe til forwarding-designet. En regel, der mapper adressen korrekt, men anvendes på det forkerte interface-par, bliver ikke valgt til dit flow. Route-lookup afgør, om den oversatte pakke routes, eller om den oprindelige destination bruges, og det afgør, om returtrafikken kommer tilbage gennem tunnelen.

Administrationsadgang til ASA'en selv er et særskilt tilfælde. Hvis du bruger identity NAT til administrationstrafik, gælder det versionsspecifikke route-lookup-krav, og en bred undtagelse kopieret fra et VPN-eksempel retter ikke SSH.

En deny i IOS NAT-ACL betyder ikke valgt her

På IOS styres internet-NAT af en kildeliste, og den ACL er en klassifikator, ikke et filter. En permit-linje vælger trafik til oversættelse; en deny-linje betyder, at pakken ikke er valgt her. Den deny er ikke en instruks om at droppe pakken, som en deny i en interface-ACL er.

Ikke valgt her er også snævrere end aldrig oversat nogen steder. En anden NAT-regel, et andet interface eller et route-map kan stadig oversætte flowet, så hele NAT-tabellen skal læses. Pakken skal også stadig have en rute, en matchende crypto ACL og tilladelse ved de faktiske adgangskontrolgrænser.

En minimal IOS-opsætning sætter deny over permit i samme liste og peger overload-reglen på den liste. Crypto ACL'en beskytter så det samme par, som deny'en udelukker fra oversættelse.

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

Et testbart spørgsmål for begge modeller

Begge modeller svarer på det samme spørgsmål: hvilken regel matchede dette flow, og hvilke adresser forlod interfacet? Fange på det ydre interface og sammenlign kildeadressen før og efter gatewayen. Kontrollér derefter peer'ens billede af tunnelen, fordi SA'en kan være oppe, mens det beskyttede flow oversættes et andet sted.

På ASA'en vises nat detail og oversættelsestabellen; på IOS vises ip nat translations og de matchende ACL-tællere. En regel, der aldrig tæller op, blev aldrig valgt, og det peger på rækkefølge, interface eller retning snarere end på crypto-konfigurationen.

Hvor konfigurationen som regel går galt

De typiske fejl er mekaniske. Deny'en står under permit og matcher aldrig. Klassifikatoren anvendes i den forkerte retning, så returflowet oversættes. Identity-reglen dækker de rigtige adresser, men det forkerte interface-par. Crypto ACL'en beskytter et subnet, der ikke længere matcher det, NAT-reglen præsenterer.

Noter det oprindelige og præsenterede adressepar ved siden af regelejeren, så den næste ingeniør kan se, hvorfor en klassifikator afviser oversættelse, mens firewalling tillader applikationen. Gem det i ændringssagen, ikke i en personlig note. Kør derefter flowet igen efter enhver NAT-ændring, fordi reglerækkefølgen er en del af konfigurationen, også når reglens tekst er uændret. En tunnel, der kommer op, er ikke bevis på, at adresserne overlevede; kun den opfangede pakke og peer'ens afkapslede billede er.