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

Похожие статьи