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

En filial kjører internett-PAT og en site-to-site-VPN på samme Cisco-gateway, og VPN-en slutter å virke i det øyeblikket NAT legges til. Adressene inne i tunnelen samsvarer ikke lenger med det crypto ACL-en beskytter, eller peer-en ser oversatte adresser den ikke har rute til. Cisco løser dette to steder: ASA-en velger en NAT-regel som mapper en adresse til seg selv, mens IOS holder flyten utenfor en oversettelsesregel via en deny i ACL-en. Begge bevarer de opprinnelige adressene, og ingen av dem er en omgåelse av NAT-behandlingen.

Skriv ned flyten før du velger en regel

Begynn med å skrive ned flyten du forventer å beskytte: LAN-kilden, den eksterne destinasjonen og det nøyaktige adresseparet IPsec-policyen beskytter. Gjør det før du redigerer en regel, fordi tuppelen viser hvilken klassifiserer eller NAT-regel som skulle ha matchet.

Finn deretter regelen som faktisk matchet, ikke den du hadde tenkt. På begge plattformer evalueres NAT i en rekkefølge, og en tidligere regel kan vinne før unntaket ditt blir vurdert. Et unntak som ser riktig ut, men taper mot en annen regel, leverer aldri den forventede pakken til beskyttelsespolicyen. Symptomet er identisk med et manglende unntak, derfor må reglerekkefølgen leses før konfigurasjonen endres.

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

På ASA-en er identity NAT en NAT-regel der den oversatte adressen er lik den opprinnelige. Den velges som enhver annen regel og installerer fortsatt en oversettelsesoppføring, så pakken hopper ikke over NAT-behandlingen. Det som endres, er at adressene på tråden forblir de samme, og det er det IPsec-policyen trenger.

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

Regelens grensesnitt og route-lookup-innstillingen må samsvare med videresendingsdesignet. En regel som mapper adressen riktig, men brukes på feil grensesnittpar, blir ikke valgt for flyten din. Route-lookup avgjør om den oversatte pakken rutes eller om den opprinnelige destinasjonen brukes, og det avgjør om returtrafikken kommer tilbake gjennom tunnelen.

Administrasjonstilgang til ASA-en selv er et eget tilfelle. Hvis du bruker identity NAT for administrasjonstrafikk, gjelder det utgivelsesspesifikke route-lookup-kravet, og et bredt unntak kopiert fra et VPN-eksempel retter ikke SSH.

En deny i IOS NAT-ACL betyr ikke valgt her

På IOS styres internett-NAT av en kildeliste, og den ACL-en er en klassifiserer, ikke et filter. En permit-linje velger trafikk for oversettelse; en deny-linje betyr at pakken ikke er valgt her. Den deny-en er ikke en instruks om å forkaste pakken slik en deny i en grensesnitt-ACL er.

Ikke valgt her er også smalere enn aldri oversatt noe sted. En annen NAT-regel, et annet grensesnitt eller et route-map kan fortsatt oversette flyten, så hele NAT-tabellen må leses. Pakken trenger også fortsatt en rute, en samsvarende crypto ACL og tillatelse ved de faktiske tilgangskontrollgrensene.

En minimal IOS-oppsett legger deny over permit i samme liste og peker overload-regelen til den listen. Da beskytter crypto ACL-en det samme paret som deny-en utelukker fra oversettelse.

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

Ett testbart spørsmål for begge modellene

Begge modellene svarer på det samme spørsmålet: hvilken regel matchet denne flyten, og hvilke adresser forlot grensesnittet? Ta opp på det ytre grensesnittet og sammenlign kildeadressen før og etter gatewayen. Sjekk deretter peer-ens syn på tunnelen, fordi SA-en kan være oppe mens den beskyttede flyten oversettes et annet sted.

På ASA-en viser du nat detail og oversettelsestabellen; på IOS viser du ip nat translations og de samsvarende ACL-tellerne. En regel som aldri øker ble aldri valgt, og det peker på rekkefølge, grensesnitt eller retning snarere enn crypto-konfigurasjonen.

Hvor konfigurasjonen vanligvis går galt

De vanlige feilene er mekaniske. Deny-en står under permit og matcher aldri. Klassifisereren brukes i feil retning, så returflyten oversettes. Identity-regelen dekker de riktige adressene, men feil grensesnittpar. Crypto ACL-en beskytter et subnett som ikke lenger samsvarer med det NAT-regelen presenterer.

Noter det opprinnelige og presenterte adresseparet ved siden av regeleieren, slik at neste ingeniør ser hvorfor en klassifiserer avslår oversettelse mens brannmuren tillater applikasjonen. Oppbevar det i endringssaken, ikke i en personlig notat. Kjør deretter flyten på nytt etter enhver NAT-endring, fordi reglerekkefølgen er en del av konfigurasjonen selv når regelteksten er uendret. En tunnel som kommer opp er ikke bevis på at adressene overlevde; bare den fangede pakken og peer-ens avkapslede visning er det.