Identity NAT на ASA наспрам изузетка NAT на IOS за VPN саобраћај

На Cisco гејтвејима и identity NAT на ASA и изузетак NAT класификатора на IOS чувају VPN адресе. Правила се разликују по томе где се превод прескаче.

Огранак држи интернет PAT и site-to-site VPN на истом Cisco гејтвеју, а VPN престаје да ради оног тренутка када се дода NAT. Адресе унутар тунела више се не поклапају са оним што штити crypto ACL, или друга страна види преведене адресе за које нема руту. Cisco то решава на два места: ASA бира NAT правило које адресу пресликава на њу саму, док IOS држи ток изван правила превода помоћу deny у ACL-у. Оба чувају оригиналне адресе и ниједно није заобилажење NAT обраде.

Забележите ток пре избора правила

Почните тако што ћете записати ток који намеравате да штитите: изворну LAN адресу, удаљено одредиште и тачан пар адреса који штити IPsec политика. Урадите то пре уређивања правила, јер тај скуп показује који је класификатор или NAT правило требало да се поклопи.

Затим пронађите правило које се стварно поклопило, а не оно које сте намеравали. На обе платформе NAT се оцењује по реду и раније правило може да победи пре него што се ваш изузетак размотри. Изузетак који изгледа исправно али изгуби од другог правила никада не предаје очекивани пакет политици заштите. Симптом је исти као код изузетка који недостаје, зато се ред правила мора прочитати пре промене конфигурације.

Identity NAT на ASA је правило, а не заобилажење

На ASA identity NAT је NAT правило чија је преведена адреса једнака оригиналној. Бира се као и свако друго правило и и даље инсталира запис превода, па пакет не прескаче NAT обраду. Мења се то да адресе на мрежи остају исте, а управо то IPsec политика тражи.

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

Интерфејси правила и његова route-lookup поставка морају да одговарају дизајну прослеђивања. Правило које адресу пресликава исправно али се примењује на погрешан пар интерфејса неће бити изабрано за ваш ток. Route-lookup одлучује да ли ће преведени пакет бити рутиран или ће се користити оригинално одредиште, а то одлучује да ли се повратни саобраћај враћа кроз тунел.

Управљачки приступ самом ASA је посебан случај. Ако користите identity NAT за управљачки саобраћај, важи захтев за route-lookup специфичан за верзију, а широки изузетак копиран из VPN примера неће поправити SSH.

Deny у IOS NAT ACL-у значи није изабрано овде

На IOS интернет NAT се води листом извора, а тај ACL је класификатор, а не филтер. Permit линија бира саобраћај за превод; deny линија значи да пакет овде није изабран. Тај deny није наредба да се пакет одбаци као deny у ACL-у интерфејса.

Није изабрано овде је уже и од нигде се не преводи. Друго NAT правило, други интерфејс или route-map могу ипак превести ток, па се цела NAT табела мора прочитати. Пакету и даље треба рута, одговарајући crypto ACL и дозвола на стварним границама контроле приступа.

Минимални IOS распоред ставља deny изнад permit у исти списак и усмерава overload правило на тај списак. Crypto ACL тада штити исти пар који deny искључује из превода.

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

Једно проверљиво питање за оба модела

Оба модела одговарају на исто питање: које је правило погодило овај ток и које су адресе напустиле интерфејс? Снимите на спољном интерфејсу и упоредите изворну адресу пре и после гејтвеја. Затим проверите како друга страна види тунел, јер SA може бити подигнут док се заштићени ток преводи негде другде.

На ASA прикажите nat detail и табелу превода; на IOS ip nat translations и одговарајуће ACL бројаче. Правило које никада не расте никада није изабрано, а то упућује на ред, интерфејс или смер, а не на crypto конфигурацију.

Где конфигурација обично погреши

Уобичајени кварови су механички. Deny стоји испод permit и никада се не поклапа. Класификатор се примењује у погрешном смеру, па се повратни ток преводи. Identity правило покрива исправне адресе али погрешан пар интерфејса. Crypto ACL штити подмрежу која се више не поклапа са оним што NAT правило представља.

Запишите оригинални и представљени пар адреса поред власника правила, да следећи инжењер види зашто класификатор одбија превод док firewall дозвољава апликацију. Држите то у тикету за промену, не у личној белешци. Затим поново пустите ток након сваке NAT промене, јер је ред правила део конфигурације и када је текст правила непромењен. Тунел који се подигне није доказ да су адресе преживеле; само снимљени пакет и поглед друге стране након декапсулације.

Повезани чланци