ASA identity NAT kontra IOS NAT-kivétel VPN-forgalomhoz

Egy fióktelep internetes PAT-ot és site-to-site VPN-t tart ugyanazon a Cisco-átjárón, és a VPN abban a pillanatban leáll, amikor NAT kerül be. A tunelen belüli címek már nem egyeznek azzal, amit a crypto ACL véd, vagy a partner olyan fordított címeket lát, amelyekhez nincs útvonala. A Cisco ezt két helyen oldja meg: az ASA olyan NAT-szabályt választ, amely a címet önmagára képezi le, míg az IOS ACL-deny segítségével tartja a folyamot a fordítási szabályon kívül. Mindkettő megőrzi az eredeti címeket, és egyik sem a NAT-feldolgozás megkerülése.

A szabály kiválasztása előtt rögzítse a folyamot

Kezdje annak a folyamnak a leírásával, amelyet védeni szeretne: helyi LAN-forrás, távoli cél és az a pontos címpár, amelyet az IPsec-szabályzat véd. Tegye ezt a szabály szerkesztése előtt, mert ez a sor megmutatja, melyik osztályozónak vagy NAT-szabálynak kellett volna egyeznie.

Ezután keresse meg a ténylegesen egyező szabályt, nem azt, amelyet szándékolt. Mindkét platformon a NAT-ot sorrendben értékelik, és egy korábbi szabály nyerhet, mielőtt a kivételét megnéznék. A helyesnek tűnő kivétel, amely alulmarad egy másik szabállyal szemben, soha nem adja át a várt csomagot a védelmi szabályzatnak. A tünet ugyanaz, mint a hiányzó kivételé, ezért a konfiguráció módosítása előtt el kell olvasni a szabályok sorrendjét.

Az ASA identity NAT szabály, nem megkerülés

Az ASA-n az identity NAT olyan NAT-szabály, amelynek fordított címe megegyezik az eredetivel. Úgy választják ki, mint bármely más szabályt, és továbbra is létrehoz egy fordítási bejegyzést, tehát a csomag nem hagyja ki a NAT-feldolgozást. Az változik, hogy a vezetéken a címek ugyanazok maradnak, és erre van szüksége az IPsec-szabályzatnak.

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

A szabály interfészeinek és route-lookup beállításának illeszkednie kell a továbbítási tervhez. Az a szabály, amely a címet helyesen képezi le, de rossz interfészpárra kerül, nem lesz kiválasztva a folyamához. A route-lookup dönti el, hogy a fordított csomagot továbbítják-e, vagy az eredeti célt használják, és ez határozza meg, hogy a visszatérő forgalom a tunelen keresztül jön-e vissza.

Maga az ASA felé irányuló kezelési hozzáférés külön eset. Ha identity NAT-ot használ a kezelési forgalomhoz, a kiadásfüggő route-lookup követelmény érvényes, és a VPN-példából másolt széles kivétel nem javítja meg az SSH-t.

Az IOS NAT ACL deny azt jelenti: itt nem kiválasztott

Az IOS-en az internetes NAT-ot forráslista vezérli, és az az ACL osztályozó, nem szűrő. A permit sor fordításhoz választ forgalmat; a deny sor azt jelenti, hogy a csomag itt nincs kiválasztva. Az a deny nem a csomag eldobásának utasítása, mint egy interfész ACL deny sora.

Az itt nem kiválasztott szűkebb annál is, hogy sehol nem fordítódik. Egy másik NAT-szabály, egy másik interfész vagy egy route-map még mindig fordíthatja a folyamot, ezért a teljes NAT-táblát el kell olvasni. A csomagnak továbbra is kell útvonal, egyező crypto ACL és engedély a tényleges hozzáférés-vezérlési határokon.

Egy minimális IOS-elrendezés a deny-t a permit fölé teszi ugyanabban a listában, és az overload szabályt erre a listára irányítja. Ekkor a crypto ACL ugyanazt a párt védi, amelyet a deny kizár a fordításból.

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

Egy tesztelhető kérdés mindkét modellhez

Mindkét modell ugyanarra a kérdésre válaszol: melyik szabály egyezett ezzel a folyammal, és mely címek hagyták el az interfészt? Rögzítsen a külső interfészen, és hasonlítsa össze a forráscímet az átjáró előtt és után. Ezután nézze meg, hogyan látja a partner a tunelt, mert az SA állhat, miközben a védett folyam máshol fordul.

Az ASA-n mutassa meg a nat detail és a fordítástáblát; az IOS-en az ip nat translations és a megfelelő ACL-számlálókat. Az a szabály, amely soha nem nő, soha nem volt kiválasztva, és ez a sorrendre, az interfészre vagy az irányra utal, nem a crypto konfigurációra.

Hol szokott elromlani a konfiguráció

A gyakori hibák mechanikusak. A deny a permit alatt van, és soha nem egyezik. Az osztályozó rossz irányban kerül alkalmazásra, ezért a visszatérő folyam fordítódik. Az identity szabály a helyes címeket, de a rossz interfészpárt fedi le. A crypto ACL olyan alhálózatot véd, amely már nem egyezik azzal, amit a NAT-szabály bemutat.

Rögzítse az eredeti és a bemutatott címpárt a szabály tulajdonosa mellett, hogy a következő mérnök lássa, miért tagadja meg az osztályozó a fordítást, miközben a tűzfal engedélyezi az alkalmazást. Tartsa ezt a változási jegyben, ne személyes feljegyzésben. Ezután minden NAT-módosítás után futtassa újra a folyamot, mert a szabályok sorrendje a konfiguráció része akkor is, ha a szabály szövege nem változott. A felálló tunel nem bizonyítja, hogy a címek túlélték; csak a rögzített csomag és a partner dekapszulálás utáni nézete.