Добрый день, коллеги!
судя по многочисленным вопросам на форуме (ссылка в конце поста), от слушателей и коллег, работа NAT на маршрутизаторах Cisco (firewall’ы я опущу, Fedia достаточно подробно его работу расписал в своей серии статей про Cisco ASA) плохо описана, поэтому я попробую описать свой опыт и свое понимание данной технологии в большинстве ее ипостасей. Не претендую на всеобъемлющее описание и 100% точность, но кому интересно — велкам под кат.
Итак, для структурности описания разберемся с определением, что такое NAT.
Определение. NAT (Network Address Translation) — технология трансляции сетевых адресов, т.е. подмены адресов в заголовке IP-пакета (иногда может еще и порт менять в заголовках TCP/UDP, но об этом позже).
Другими словами, пакет, проходя через маршрутизатор, может поменять свой адрес источника и/или назначения.
Зачем это нужно?
1. Для обеспечения доступа из LAN, где чаще всего используются частные IP-адреса, в Internet, где маршрутизируются только глобальные IP-адреса.
2. (в меньшей степени) для сокрытия топологии сети и создания некоторого защитного барьера для проникновения внутрь сети (обсудим это позже на примере).
NAT бывает разным 
И хотя много по этому поводу уже написано, есть желание отправлять новичков с вопросами о NAT по конкретному адресу, поэтому я все же приведу некоторую классификацию.
1. Static NAT — статический NAT задает однозначное соответствие одного адреса другому. Иными словами, при прохождении через маршрутизатор, адрес(а) меняются на строго заданный адрес, один-к-одному. (к примеру 10.1.1.1 всегда заменяется на 11.1.1.1 и обратно, но никогда на 12.1.1.1). Запись о такой трансляции хранится неограниченно долго, пока есть строчка в конфиге.
2. Dynamic NAT — при прохождении через маршрутизатор, новый адрес выбирается динамически из некоторого куска адресов, называемого пулом (англ. pool). Запись о трансляции хранится некоторое время, чтобы ответные пакеты могли быть доставлены адресату. Если в течение некоторого времени трафик по этой трансляции отсутствует, трансляция удаляется и адрес возвращается в пул. Если требуется создать трансляцию, а свободных адресов в пуле нет, то пакет отбрасывается. Иными словами, хорошо бы, чтобы число внутренних адресов было ненамного больше числа адресов в пуле, иначе высока вероятность проблем с доступом наружу.
3. Dynamic NAT with overload или PAT. Работает почти также, как dynamic NAT, но при этом происходит трансляция много-в-один, задействуя при этом возможности транспортного уровня. Об этом подробнее на примере дальше.
Поскольку я чаще всего работаю именно с железом Cisco, я опишу в статье именно особенности работы и возможные варианты NAT именно на этих железках.
Давайте посмотрим, что у нас есть в этом случае.
1. inside source NAT
Самый распространенный и достаточно простой вариант. Допустим у нас есть такая топология:
Другими словами,
а) подсеть внутренних адресов — 10.0.0.0/8
б) подсеть внешних адресов — 11.0.0.0/8
и мы хотим транслировать каким-то образом внутренние адреса во внешние при прохождении трафика через маршрутизатор.
Что для этого нужно?
1. Мы явно указываем, что мы хотим транслировать. Т.е. какой трафик и от каких хостов.
2. Мы явно указываем, во что мы хотим траслировать, т.е. пул внешних адресов (или единственный адрес для статической трансляции).
3. Помечаем внутренний и внешний интерфейс.
4. Включаем трансляцию.
На п.3 я себе позволю остановиться подробнее, потому что именно здесь часто происходит непонимание.
Как это работает?
Итак, допустим мы решили, что будем транслировать всю 10ю сеть целиком в 11ю. Задали их соответствующим образом (настройки потом, сначала теория). И пометили наши интерфейсы как внутренний (inside) и внешний (outside).
Теперь, давайте разберемся, что делает именно inside source NAT. На самом деле, в названии зашита половина действия а именно: у пакета, пришедшего на inside интерфейс меняется source . Но помните, мы говорили о том, что ответные пакеты должны доходить до нашего внутреннего хоста? Отсюда вторая половина действия: у пакета, пришедшего на outside интерфейс меняется destination.
Рассмотрим прямую трансляцию.
1. Трафик, приходя на интерфейс, помеченный как inside, если он соответствует тому, что мы хотим транслировать, маркируется как возможно_транслируемый. Часто полагают, что в этот момент происходит трансляция, но это не так.
2. Следующим этапом, трафик подвеграется маршрутизации (PBR и обычной). И если при этом трафик направляется на интерфейс, помеченный как outside — только тогда происходит трансляция. Если трансляция динамическая, маршрутизатор проверяет ее наличие в таблице трансляций. Если ее там нет — создает, если уже есть — обнуляет счетчик неактивности. Если же пакет попадает на выход на интерфейс, не помеченный как outside — трансляция НЕ происходит.
Теперь обратная трансляция.
1. Трафик, попадая на outside интерфейс, в противовес прямой трансляции, сначала подвергается NAT. Если трансляция существует (неважно, динамическая или статическая), в случае с inside source NAT, у него меняется destination. И только после этого трафик подвергается маршрутизации и перенаправляется по назначению.
Поэтому маркировать интерфейсы как inside или outside нужно именно принимая во внимание механизм работы.
Замечания и следствия.
1. Для обратной трансляции не обязательно наличие метки inside на каком-либо интерфейсе. Все равно, если прямая трансляция существует, обратная трансляция сработает до маршрутизации. Но когда будет существовать такая трансляция, ведь мы обсуждали, что трафик должен пройти через inside интерфейс для создания прямой трансляции? Отсюда
2. Трафик самого роутера подвергается трансляции, если он попадает на интерфейс, помеченный как outside и удовлетворяет правилу NAT. И это сколь полезно, столь и опасно. С одной стороны, мы можем транслировать трафик роутера как и любой другой. С другой стороны, многие хотят описать трафик, подлежащий трансляции как permit any, но тогда и, например, пакеты протоколов маршрутизации будут транслироваться, что приведет к сбою.
3. Интерфейсы типа loopback маршрутизатора трактуются как и любые другие, мы можем метить их как inside или outside, заворачивать на них трафик и получать от этого профит
Теперь посмотрим общую конфигурацию, а потом еще несколько частных случаев.
Конфигурация inside source NAT
inside source dynamic NAT
1. Указываем, что транслировать. Для этого создаем access-list, перечисляющий трафик. Например, в нашем случае достаточно одной строчки:
(config)# access-list 100 permit ip 10.0.0.0 0.255.255.255 any
Замечание. В ACL могут встречаться строчки deny. Вопреки распространенному заблуждению, трафик удовлетворяющей данной строчке не дропается, а просто не подвеграется трансляции. Так же, ACL может быть стандартным и расширенным, нумерованным и именованным.
2. Создаем пул из адресов, указывая стартовый и конечный адрес. Например так:
(config)# ip nat pool NAME_OF_POOL 11.1.1.10 11.1.1.20 netmask 255.255.255.0
Замечания.
1. Стартовый и конечный адрес в пуле могут совпадать, тогда трансляция будет в 1 адрес.
2. Опция netmask, хотя и является обязательной, по моему мнению — рудимент. Она позволяет вырезать из диапазона адресов в пуле те адреса, которые являются адресами подсети или бродкастными при данной маске.
3. Маркируем интерфейсы. В нашем случае достаточно
(config)# interface fa 0/0
(config-if)# ip nat inside
и
(config)# interface fa 0/1
(config-if)# ip nat outside
4. создаем собственно трансляцию:
ip nat inside source list 100 pool NAME_OF_POOL
вуаля Если мы теперь обратимся например с хоста 10.1.1.1 к хосту 11.1.1.2, то получим такую трансляцию:
Router#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.10:55209 10.0.1.1:55209 11.1.1.2:23 11.1.1.2:23
Интересно, что хотя в таблице явно записаны source port и destination port, трансляция создается целиком для адреса. И на время ее жизни в таблице трансляция, пакеты снаружи могут проходить на внешний адрес (inside global)
Например, пинг с некоторого адреса во внешней сети на наш inside global будет успешным (на время жизни трансляции):
R4#ping 11.1.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.1.1.10, timeout is 2 seconds:
!!!!!
Иными словами, открывается трансляция единожды и к некоторому хосту, после этого некоторое время действует для любого адреса извне.
inside source dynamic NAT with overload
П. 1,2 и 3 — как в предыдущем разделе.
4. Создаем собственно трансляцию:
ip nat inside source list 100 pool NAME_OF_POOL overload
Видим, что добавилось всего одно слово: overload. Но оно существенно изменило схему работы трансляции.
Как было сказано, PAT — это трансляция много-в-мало или даже много-в-один. Но чтобы можно было отличить трафик одного соединения от другого, маршрутизатор будет менять не только IP-адреса, но еще и TCP/UDP порты.
Замечание. Схема работы с портами (когда меняется source, когда destination) — такая же, как и схема работы с IP-адресами.
Другими словами, при обращении изнутри наружу меняется source IP и source port, запись об этом вносится в таблицу трансляций. При обратной трансляции — все меняется наоборот.
Посмотрим, что изменилось:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.11:21545 10.0.1.1:21545 11.1.1.2:23 11.1.1.2:23
tcp 11.1.1.11:49000 10.0.2.1:49000 11.1.1.2:23 11.1.1.2:23
Видим, что разные внутренние адреса (10.0.1.1 и 10.0.2.1) странслировались в один внешний (11.1.1.11).
Замечания.
1. Кажется, что source-port не был изменен, как обещали, непорядок . На деле, маршрутизатор пытается сохранить source port всеми доступными средствами. В частности, если порт inside global адреса уже был занят, он возьмет следующий адрес в пуле и проверит его порт на занятость. И только не найдя адреса со свободным портом возьмет следующий свободный.
2. Поведение такой трансляции отличается от поведения обычного dynamic NAT еще и тем, что доступ снаружи на inside global адрес невозможен. Именно это я имел ввиду, когда говорил о некоторой повышенной безопасности при использовании PAT, т.к. фактически все соединения инициируются изнутри нашей сети, а снаружи нам могут приходить только ответы на них.
3. Если мы получили у провайдера не целый блок адресов, а один несчастный адрес, который тут же и назначили внешнему интерфейсу маршрутизатора, можно не городить огород с пулом в один адрес, а сразу писать например так:
(config)# ip nat inside source list 100 interface fa0/1 overload
inside source static NAT and PAT
Много упоминалось о статических трансляциях, давайте наконец их обсудим.
Зачем это нужно?
Мы обсудили, что если в случае dynamic NAT трансляция не создана и в случае PAT, доступ извне невозможен. Если даже в случае dynamic NAT трансляция создана, то inside global адрес может меняться. И обращаться к нашему внутреннему хосту по какому-то внешнему адресу невозможно.
Тем не менее, нередки ситуации, когда внутри корпоративной сети есть сервер, доступ которому извне по статическому внешнему адресу жизненно необходим. В таком случае, можно выставить его прямиком в Интернет, назначив глобальный адрес. Но часто это не очень удобно, например по соображениям безопасности. И в таких случаях нам на помощь приходит static NAT.
Он создает двустороннюю и постоянную трансляцию. Так что наш хост всегда будет доступен по одному внешнему адресу и эта трансляция никогда не вылетит из таблицы трансляций по таймауту.
собственно настройка.
Сразу создаем трансляцию:
(config)# ip nat inside source static 10.0.1.1 11.1.1.21
Маркируем интерфейсы и вуаля!
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 11.1.1.21:14 10.0.1.1:14 11.1.1.2:14 11.1.1.2:14
--- 11.1.1.21 10.0.1.1 --- ---
Как видим, появилось две записи — одна постоянная, другая (чисто информативная) — временная, вызванная трафиком изнутри наружу.
Замечание. Появление таких информативных записей можно отключить командой
(config)# no ip nat create flow-entries
Идем дальше. Часто бывает, что нужно выставить наружу не целый адрес, а только один порт (например 80й для www-сервера). Никаких проблем, можно создать и статическую PAT-трансляцию для некоторых портов:
(config)# ip nat inside source static tcp 10.0.1.1 80 11.1.1.21 80
(config)# ip nat inside source static udp 10.0.1.1 5060 11.1.1.21 7877
Видим, что порты одного и того же внешнего адреса можно пробрасывать на разные порты внутренних, и управлять трансляцией портов при этом тоже возможен.
В заключение добавлю, что изменять различные таймауты для NAT можно командой
Router(config)#ip nat translation ?
arp-ping-timeout Specify timeout for WLAN-NAT ARP-Ping
dns-timeout Specify timeout for NAT DNS flows
finrst-timeout Specify timeout for NAT TCP flows after a FIN or RST
icmp-timeout Specify timeout for NAT ICMP flows
max-entries Specify maximum number of NAT entries
port-timeout Specify timeout for NAT TCP/UDP port specific flows
pptp-timeout Specify timeout for NAT PPTP flows
routemap-entry-timeout Specify timeout for routemap created half entry
syn-timeout Specify timeout for NAT TCP flows after a SYN and no
further data
tcp-timeout Specify timeout for NAT TCP flows
timeout Specify timeout for dynamic NAT translations
udp-timeout Specify timeout for NAT UDP flows
Объемистая статейка получилась, придется разбить на несколько частей. Конечно inside source NAT многократно обсужден и расписан, но надеюсь, что даже не совсем новичкам удастся найти в статье что-то полезное. Надо было начать с некоторой базы, пусть и общеизвестной.
В следующей статье мы обсудим inside destination NAT, если конечно статья найдет отклик и поддержку.
С уважением,
Подкопаев Илья
P.S. Я открыт для пожеланий по улучшению статьи и исправлению неточностей/ошибок.
P.P.S. Ссылки:
1. форум сайта anticisco.ru
2. Cisco NAT order of operations
Копипаст отсюда: http://habrahabr.ru/blogs/cisconetworks/108931/
Продолжаю серию статей про NAT на Cisco, т.к. предыдущая статья все нашла некоторое количество положительных отзывов.
В этой статье мы рассмотрим, как и было обещано, inside destination NAT. Кому интересно — велкам под кат.
Прежде чем читать дальше — дисклаймер: коллеги, я понимаю, что не все ровно относятся к Cisco вообще, CLI в частности и цискарям в особенности. Но давайте все же не разводить холиваров и делать обсуждение более конструктивным, а именно обсуждать конкретно эту статью и описываемую технологию. Поскольку блог-то тематический, то и статья в его тематику. И еще просьба, давайте при несхождении мнений не выходить за рамки корректности. все, извините за лирическое отступление.
Итак,
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).
Копипаст: http://habrahabr.ru/blogs/cisconetworks/108978/
Декабрь 2nd, 2010 
elimS 
для приложений или OS, если вы, например, экспериментируете на рабочем компьютере.
