Настройка NAT на Cisco ASA 8.3. Object NAT

Наверняка многие уже столкнулись с большими изменениями в синтаксисе настройки NAT при переходе от линейки ASA ОС 8.2 к 8.3. Трудно сказать, с чем связано такое резкое изменение подхода, но одно можно сказать уверенно: настройка стала менее понятна и прозрачна. Но это не повод вовсе не использовать версии 8.3, 8.4 и далее (вряд ли разработчики вернут старый синтаксис)

Предлагаю постепенно, от простого к сложному, освоить новый синтаксис, ибо по нему регулярно возникают вопросы. Итак, cisco ввела два новых понятия: Object NAT и Twice NAT, заменив ими все предыдущие типы (Regular, Policy, Identity NAT).
______________
UPD 10.12.11
А также попутно отменила понятие nat-control. Теперь у нас тотальный no nat-control что означает «нет правила НАТ — просто маршрутизировать».
______________

Для начала познакомимся с понятием object NAT, узнаем про последовательность обработки правил object NAT, потом познакомимся с TWICE NAT и в конце подведем черту: опишем всю последовательность правил NAT в новом синтаксисе. Планирую небольшой цикл статей — штуки 4, дабы не перегружать сразу читателей.

Работать будем вот с такой топологией

Рассмотрим простейшую задачу: выйти через ASA в интернет.
Для этого, как и ранее, надо определить, какие внутренние адреса мы собираемся транслировать в какой внешний пул адресов (NAT) или какой адрес (РАТ).

Для начала хочу обратить ваше внимание, что кроме уже привычных object-group разного типа в версии 8.3 появились просто объекты (object) типа network и service:

object network {ИМЯ}
object service {ИМЯ}

и именно при помощи них описываются погрупповые правила НАТ. Не перепутайте!

Согласно новому синтаксису object NAT, адреса, которые мы собираемся транслировать, описываются при помощи объекта типа network, например:
object network LAN
  subnet 10.1.1.0 255.255.255.0

Во что мы транслируем указывается также помощи отдельного объекта. Если мы хотим написать трансляцию в пул адресов, то можно прямо так и указывать
Object network MAPPED_LAN_POOL
  range 20.1.1.10 20.1.1.100
Если же хочется сделать динамический PAT в адрес, отличный от адреса интерфейса, то можно создать такой объект:
Object network MAPPED_LAN_HOST
  host 20.1.1.101
Примечание: для РАТ отдельный объект имеет смысл создавать, когда в нем несколько хостов. Если же используется всего один адрес, то его можно будет указать явно в соответствующей строке nat.

__________________
UPD 9.12.11 — Один объект может содержать либо ОДИН хост, либо ОДИН непрерывный диапазон, либо ОДНУ подсеть. Это важно, а сразу не упомянул.
__________________

Сама трансляция будет описываться так: необходимо конкретному объекту, описывающему адреса, которые мы хотим транслировать, применить правила трансляции. Для этого заходим в ранее созданный объект и пишем:

object network LAN
  nat (INS,OUT) dynamic MAPPED_LAN_POOL [interface] [dns]

Аналогично для описания трансляции РАТ:
object network LAN
  nat (INS,OUT) dynamic MAPPED_LAN_HOST [interface] [dns]

Или явно указав адрес:
object network LAN
  nat (INS,any) dynamic 20.1.1.101 [interface] [dns]
___________________________
UPD 9.12.11
Важно: в качестве группы для динамической трансляции нельзя использовать объекты, содержащие сеть. Только хост или диапазон.
___________________________

Интересная особенность: теперь не обязательно указывать интерфейсы (то, что в скобочках)! Если их явно не указывать, то НАТ станет ненаправленным (аналог ip nat enable на маршрутизаторах) и будет работать на всех интерфейсах, если адрес источника попадет в группу LAN. Мало того, можно зафиксировать лишь один интерфейс (источника или назначения), не указывая явно второй, заменив его на any.
Выглядеть это может вот так:
object network LAN
  nat dynamic MAPPED_LAN_HOST [interface] [dns]

Или так:
object network LAN
  nat (INS,any) dynamic MAPPED_LAN_HOST [interface] [dns]

Ключевое слово interface можно написать для того, чтобы после исчерпания пула, либо зарезервированного количества сессий для одного адреса в РАТ, продолжать транслировать, но уже с использованием адреса интерфейса. Правда, при использовании этой опции название интерфейса назначения надо указывать явно (any не сгодится).

Ключевое слово dns – старый добрый ДНС-докторинг. ASA подслушивает запросы ДНС и подменяет ответы, если в ответе содержится глобальный адрес из какой-нибудь статической трансляции на этой ASA (подробнее — в цикле статей про АСА 8.2).

Важно отметить, что если необходимо транслировать разные внутренние адреса (сети) в один и тот же внешний пул адресов (или адрес), можно использовать одну и ту же объектную группу назначения несколько раз.
А вот если есть необходимость транслировать одну и ту же сеть в разные пулы при прохождении через разные исходящие интерфейсы, одну и ту же группу источника использовать будет нельзя. Вот такое странное ограничение: придётся создавать несколько групп с разными именами, но с одной и той же сетью.
Пример того, как НЕЛЬЗЯ:
object network LAN
  nat (INS,OUT) dynamic 20.1.1.101
  nat (INS,DMZ) dynamic 172.16.1.101

Причем ASA не ругнется, но сохранит лишь последнюю строчку
TESTASA(config-network-object)# sh run nat
!
object network LAN
  nat (INS,DMZ) dynamic 172.16.1.101

Приходится делать 2 разных объекта под каждое правило:
object network LAN_FOR_DMZ
  subnet 10.1.1.0 255.255.255.0
  nat (INS,DMZ) dynamic 172.16.1.101

Для закрепления этого кусочка приведем пример конфига, когда мы локальную сеть 10.1.1.0/24 транслируем в пул 20.1.1.10-20.1.1.100 с подстраховкой в виде динамического НАТа в адрес интерфейса и ДНС-докторингом:

object network MAPPED_LAN_POOL
  range 20.1.1.10 20.1.1.100
!
object network LAN
  subnet 10.1.1.0 255.255.255.0
  nat (INS,OUT) dynamic MAPPED_LAN_POOL interface dns

Итак задача минимум выполнена: динамический НАТ мы настроили, в интернет вышли, трансляции и сессии создаются, как мы и хотели:
TESTASA# sh run nat
!
object network LAN
  nat (INS,OUT) dynamic MAPPED_LAN_POOL interface dns
!
TESTASA# sh xl
1 in use, 1 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from INS:10.1.1.2 to OUT:20.1.1.71 flags iD idle 0:03:13 timeout 3:00:00
!
TESTASA# sh conn
1 in use, 1 most used
TCP OUT 20.1.1.1:23 INS 10.1.1.2:47525, idle 0:00:10, bytes 134, flags UIO

Теперь вторая задача: анонсировать что-либо наружу, т.е. статические трансляции.
Продолжаем использовать эту топологию:

Для этого также используются объекты. Например, мы хотим анонсировать наружу сервер с адресом 10.100.1.1 (статический NAT) по адресу 20.1.1.102. Для этого мы тоже создаем группы:
object network SERVER
  host 10.100.1.1
!
object network SERVER_GLOBAL
  host 20.1.1.102

И применяем правило статического НАТа для группы, которая описывает реальный адрес сервера:
object network SERVER
  nat (INS,OUT) static SERVER_GLOBAL [dns]

Можно также явно указать адрес, в который мы транслируем
object network SERVER
  nat (INS,OUT) static 20.1.1.102 [dns]

Сохраняются все те же особенности, что и для динамического НАТа: названия интерфейсов не обязательно указывать, тогда будет работать НАТ на всех парах интерфейсов, можно не указывать какой-то один из интерфейсов, заменив его название словом any.

Ключевое слово dns нужно для ДНС-докторинга совместно с таким же словом для динамической трансляции. Если в статической или динамической трансляции не указать это ключевое слово, то технология ДНС-докторинга не будет работать. Еще одно замечание по ходу: ДНС-докторинг работает ТОЛЬКО для трансляций NAT (адрес в адрес). Если вы пользуетесь внешним ДНС-сервером и хотите попасть на свой частный сервер по имени, то надо такой сервер пробрасывать статическим NATом (а не РАТом).

Таким образом можно описать трансляцию адрес в адрес. Если необходимо описать трансляцию РАТ (с портами) то надо дополнительно указывать слово service и пару портов (реальный и измененный):
object network SERVER
  nat (INS,OUT) static SERVER_GLOBAL service {tcp|udp} {REAL_PORT} {MAPPED_PORT}

Пример: проанонсируем наружу 80 порт сервера через адрес 20.1.1.102 и порт 8081
object network SERVER
  nat (INS,OUT) static SERVER_GLOBAL service tcp 80 8081

Когда мы транслируем один внутренний адрес в один внешний адрес все понятно. А что будет, если мы укажем для трансляции не хост, а диапазон (range) или подсеть (subnet)?

В случае если «мощность» объектов одинаковая (в них одинаковое количество хостов), то будет выполняться трансляция «один в один». Например, можно странслировать подсеть целиком в другую подсеть или сделать identity NAT – странслировать сеть в себя в каком-то направлении.

Но попробуем схитрить и настроим такую схему:
Выберем пул адресов для трансляции на 9 хостов:
object network TESTLOCAL
  range 10.100.1.2 10.100.1.10

Выберем пул, в который транслируем, меньшего размера (путь будет 2 адреса):
object network TESTGLOBAL
  range 20.1.1.201 20.1.1.202

Теперь привяжем одно к другому:
object network TESTLOCAL
  nat (INS,OUT) static TESTGLOBAL

ASAшка съедает эту команду не ругнувшись и отчете пишет так (обратите внимание на запись: АСАшка записывает диапазон в виде маленьких подсеток):
TESTASA# sh xl
4 in use, 4 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
NAT from any:10.100.1.2/31, 10.100.1.4/30, 10.100.1.8/31,
    10.100.1.10 to any:20.1.1.201, 20.1.1.202
    flags s idle 0:15:29 timeout 0:00:00

Но «съесть» команду мало! Надо проверить, как это будет работать.
Для начала попробуем выйти наружу. Создадим на cisco 2911 несколько лупбеков с адресами 10.100.1.2-10.100.1.10. Далее, откроем несколько телнет-сессий на 1841 с разных лупбеков
TEST2911# telnet 20.1.1.1 /source loop X

На 1841 мы увидим следующую картинку:

TEST1841# show user
194 vty 0 cisco idle 00:02:33 20.1.1.201
195 vty 1 cisco idle 00:02:31 20.1.1.201
196 vty 2 cisco idle 00:02:04 20.1.1.202
197 vty 3 cisco idle 00:00:37 20.1.1.201
*198 vty 4 cisco idle 00:00:36 20.1.1.202

Как видно, ASA делает какой-то вариант round-robin. Теперь самое интересное: это ведь статическая трансляция, а значит она должна работать и снаружи внутрь! Проверим:
Откроем 5 разных telnet-сессий с разными адресами источника на разные адреса из пула TESTGLOBAL с 1841

TESTASA(config)# sh conn
5 in use, 5 most used
TCP OUT 20.1.1.1:21680 INS 10.100.1.3:23, idle 0:00:09, bytes 143, flags UIOB
TCP OUT 20.200.1.1:52285 INS 10.100.1.3:23, idle 0:00:17, bytes 156, flags UIOB
TCP OUT 20.200.1.1:22909 INS 10.100.1.2:23, idle 0:00:43, bytes 156, flags UIOB
TCP OUT 20.1.1.1:56820 INS 10.100.1.2:23, idle 0:01:14, bytes 160, flags UIOB
TCP OUT 20.1.1.1:54876 INS 10.100.1.2:23, idle 0:01:33, bytes 2193, flags UIOB

Легко видеть, что сессии приходят только на первые два адреса из пула TESTLOCAL
Теперь попробуем наоборот: маленький пул TESTLOCAL (10.100.1.2-10.100.1.3) и большой – TESTGLOBAL (20.1.1.201-20.1.1.210). Еще раз открываем сессии с 1841 в сторону АСАшки и попадаем на 2911.
Все сессии на разные адреса из пула устанавливаются:

TEST1841#sh sess
Conn Host Address Byte Idle Conn Name
* 1 20.1.1.208 20.1.1.208 0 0 20.1.1.208
2 20.1.1.203 20.1.1.203 0 5 20.1.1.203
3 20.1.1.204 20.1.1.204 0 5 20.1.1.204
4 20.1.1.205 20.1.1.205 0 2 20.1.1.205

Причем на разные локальные адреса тоже по какому-то алгоритму round-robin
TESTASA# sh conn
4 in use, 5 most used
TCP OUT 20.1.1.1:33295 INS 10.100.1.3:23, idle 0:00:00, bytes 379, flags UIOB
TCP OUT 20.1.1.1:56208 INS 10.100.1.3:23, idle 0:06:15, bytes 156, flags UIOB
TCP OUT 20.200.1.1:58275 INS 10.100.1.2:23, idle 0:03:48, bytes 173, flags UIOB
TCP OUT 20.1.1.1:35543 INS 10.100.1.2:23, idle 0:06:48, bytes 143, flags UIOB

Правда, проходит некоторое время (небольшая пауза) при установлении первой сессии на локальный адрес. Наверно это связано с первичным контактом АСАшки на новый адрес из локального пула.

Таким образом можно сделать вывод, что трансляции теперь можно делать «много в много»

Итак, мы научились делать статические трансляции. Здесь уместно упомянуть еще одно умопомрачительное изменение: теперь списки доступа, которые висят на интерфейсе, внешнем для НАТовской трансляции, работают иначе. Вернее, иначе устроен алгоритм проверки входящего через этот внешний интерфейс пакета, инициирующего сессию. Сначала ASA проверяет, есть ли для адреса, на который обращаются, статическая трансляция (NAT или PAT). Если есть, то ASA сначала производит трансляцию, а уже потом проверяет разрешение в списке доступа для этого интерфейса. Это в корне отличается от предыдущего алгоритма, который работал также, как на маршрутизаторах: сначала проверяем входящий ACL, а уже потом наличие трансляции.
В связи с этим изменением, списки доступа на внешнем интерфейсе станут выглядеть непривычно: в них разрешения надо указывать уже на частные адреса (те, которые реально присвоены вашим серверам). Справедливости ради скажу, что такой подход – не инновация циски: Juniper, Vyatta, Linux работаю также.
Пример нового конфига для нашего сервера (пусть мы хотим пропускать http):

access-list FROMOUT permit tcp any h 10.100.1.1 eq 80
access-group in int OUT

В ОС 8.2 и ранее надо было писать так:
access-list FROMOUT permit tcp any h 20.1.1.100 eq 80
access-group in int OUT

Источник: blogsvazista.ru/cisco-asa-8-3-object-nat/