ASA identity NAT mot IOS NAT-unntak for VPN-trafikk

Ei avdeling køyrer internett-PAT og ein site-to-site-VPN på same Cisco-gateway, og VPN-en sluttar å verke i det augeblikket NAT vert lagt til. Adressene inne i tunnelen samsvarar ikkje lenger med det crypto ACL-en vernar, eller motparten ser omsette adresser han ikkje har rute til. Cisco løyser dette på to stader: ASA-en vel ein NAT-regel som mappar ei adresse til seg sjølv, medan IOS held flyten utanfor ein omsetjingsregel via ein deny i ACL-en. Begge bevarar dei opphavlege adressene, og ingen av dei er ein omgåing av NAT-handsaminga.

Skriv ned flyten før du vel ein regel

Byrja med å skrive ned flyten du ventar å verne: LAN-kjelda, den eksterne destinasjonen og det nøyaktige adresseparet IPsec-policyen vernar. Gjer det før du redigerer ein regel, fordi tuppelen viser kva klassifiserar eller NAT-regel som skulle ha matcha.

Finn deretter regelen som faktisk matcha, ikkje den du hadde tenkt. På begge plattformer vert NAT vurdert i ein rekkjefølgje, og ein tidlegare regel kan vinne før unntaket ditt vert vurdert. Eit unntak som ser rett ut, men tapar mot ein annan regel, leverer aldri den venta pakka til vernepolicyen. Symtomet er identisk med eit manglande unntak, difor må reglerekkjefølgja lesast før konfigurasjonen vert endra.

ASA identity NAT er ein regel, ikkje ein omgåing

På ASA-en er identity NAT ein NAT-regel der den omsette adressa er lik den opphavlege. Han vert vald som ein kvar annan regel og installerer framleis ein omsetjingspost, så pakka hoppar ikkje over NAT-handsaminga. Det som endrar seg, er at adressene på tråden held seg like, og det er det IPsec-policyen treng.

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

Grensesnitta til regelen og route-lookup-innstillinga må samsvare med vidaresendingsdesignet. Ein regel som mappar adressa rett, men vert nytta på feil grensesnittpar, vert ikkje vald for flyten din. Route-lookup avgjer om den omsette pakka vert ruta eller om den opphavlege destinasjonen vert nytta, og det avgjer om returtrafikken kjem tilbake gjennom tunnelen.

Administrasjonstilgang til ASA-en sjølv er eit eige tilfelle. Viss du nyttar identity NAT for administrasjonstrafikk, gjeld det utgivingsspesifikke route-lookup-kravet, og eit breitt unntak kopiert frå eit VPN-døme rettar ikkje SSH.

Ein deny i IOS NAT-ACL betyr ikkje vald her

På IOS vert internett-NAT styrt av ei kjeldeliste, og den ACL-en er ein klassifiserar, ikkje eit filter. Ei permit-linje vel trafikk for omsetjing; ei deny-linje betyr at pakka ikkje er vald her. Den deny-en er ikkje ei pålegg om å kaste pakka slik ein deny i ein grensesnitt-ACL er.

Ikkje vald her er også smalare enn aldri omsett nokon stad. Ein annan NAT-regel, eit anna grensesnitt eller eit route-map kan framleis omsetje flyten, så heile NAT-tabellen må lesast. Pakka treng også framleis ei rute, ein samsvarande crypto ACL og løyve ved dei faktiske tilgangskontrollgrensene.

Eit minimalt IOS-oppsett legg deny over permit i same liste og peikar overload-regelen til den lista. Då vernar crypto ACL-en det same paret som deny-en utelukkar frå omsetjing.

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

Eitt testbart spørsmål for begge modellane

Begge modellane svarar på det same spørsmålet: kva regel matcha denne flyten, og kva adresser forlét grensesnittet? Ta opp på det ytre grensesnittet og samanlikn kjeldeadressa før og etter gatewayen. Sjekk deretter synet til motparten på tunnelen, fordi SA-en kan stå oppe medan den verna flyten vert omsett ein annan stad.

På ASA-en viser du nat detail og omsetjingstabellen; på IOS viser du ip nat translations og dei samsvarande ACL-teljarane. Ein regel som aldri aukar vart aldri vald, og det peikar på rekkjefølgje, grensesnitt eller retning snarare enn crypto-konfigurasjonen.

Kvar konfigurasjonen vanlegvis går gale

Dei vanlege feila er mekaniske. Deny-en står under permit og matchar aldri. Klassifiseraren vert nytta i feil retning, så returflyten vert omsett. Identity-regelen dekkjer dei rette adressene, men feil grensesnittpar. Crypto ACL-en vernar eit subnett som ikkje lenger samsvarar med det NAT-regelen presenterer.

Noter det opphavlege og presenterte adresseparet ved sida av regeleiaren, slik at neste ingeniør ser kvifor ein klassifiserar avslår omsetjing medan brannmuren tillèt applikasjonen. Oppbevar det i endringssaka, ikkje i ein personleg notat. Køyr deretter flyten på nytt etter kvar NAT-endring, fordi reglerekkjefølgja er ein del av konfigurasjonen sjølv når regelteksten er uendra. Ein tunnel som kjem opp er ikkje bevis på at adressene overlevde; berre den fanga pakka og den avkapsla visninga til motparten er det.