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 правилото.

Запишете го оригиналниот и презентираниот пар адреси покрај сопственикот на правилото, за следниот инженер да види зошто класификаторот одбива превод додека огнениот ѕид ја дозволува апликацијата. Чувајте го тоа во билетот за промена, не во лична белешка. Потоа пуштете го текот повторно по секоја промена на NAT, бидејќи редоследот на правилата е дел од конфигурацијата и кога текстот на правилото е непроменет. Подигнат тунел не е доказ дека адресите преживеале; само снимениот пакет и прегледот на спротивната страна по декапсулацијата.

Поврзани статии