ASA identity NAT kontra IOS NAT-undantag för VPN-trafik

En filial kör internet-PAT och en site-to-site-VPN på samma Cisco-gateway, och VPN slutar fungera i samma stund som NAT läggs till. Adresserna i tunneln matchar inte längre det crypto ACL skyddar, eller peer ser översatta adresser som den saknar route till. Cisco löser detta på två ställen: ASA väljer en NAT-regel som mappar en adress till sig själv, medan IOS håller flödet utanför en översättningsregel via en deny i ACL. Båda bevarar originaladresserna, och ingen av dem är en kringgång av NAT-behandlingen.

Skriv ned flödet innan du väljer en regel

Börja med att skriva ned flödet du förväntar dig att skydda: LAN-källan, fjärrmålet och det exakta adressparet som IPsec-policyn skyddar. Gör det innan du redigerar en regel, eftersom tupeln visar vilken klassificerare eller NAT-regel som borde ha matchat.

Hitta sedan regeln som faktiskt matchade, inte den du avsåg. På båda plattformarna utvärderas NAT i en ordning, och en tidigare regel kan vinna innan ditt undantag beaktas. Ett undantag som ser korrekt ut men förlorar mot en annan regel levererar aldrig det förväntade paketet till skyddspolicyn. Symtomet är identiskt med ett saknat undantag, därför måste regelordningen läsas innan konfigurationen ändras.

ASA identity NAT är en regel, inte en kringgång

På ASA är identity NAT en NAT-regel vars översatta adress är lika med originalet. Den väljs som vilken annan regel som helst och installerar fortfarande en översättningspost, så paketet hoppar inte över NAT-behandlingen. Det som ändras är att adresserna på tråden förblir desamma, och det är vad IPsec-policyn behöver.

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

Regelns gränssnitt och dess route-lookup-inställning måste stämma med vidarebefordringsdesignen. En regel som mappar adressen korrekt men tillämpas på fel gränssnittspar väljs inte för ditt flöde. Route-lookup avgör om det översatta paketet routas eller om originaldestinationen används, och det avgör om returtrafiken kommer tillbaka genom tunneln.

Administrativ åtkomst till själva ASA är ett eget fall. Om du använder identity NAT för administrationstrafik gäller det utgivningsspecifika route-lookup-kravet, och ett brett undantag kopierat från ett VPN-exempel lagar inte SSH.

En deny i IOS NAT-ACL betyder inte vald här

På IOS styrs internet-NAT av en källista, och den ACL:n är en klassificerare, inte ett filter. En permit-rad väljer trafik för översättning; en deny-rad betyder att paketet inte är valt här. Den deny:n är inte en instruktion att kasta paketet som en deny i en gränssnitts-ACL.

Inte vald här är också snävare än aldrig översatt någonstans. En annan NAT-regel, ett annat gränssnitt eller en route-map kan fortfarande översätta flödet, så hela NAT-tabellen måste läsas. Paketet behöver fortfarande en route, en matchande crypto ACL och tillstånd vid de faktiska åtkomstkontrollgränserna.

En minimal IOS-uppsättning sätter deny ovanför permit i samma lista och pekar overload-regeln mot den listan. Då skyddar crypto ACL samma par som deny utesluter från översättning.

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

En testbar fråga för båda modellerna

Båda modellerna svarar på samma fråga: vilken regel matchade detta flöde, och vilka adresser lämnade gränssnittet? Fånga på det yttre gränssnittet och jämför källadressen före och efter gatewayen. Kontrollera sedan peerns bild av tunneln, eftersom SA kan vara uppe medan det skyddade flödet översätts någon annanstans.

På ASA visar du nat detail och översättningstabellen; på IOS visar du ip nat translations och motsvarande ACL-räknare. En regel som aldrig ökar valdes aldrig, och det pekar på ordning, gränssnitt eller riktning snarare än crypto-konfigurationen.

Var konfigurationen brukar gå fel

De vanliga felen är mekaniska. Deny:n står under permit och matchar aldrig. Klassificeraren tillämpas i fel riktning, så returflödet översätts. Identity-regeln täcker rätt adresser men fel gränssnittspar. Crypto ACL skyddar ett subnät som inte längre stämmer med det NAT-regeln presenterar.

Anteckna det ursprungliga och det presenterade adressparet bredvid regelägaren, så att nästa ingenjör ser varför en klassificerare nekar översättning medan brandväggen tillåter applikationen. Förvara det i ändringsärendet, inte i en personlig anteckning. Kör sedan flödet igen efter varje NAT-ändring, eftersom regelordningen är en del av konfigurationen även när regeltexten är oförändrad. En tunnel som kommer upp är inte bevis för att adresserna överlevde; bara det fångade paketet och peerns avkapslade vy är det.