Identity NAT у ASA проти винятку NAT у IOS для трафіку VPN

На шлюзах Cisco і identity NAT у ASA, і виняток класифікатора NAT у IOS зберігають адреси VPN. Правила різняться тим, де пропускається трансляція.

Філія тримає інтернет-PAT і VPN між сайтами на одному шлюзі Cisco, і VPN перестає працювати тієї миті, коли додається NAT. Адреси всередині тунелю більше не збігаються з тим, що захищає crypto ACL, або протилежна сторона бачить трансльовані адреси, маршруту до яких не має. Cisco вирішує це у двох місцях: ASA обирає правило NAT, яке відображає адресу на неї саму, а IOS утримує потік поза правилом трансляції за допомогою deny в 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.

Deny в ACL NAT на IOS означає тут не вибрано

На 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, бо порядок правил є частиною конфігурації, навіть коли текст правила не змінився. Піднятий тунель не доводить, що адреси вціліли; лише знятий пакет і вид протилежної сторони після декапсуляції.

Схожі статті