ASA identiteedi-NAT versus IOS-i NAT-i erand VPN-liiklusele

Cisco lüüsides säilitavad VPN-aadressid nii ASA identiteedi-NAT kui ka IOS-i NAT-klassifitseerija erand. Reeglid erinevad selle poolest, kus tõlge vahele jääb.

Haru hoiab interneti-PAT-i ja saidi-vahelise VPN-i samas Cisco lüüsis ning VPN lakkab töötamast hetkel, kui NAT lisatakse. Tunnelis olevad aadressid ei vasta enam sellele, mida kaitseb crypto ACL, või vastaspool näeb tõlgitud aadresse, mille jaoks tal marsruuti pole. Cisco lahendab selle kahes kohas: ASA valib NAT-reegli, mis vastendab aadressi iseendaga, samas kui IOS hoiab voo ACL-i deny abil tõlkereeglist väljas. Mõlemad säilitavad algsed aadressid ja kumbki ei ole NAT-i töötlemise möödaminek.

Kirjuta voog üles enne reegli valimist

Alusta voo üleskirjutamisest, mida kavatsed kaitsta: kohaliku LAN-i allikas, kaugsihtkoht ja täpne aadressipaar, mida IPsec-poliitika kaitseb. Tee seda enne reegli muutmist, sest see korteež näitab, milline klassifitseerija või NAT-reegel oleks pidanud sobima.

Seejärel leia reegel, mis tegelikult sobis, mitte see, mida kavatsesid. Mõlemal platvormil hinnatakse NAT-i kindlas järjekorras ja varasem reegel võib võita enne, kui sinu erandit vaadatakse. Õigena näiv erand, mis kaotab teisele reeglile, ei anna kunagi oodatud paketti kaitsepoliitikale. Sümptom on sama nagu puuduva erandi puhul, seetõttu tuleb enne konfiguratsiooni muutmist lugeda reeglite järjekorda.

ASA identiteedi-NAT on reegel, mitte möödaminek

ASA-s on identiteedi-NAT NAT-reegel, mille tõlgitud aadress võrdub algsega. Seda valitakse nagu iga teist reeglit ja see paigaldab endiselt tõlke kirje, seega pakett ei jäta NAT-i töötlemist vahele. Muutub see, et aadressid juhtmel jäävad samaks, ja just seda IPsec-poliitika vajab.

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

Reegli liidesed ja selle route-lookup seade peavad vastama edastuskavale. Reegel, mis vastendab aadressi õigesti, kuid rakendatakse vale liidesepaari külge, ei valita sinu voo jaoks. Route-lookup otsustab, kas tõlgitud pakett marsruuditakse või kasutatakse algset sihtkohta, ja see määrab, kas tagasitulev liiklus tuleb tunnelist tagasi.

Haldusjuurdepääs ASA-le endale on eraldi juhtum. Kui kasutad identiteedi-NAT-i haldusliikluse jaoks, kehtib versioonipõhine route-lookup nõue, ja VPN-i näitest kopeeritud lai erand SSH-d ei paranda.

IOS-i NAT-ACL-i deny tähendab siin ei valita

IOS-is juhitakse interneti-NAT-i allikaloendiga ja see ACL on klassifitseerija, mitte filter. Permit-rida valib liikluse tõlkimiseks; deny-rida tähendab, et paketti siin ei valita. See deny ei ole käsk pakett maha visata, nagu deny liidese ACL-is.

Siin ei valita on ka kitsam kui mitte kunagi kusagil tõlgitud. Teine NAT-reegel, teine liides või route-map võivad voo ikkagi tõlkida, seega tuleb lugeda kogu NAT-tabelit. Pakett vajab endiselt marsruuti, sobivat crypto ACL-i ja luba tegelikel juurdepääsukontrolli piiridel.

Minimaalne IOS-i lahendus paneb deny permit-i kohale samas loendis ja suunab overload-reegli sellele loendile. Siis kaitseb crypto ACL sama paari, mille deny tõlkest välja jätab.

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

Üks testitav küsimus mõlema mudeli jaoks

Mõlemad mudelid vastavad samale küsimusele: milline reegel selle vooga sobis ja millised aadressid liidesest lahkusid? Püüa välisliidesel ja võrdle allikaaadressi enne ja pärast lüüsi. Seejärel kontrolli vastaspoole vaadet tunnelile, sest SA võib olla üleval, samal ajal kui kaitstud voog tõlgitakse mujal.

ASA-s näita nat detail ja tõlketabelit; IOS-is näita ip nat translations ja vastavaid ACL-loendureid. Reegel, mis kunagi ei suurene, ei olnud kunagi valitud, ja see viitab järjekorrale, liidesele või suunale, mitte crypto konfiguratsioonile.

Kus konfiguratsioon tavaliselt valesti läheb

Levinud tõrked on mehaanilised. Deny asub permit-i all ja ei sobi kunagi. Klassifitseerija rakendatakse vales suunas, seega tagasivoog tõlgitakse. Identiteedireegel katab õiged aadressid, kuid vale liidesepaari. Crypto ACL kaitseb alavõrku, mis ei vasta enam sellele, mida NAT-reegel esitab.

Kirjuta algne ja esitatud aadressipaar reegli omaniku kõrvale, et järgmine insener näeks, miks klassifitseerija keeldub tõlkest, samal ajal kui tulemüür lubab rakendust. Hoia seda muudatuse piletil, mitte isiklikus märkmes. Seejärel käivita voog uuesti pärast iga NAT-i muudatust, sest reeglite järjekord on konfiguratsiooni osa ka siis, kui reegli tekst on muutumatu. Üles tõusev tunnel ei tõesta, et aadressid püsisid; seda tõestavad ainult püütud pakett ja vastaspoole dekapsuleeritud vaade.

Seotud artiklid