antiCisco blogs


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

Опубликовано 30 Ноябрь , 2010

И снова добрый день, коллеги!

Продолжаю серию статей про NAT на Cisco, т.к. предыдущая статья все нашла некоторое количество положительных отзывов.

В этой статье мы рассмотрим, как и было обещано, inside destination NAT. Кому интересно — велкам под кат.

Итак,

inside destination NAT

На самом деле весьма и весьма экзотический вид NATа, созданный специально для балансировки нагрузки между серверами, работающими по TCP протоколу. В реальной жизни встречается не чаще солнечного затмения 🙂

Давайте углубимся.
1. Итак, данная трансляция срабатывает ТОЛЬКО когда соединение инициируется (простите за такое слово) со стороны outside интерфейса в сторону inside интерфейса и для ответного трафика. Но если трафик инициируется со стороны inside — трансляция не произойдет.
2. Такой NAT работает только для протокола TCP.

Зачем нам такая радость?

Допустим, у нас есть десяток web-серверов, имеющих адреса с 10.0.0.1 по 10.0.0.10. На всех серверах крутится один и тот же сайт (вернее это могут быть просто frontend-сервера) и порт у них тоже один, для простоты — 80 (HTTP).

Клиенты снаружи достукиваются до нашего «размазанного» сайта по адресу 11.1.1.1:80.

И мы хотим балансировать нагрузку между ними по принципу RR (Round Robin), т.е. чтобы каждый следующий клиент, обращающийся снаружи к нашему маршрутизатору по глобальному адресу, обращался к следующему серверу из этой десятки (по кругу).
Вот тут-то там и поможет этот хитрый NAT.

Как это работает?

1. Прямая трансляция. Вопреки логичным и привычным ожиданиям, основанным на логике работы inside source NAT, для этого типа прямая трансляция та, которая создается при обращении со стороны outside в сторону inside. При появлении TCP (и только его, повторюсь) трафика на outside интерфейсе, трафик сначала проверяется на соответствие inside destination NAT. Если он соответствует — адрес назначения меняется на следующий в пуле и трансляция заносится в список трансляций. После этого пакет с уже измененным адресом назначения подвергается маршрутизации.
2. Обратная трансляция. Опять же — многое наоборот. Обратная трансляция происходит в направлении inside-to-outside. И здесь уже сначала отрабатывает маршрутизация, если она бросает трафик с inside на outside и есть соответствующая запись в таблице трансляций — пакет растранслируется.

Замечания.
1. В отличие от static inside source NAT и static inside source PAT, маршрутизатор не отвечает на ARP-запросы по поводу глобального адреса, если конечно этот адрес не назначен его интерфейсу. Поэтому возможно потребуется добавить его к интерфейсу как secondary.
2. Как и в случае inside source NAT, трафик роутера тоже подвергается трансляции, даже если нет ни одного inside интерфейса.
3. Следствие из п. 2: если нет inside-интерфейсов, транслируется только трафик самого роутера.

давайте теперь посмотрим, как это конфигурируется.
1. Итак, сначала создаем пул. Адреса в пуле — адреса наших серверов.
(config)# ip nat pool NAME_OF_POOL 10.0.0.1 10.0.0.10 netmask 255.255.255.0 type rotary
я специльно выделил слово rotary — для этого типа NAT пул должен быть ротационным (т.е. мы как раз указываем, что адреса будут браться один за другим
по кругу, иначе по достижению конца пула следующий пакет будет дропнут).

2. Создаем access-list, который будет выделять трафик, подлежащий трансляции. Специально сделал его расширенным:
(config)# access-list 100 permit tcp any host 11.1.1.1 eq www
Т.е. транслировать мы будем трафик, направленный к нашему глобальному адресу и даже конкретному порту (TCP!).

3. Создаем трансляцию, остались мелочи:
(config)# ip nat inside destination list 100 pool NAME_OF_POOL

4. И маркируем интерфейсы (там где сервера — inside, где внешний мир — outside)
(config)# int fa0/0
(config-if)# ip nat inside
(config-if)# int fa0/1
(config-if)# ip nat outside

И теперь, можем пронаблюдать картину обращений к нашему серверу:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.1:80 10.0.0.1:80 11.1.1.251:18747 11.1.1.251:18747
tcp 11.1.1.1:80 10.0.0.2:80 11.1.1.250:52943 11.1.1.250:52943

видим, что один и тот же порт глобального адреса (а именно 11.1.1.1:80) странслировался в разные адреса.

Замечания.
1. Нельзя перенаправлять какой-то порт глобального адреса на другие порты серверов (например 80й на 8080й), порты должны совпадать. Если очень нужно — можно прицепить loopback, транслировать на него обычным inside source static PAT с заменой порта, оттуда уже на сервера с помощью inside destination NAT. И совсем нельзя (ощущение, что с помощью еще и nat enable — можно) такое делать, если на серверах один и тот же протокол отвечает по разным портам (где-то по 80, а где-то по 8080 например). Но если кому-то до зарезу нужно — пишите, попробую сообразить.
2. Если настроены две трансляции — одна inside destination, как выше, а другая — inside source dynamic PAT для тех же серверов, т.е. для трафика, идущего от них наружу, но не попадающего в обратную трансляцию (например для доступа серверов к репозиториям):
ip nat inside source list 110 interface FastEthernet0/1 overload
access-list 110 permit ip 10.0.0.0 0.0.0.255 any

Видим, что они перекрываются, т.е. ответ от серверов с 80го порта должен подвергнуться обратной трансляции inside destination и прямой inside source (кстати, обе они сработают только после маршрутизации). В этом случае, обратная трансляция выигрывает и все будет работать как положено.
3. Нельзя сделать статический inside destination NAT. Для этого нужно использовать static inside source NAT.

В заключение. Подводя итоги, хочу еще разок отметить следующее:
1. Inside destination NAT — технология трансляции адресов с целью балансировки и работает она только для протокола TCP.
2. Хотя интерфейсы маркируются так же, как и в случае inside source NAT, направление прямой и обратной трансляции противоположное.
3. Приоритеты NAT (inside-to-outside и outside-to-inside) такие же, как и в случае inside source NAT.
4. Если трафик инициируется в направлении inside-to-outside, то трансляции он не подвергается (если только Вы там еще не наворотили и inside source NAT).

Я решил не перегружать статью, так что outside source NAT мы рассмотрим в следующей статье.

По традиции — я открыт для пожеланий и предложений.

 

Опубликовано: Маршрутизаторы и коммутаторы

 

2 комментария “NAT на Cisco. Часть 2”

comment rss - Trackback

  1. Я не помню на 100%, на кажется в секурном IEBW была такая фишка и работала она для icmp… Но утверждать не буду — надо бы освежить

  2. Спасибо за статью, интересный тип трансляции. Знал, что он есть, но никогда в жизни не пробовал (балансировку всегда делал на L7).

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

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