NAT на Cisco. Часть 2

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

    Продолжаю серию статей про 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. Если он соответствует — адрес назначения меняется на следующий в пуле и трансляция заносится в список трансляций. После этого пакет с уже измененным адресом назначения подвергается маршрутизации.
    ___
    UPD: не-TCP трафик будет направлен на первый адрес в пуле. За комментарий спасибо Ilya_Drey

    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) странслировался в разные адреса.

    ___
    UPD: естественно, трафик балансируется per-session, что необходимо для корректной работы TCP. За комментарий спасибо Ilya_Drey

    Замечания.
    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 мы рассмотрим в следующей статье.

    По традиции — я открыт для пожеланий и предложений. Пока в списке видел policy-NAT.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 44

      –2
      Мне нравиться!

      Через месяц уже новый 2011 год, в течении которого закончатся адреса Ipv4 и миру придется начать миграцию в ipv6, который идеологически отрицает NAT на любом уровне.

      А Cisco тут как тут — вовремя :)
        0
        думаю, нам еще долго понадобится NAT-PT, да и думаю, что многие просто не готовы к тому, что их адрес будет «белым» и нас ждет новая волна червей и троянов.
        Кроме того, технологии не новые, просто я именно сейчас почему-то собрался их описать
          –1
          NAT будет жить ровно столько сколько ipv4, то есть недолго
          Белые адреса — это очень хорошо и многие пользователи и провайдеры это подтвердят.
          firewall не имеет никакого отношения к NAT
            0
            белые адреса хорошо для тех, кто хотя бы отличает их от серых. А сколько домохозяек имеет старую пиратскую винду без единого обновления, на которой файерволл больше похож на решето? Раньше НАТ их хоть отчасти скрывал, а сейчас…
              0
              Файрволл с приходом ipv6 никуда не исчезнет
                0
                это понятно. просто раньше их скрывал NAT провайдера. а теперь нечему.
                  –3
                  Идиотам ничего не поможет, даже если они назвали себя провайдерами
                    0
                    верно. Но я например буду со своей стороны не рад резкому увеличению мощности ботнетов.
                      +2
                      Надеясь на firewall на уровне провайдера вы как раз способствуете их увеличению
                        –1
                        я не надеюсь на него. Мне он не нужен, у меня и так белый адрес и не один :) справляюсь :) Вопрос в том, что многим пользователям он пока нужен
                          +1
                          Я имел в виду что строя сеть в котором единственной защитой абонентов является NAT, выполняющий роль firewall на уровне uplink, вы открываете простор для разгула ботов внутри сети. Достаточно одному пользователю заразиться и вся сеть работает на мировой терроризм.

                          Ежели в сети есть другие механизмы защиты, то я не понимаю зачем этот пассаж про бедных домохозяек с пиратской виндой.

                          PS. рад за вас
                            +1
                            В задачи провайдера, входит только доставка трафика. И меня будет совершенно не радовать то, что фильтрует какие то пакеты, по правилам которые мне не известны и на которые я не могу повлиять.

                            Если уж так хочется, то можно для домохозяек ввести дополнительную опцию (можно даже на этом деньжат срубить). Но этот уже как дополнение. В примые обязанности провайдера, фильтровать «опасный трафик» не входит.
                      +1
                      Вы так радикальны, что прямо вживую ощущаю запах тролля. Будьте тоньше хотя б.
                        –1
                        Я не троллю ( тролю? без понятия как правильно ) и мне нет нужды быть толще или тоньше. Честно.

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

                        NAT=firewall одна из них.
                          –1
                          никто о таком равенстве и не говорит. Но сейчас НАТ отчасти добавляет защиты. Что будет, когда его не будет — … боюсь, ничего хорошего. Конечно, это проблема пользователей. Но интернетом пользуются все, а вот знаний достаточно у немногих.
                            0
                            NAT можно настроить на статический mapping портов, но почему-то из коробки этого нет на типичном CPE.
                            Почему же Вы думаете что в отсутствие NAT в типичной коробке будет отсутствовать firewall?
                              0
                              ну не все ведь подключены через CPE. Многие подключены просто кабелем в комп. И я не говорю, что такие сети, где НАТ — единственная защита — правильные, но таких много, наверное даже большинство. Опять же, на текущий момент белый IP подразумевает отсутствие всякого контроля по доступу к нему со стороны провайдера (а иначе нафига он мне сдался?), а теперь провайдерам придется так или иначе брать на себя ограничение трафика
                                –2
                                Я сейчас не владею статистикой, но пару лет назад NAT был уделом домовых сетей сделанных на коленке. А CPE использовали больше двух третей пользователей и их процент продолжал расти.
                                Белый адрес для провайдера это еще и устранение бутылочного горлышка на uplink-е, а контроль трафика со стороны провайдера быть должен, поскольку есть SLA, QoS, учет и тарификация. Опять же должна быть возможность логгирования.
                                  +2
                                  Белый адрес для провайдера это еще и устранение бутылочного горлышка на uplink-е, а контроль трафика со стороны провайдера быть должен, поскольку есть SLA, QoS, учет и тарификация. Опять же должна быть возможность логгирования.

                                  А что мешает делать это BRASе для локальных IP (как сейчас все и работают)?
                                    +2
                                    Я сейчас не владею статистикой, но пару лет назад NAT был уделом домовых сетей сделанных на коленке. А CPE использовали больше двух третей пользователей и их процент продолжал расти.


                                    вы заблуждаетесь. довольно крупные провайдеры, тоже использовали нат и сейчас используют. т.е. не только домушники.
                                      +1
                                      Начнем с того что двы действительно не владете статистикой. Думаю на этом можнои окончить.
                +2
                Вы наверно дальше заголовка не читали? Этот NAT служит для балансировки внешнего (входящего) трафика между несколькими машинами внутри сети, а не для маскарадинга исходящего. Неужели у ipv6 балансировка есть сразу в протоколе?
                  0
                  для балансировки не обязателен nat, нужно лишь отслеживать сессии и поровну размазывать их по серверам. это можно делать и в ip4, и в ip6.
                +2
                Только что показал нашему админу. Он попробовал на стендовом оборудование. Очень интерестная и полезная вещь. Ждем продолжения. Автору цикла большое спасибо.
                  0
                  большое пожалуйста :) Продолжение будет, NAT объемистая технология
                  +1
                  как известно, nat жрет ресурсов всегда больше всего, вообще реально ли снизить нагрузку на железку от nat? может есть какие тонкие моменты? (я в свое время не копал далеко)

                  спасибо.
                    0
                    ну не больше всего. Имхо больше всего ест IPSec, потом SPI, IPS, а NAT где-то на задворках :) Но тем не менее процессор оно конечно ест. Снизить нагрузку довольно сложно, поковыряюсь на НГ, может и соображу чего-нибудь в плане оптимизации.
                    0
                    Более гибкий и удобный инструмент для распараллеливания, а также резервирования у Cisco — Server Load Balancing (SLB). Но встречается наверняка с той же периодичностью :)
                      0
                      SLB возможна только на более дорогом оборудование и только на определеных версий IOS на сколько я помню. В свое время мы пытались сделать SLB для жаббер кластера но наше оборудование это не поддержывало так что ограничились DNS round-robin.
                        0
                        Никто и не спорит :)
                          0
                          Согласен. Данный метод хорош для оборудования не поддерживающий SLB, также для небольших серверных ферм. Для чего-то более лудше пользоваться SLB.
                        –1
                        Верно. Встречается тоже редко :) Но коль уж я взялся NAT описывать, пришлось и его :) тем более, что кому-то может показаться полезным.
                        –2
                        Прошу прощения, но вся эта информация уже описана в куче документов и книжек, зачем её переписывать сюда?
                          0
                          так или иначе все описано в книжках и документах, Вы не находите?
                            –2
                            Даже не знаю что Вам ответить.
                            Если бы всё было описано в книгах, то не было бы новых продуктов и решений. Всё было бы заранее известно.
                            Думаю что делиться нужно новым и необычным, а то что можно найти в любой уже даже книжной библиотеке — это не интересно — это для лентяев, которые не хотят искать.
                              0
                              почитайте комменты, для некоторых это и новое, и интересное. Впрочем, дело вкуса.
                          0
                          Спасибо, статья пришлась очень кстати!
                          Только возник вопрос — а как будет вести себя циска, если один из серверов станет недоступен? Т.е. подходит ли такая конфигурация для полноценного резервирования и балансировки нагрузки?
                            0
                            пожалуйста :) в том-то и дело, что она только форвардит, к сожалению. Для полноценного резервирования нужен SLB, но он мало какой железкой поддерживается.
                              0
                              Хм, SLB реализуется на свичах, а меня интересует именно резервирование с помощью роутера с натом. На сколько я понимаю, других вариантов реализации, кроме destination NAT cisco не придумала… (
                                0
                                к сожалению, я тоже о них не знаю. Можно было бы попровать совместить Destination NAT + SLB. но семитонника совершенно случайно под рукой нет на пробу.
                                  0
                                  и в догонку, можно попробовать прикрутить SLA/EEM и дописывать/удалять адреса из пула в зависимости от живости хостов, например
                            • UFO just landed and posted this here
                                0
                                спасибо, очень ценные комментарии! Внесу в пост
                                0
                                Спасибо! Доступно и понятно.

                                Only users with full accounts can post comments. Log in, please.