antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 2 Декабрь , 2011

Продолжаем про новый синтаксис НАТа. Начало тут

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

Для этого также используются объекты. Например, мы хотим анонсировать наружу сервер с адресом 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

Согласитесь, что разница существенна!

<<< Предыдущая Следующая >>>

 

Метки: , , ,
Опубликовано: Безопасность cisco

 

One Response to “ASA 8.3. Object NAT. Static”

comment rss - Trackback

  1. […] object network SERVER   host 10.100.1.1 ! object network SERVER_GLOBAL   host Читать далее Tweet VK.init({apiId: 2672059, onlyWidgets: true}); VK.Widgets.Like('vk_like_7428', {type: […]

» Оставить комментарий

Вы должны войти чтобы прокомментировать.