Identity NAT в ASA срещу изключване на NAT в IOS за VPN трафик

На шлюз Cisco както identity NAT в ASA, така и изключването на NAT класификатор в IOS запазват VPN адресите. Правилата се различават по мястото, където транслацията се пропуска.

Клон поддържа интернет PAT и VPN сайт-към-сайт на един и същ шлюз Cisco и VPN спира да работи в момента, в който се добави NAT. Адресите в тунела вече не съвпадат с това, което защитава crypto ACL, или партньорът вижда транслатирани адреси, за които няма маршрут. Cisco решава това на две места: ASA избира правило за NAT, което преобразува адрес в себе си, а IOS държи потока извън правило за транслация чрез забрана в ACL. И двете запазват оригиналните адреси и нито едно не заобикаля обработката на NAT.

Запишете потока, преди да изберете правило

Започнете, като запишете потока, който смятате да защитавате: източник в локалната мрежа, отдалечена дестинация и точната двойка адреси, която защитава политиката 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.

Забраната в ACL за NAT в IOS означава не е избран тук

В IOS интернет NAT се управлява от списък с източници и този ACL е класификатор, а не филтър. Ред permit избира трафик за транслация; ред за забрана означава, че пакетът не е избран тук. Тази забрана не е инструкция за отхвърляне на пакета, както забрана в ACL на интерфейс.

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

Минимална схема в IOS поставя забраната над permit в същия списък и насочва правилото за overload към този списък. Тогава crypto ACL защитава същата двойка, която забраната изключва от транслация.

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.

Къде конфигурацията обикновено се обърква

Обичайните откази са механични. Забраната стои под permit и никога не съвпада. Класификаторът е приложен в грешна посока, затова обратният поток се транслатира. Правилото за identity покрива правилните адреси, но грешната двойка интерфейси. Crypto ACL защитава подмрежа, която вече не съвпада с това, което представя правилото за NAT.

Запишете оригиналната и представената двойка адреси до собственика на правилото, за да види следващият инженер защо класификатор забранява транслация, докато защитната стена разрешава приложението. Дръжте това в заявката за промяна, а не в лична бележка. След това пуснете потока отново след всяка промяна на NAT, защото редът на правилата е част от конфигурацията, дори когато текстът на правилото не е променен. Вдигнатият тунел не е доказателство, че адресите са оцелели; само заснетият пакет и изгледът на партньора след декапсулация са доказателство.

Подобни статии