Двусторонний NAT (PAT) на Cisco IOS или NAT NVI

    По просьбе коллеги (Fedia) я собрался с мыслями и решился написать статью про NAT NVI. Надо сказать, что вообще сама по себе трансляция адресов на роутере многократно рассматривалась, в т.ч. в статье «По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP». Тем не менее, описанный в ней механизм inside source и outside source NAT имеет некоторые ограничения.


    Задача 1.
    В частности, рассмотрим топологию:
    image
    Постановка задачи.
    Требуется транслировать на R0:
    • 1. адреса за R2 (10.0.2.0/24) – в интерфейс fa 0/0, при обращении к R1
    • 2. адреса за R3 (10.0.3.0/24) – в интерфейс fa 0/1, при обращении к R2

    Поскольку адрес интерфейса один, то естественно используется PAT.
    Решение № 1.
    Сами по себе трансляции пишутся для каждого случая довольно просто.
    Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
    Router(config)# ip nat inside source list 101 interface fa 0/0 overload


    Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
    Router(config)# ip nat inside source list 102 interface fa 0/1 overload


    Теперь нам, требуется указать для каждого интерфейса, участвующего в трансляции, является он внутренним (inside) или внешним (outside) для трансляции. Вроде все просто но вот незадача: интерфейс fa 0/1 нужно будет сделать одновременно inside и outside. Что невозможно, поскольку каждый интерфейс может быть либо inside, либо outside.
    Решить такую задачу с помощью классического NAT можно только с серьезными ухищрениями.
    Первый способ решения состоит в применении технологии PBR (policy based routing). Идея состоит в следующем:
    • 1. Настроить fa 0/1 у R0 как outside.
    • 2. Создать на R0 виртуальный интерфейс (loopback) lo0 с некоторым адресом и включить на нем ip nat inside.
    • 3. Перенаправить трафик с fa 0/1 на lo0, если этот трафик требуется транслировать в интерфейс fa 0/0.


    Граничные условия. Здесь позволю себе сделать несколько оговорок.
    Во-первых, хотел бы обратить внимание, что такая хитрость возможно далеко не всегда. Дело в том, что PBR срабатывает раньше, чем inside-to-outside NAT (см. статью Cisco: Порядок обработки пакетов «в сложных конфигурациях»). В случае с outside-to-inside NAT это не верно, т.е. сначала проверяются правила NAT.
    Во-вторых, мы создаем излишнюю нагрузку на роутер, т.к. отправка пакетов через PBR всегда нагружает процессор.
    Т.е. решение, хотя и не выходит за рамки классического NAT, стоит на весьма хилых подпорках.

    Решение № 2.
    Теперь, собственно, давайте подойдем к тому варианту, из-за которого и писалась эта статья.
    Технология Cisco NVI NAT (или ее еще часто называют ip nat enable) позволяет нам не заботиться о маркировании интерфейсов как inside или outside. Мы просто маркируем их, как включенные в NAT с помощью команды
    Router(config-if)# ip nat enable
    И пишем унифицированные правила. В частности для нашего случая, эти правила будут отличаться только отсутствием слова inside:
    Router(config)# access-list 101 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
    Router(config)# access-list 102 permit ip 10.0.3.0 0.0.0.255 10.0.2.0 0.0.0.255
    Router(config)# ip nat source list 101 interface fa 0/0 overload
    Router(config)# ip nat source list 102 interface fa 0/1 overload

    А роутер сам разбирается, при получении на интерфейс пакета, подвергать этот пакет прямой или обратной трансляции, и какое у этой трансляции направление.
    Естественно, такая «автоматика» требует гораздо более внимательного задания «интересного» трафика для трансляции, поскольку если описать его слишком поверхностно, можно получить непредсказуемое число трансляций в обе стороны.

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

    Задача 2.

    Постановка задачи.
    Часто бывает, что для некоторых запросов извне нам бы хотелось представить «запрашивающих» в качестве некоторого внутреннего адреса.
    Рассмотрим топологию
    image
    Условия задачи:
    • 1. На R1 для хостов из 192.168.0.0/24 сети сконфигурирован PAT в адрес 172.16.1.5.
    • 2. На SRV1 шлюзом по умолчанию выставлен R2.
    • 3. Необходимо пробросить на R1 порт SSH (22) на сервер.

    Анализ.
    Очевидно, что классический static PAT в данном случае не подходит, т.к. при запросе из интернета он изменит нам только адрес и порт назначения (c 172.16.1.5:22 на 192.168.1.2:22), оставив source (любой адрес из интернета) неизменным. Тогда ответ от SRV пойдет через шлюз по умолчанию, т.е. через R2 в интернет.
    Нам же нужно, чтобы ответ возвращался тем же путем – через R1, т.е. чтобы клиент, подключившийся к серверу, получил ответ от того же глобального адреса, на который он обращался. Для этого хорошо бы представить обращающиеся к 172.16.1.5:22 хосты в качестве некоторого внутреннего адреса, например 192.168.0.201, тогда ответ на этот адрес пойдет по маршрутизации от R2 через локальную сеть к R1 и уже потом в Интернет.
    Казалось бы, для этого можно использовать outside source NAT, но есть в cisco IOS одна загвоздка: outside source NAT не может быть PAT, т.е. работает на сетевом уровне и транслирует адрес в адрес. Это вынуждает нас делать трансляцию в некий пул. И число таких одновременных трансляций ограничено емкостью пула.
    Поскольку количество адресов в интернете превышает любой наперед заданный пул, а сервер может быть очень посещаемый, то данное решение слабо нам подходит.
    Решение.
    Обратимся к Cisco NVI. Поскольку направление трансляции больше не задается на интерфейсах, мы можем сделать несколько прямых PAT-трансляций:
    1. Трансляция для выхода в интернет наших хостов:
    Router(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
    Router(config)# ip nat source list 100 interface fa0/0 overload

    2. Трансляция для проброса порта:
    ip nat source static tcp 192.168.1.2 22 172.16.1.5 22 extendable
    3. Трансляция адресов всевозможных запрашивающих хостов во внутренний адрес 192.168.0.201
    Router(config)# access-list 101 permit tcp any host 172.16.1.5 eq 22
    Router(config)# ip nat pool SERV_PAT 192.168.0.201 192.168.0.201 prefix-length 24
    Router(config)# ip nat source list 101 pool SERV_PAT overload

    Другими словами, мы совместили две динамических PAT-трансляции и одну статическую.

    Конечно, данная статья не претендует на всевозможное раскрытие возможностей Cisco NVI NAT, тем не менее, она может быть полезна тем, кто часто использует NAT в своих топологиях и не хочет ограничивать себя возможностями классического NAT.

    P.S. Спасибо Fedia за инвайт, приобщение к хабраобществу и просто за то, что сподвиг на написание сего опуса :)

    Подкопаев Илья, инструктор
    Share post

    Similar posts

    Comments 37

    • UFO just landed and posted this here
        +1
        Спасибо за отзыв :) Рад, что пригодилось
        +2
        Добро пожаловать, Илюх :)

        Удачного «вхабрения» :)
          +2
          :) Умеешь ты заражать идеями
            0
            Кстати, я сегодня твою статью ещё и у нас поместил. Погляди и дай ценные замечания, как поправить дезигн блога. А то что я один думаю :)
            www.anticisco.ru/blogs/?p=23
              0
              :) ок, гляну. Счас вот статью про GET VPN допишу и гляну.
        • UFO just landed and posted this here
            0
            ой прощай твоя карма
            • UFO just landed and posted this here
              +1
              Приведите плз если не сложно примеры этих волшебных ОС. Чтобы не быть голословным

              Желательно с примером конфигов в 2 строчки. Заранее спасибо.
                0
                iptables -t nat -A POSTROUTING -s -d -o -j MASQUERADE
                  0
                  -s (src_ip) -d (dst_ip) -o (out_intf)*
                    0
                    О, прекрасно, Линукс :)

                    И чем это сложнее
                    ip nat sourse access-list NAT int f0/0 overload?

                    По мне так у циски читаемей :)

                    К тому же расстрою: не все можно сделать на Линухе. Я имею ввиду сопряжение нескольких технологий

                    Классический пример: сопряжение РАТ и МСЭ

                    Впрочем, в мире передачи пакетов сложно что-то совсем новое придумать :)
                    Поэтому у всех все похоже.

                      0
                      угу. или NAT при H323. На BSD есть глючный самописный пакет, а Cisco влет с этим справляется.
                        0
                        [qs@archevil ~]$ modprobe -l | grep -P «h323|sip»
                        kernel/net/netfilter/nf_conntrack_h323.ko
                        kernel/net/netfilter/nf_conntrack_sip.ko
                        kernel/net/ipv4/netfilter/nf_nat_h323.ko
                        kernel/net/ipv4/netfilter/nf_nat_sip.ko
                        [qs@archevil ~]$

                        В последний раз все норм работало.
                          0
                          а на нагрузку тестили? нам результат очень не понравился, происходят обрывы, односторонние звонки и т.п. И это всего при порядка 150 одновременных звонков. Сейчас на этом месте ASA и проблем нет.
                            0
                            А jingle? :-)
                            Не сильно хорошо в Linux с NATами.
                          0
                          по подробнее про PAT и МСЭ проблему можно?
                          сложнее не сложнее, вопрос был про 2 строчки, соотв ответ был дан:)
                            0
                            Уверен, вы про нее знаете: есть множество протоколов, которые требуют динамического открытия портов или открытия новых сессий с других адресов
                            FTP, SIP, H323, RSH, SQL*NET и множество других, например, TFTP :)

                            Каждый из описанных протоколов не пройдёт через РАТ и через МСЭ сам по мебе. Требуются ухищрения.

                            На цисках реализован механизм глубокого анализа многих таких протоколов и у правление сессиями и НАТ-кешем на основании этого анализа

                            Сложного в этом ничего нет и вероятнее всего все эти протоколы можно прокинуть через «любую нормальную ОС», только требует множества телодвижений для каждого протокола
                              0
                              насчет множества — оч сомнительно, необходимо лишь подгрузить соотв модуль из списка:

                              [qs@archevil ~]$ modprobe -l | grep nf_nat
                              kernel/net/ipv4/netfilter/nf_nat.ko
                              kernel/net/ipv4/netfilter/nf_nat_amanda.ko
                              kernel/net/ipv4/netfilter/nf_nat_ftp.ko
                              kernel/net/ipv4/netfilter/nf_nat_h323.ko
                              kernel/net/ipv4/netfilter/nf_nat_irc.ko
                              kernel/net/ipv4/netfilter/nf_nat_pptp.ko
                              kernel/net/ipv4/netfilter/nf_nat_sip.ko
                              kernel/net/ipv4/netfilter/nf_nat_snmp_basic.ko
                              kernel/net/ipv4/netfilter/nf_nat_tftp.ko
                              kernel/net/ipv4/netfilter/nf_nat_proto_dccp.ko
                              kernel/net/ipv4/netfilter/nf_nat_proto_gre.ko
                              kernel/net/ipv4/netfilter/nf_nat_proto_udplite.ko
                              kernel/net/ipv4/netfilter/nf_nat_proto_sctp.ko

                              актуально для
                              [qs@archevil ~]$ uname -mrs
                              Linux 2.6.30-ARCH i686
                              [qs@archevil ~]$

                              и одной строкой в iptables сказать чтоб track делал, дальше он все автоматом.

                              Я не в коем случае не говорю, что линукс замена всему и вся, да и больших диплоев на нем никогда не делал ( работая в СИ как то невыгодно линукс-решения продвигать :) все больше по цискам да джуниперам )

                              Но для soho/small branches вполне жизнеспособное решение.
                                0
                                Да, я в курсе. Я чуть-чуть настраивал Линух (РедХат Сертифайд Инжинер)

                                Просто в циске ничего подгружать и проверять не надо. Надо только набрать команду. Это импонирует :)

                      • UFO just landed and posted this here
                      0
                      И в этой нормальной ОС куча различных интерфейсоф, высокая надежность поддержка производителя.
                      Ну и как бы сиськи не для нищебродов, дорогие они для решения только такой задачи.
                        0
                        Поддерживаю, давайте не будем разводить холивары. Если циски покупают по такой цене — значит это кому-нибудь нужно. А если нужно — есть возможность не ограничиваться inside натом.
                        • UFO just landed and posted this here
                      +1
                      на днях напишу статью посвященую nat-у в общих чертах, а то эта статья расматривает уже более серьезную проблему, которую я так и не понял, даже перечитав дважды :((
                        0
                        да, безусловно, эта статья скорее как расширение для тех, кто знаком с классическим натом на циско.
                          +1
                          Прекрасно! Больше статей, хороших и нужных!

                          А если к теории добавить команд циско, жунипер и линукс будет вообще прекрасно!
                          • UFO just landed and posted this here
                              0
                              Не уверен, что правильно понял вашу иронию: что вызвало такую реакцию?

                              Что мы ретрограды и рассуждаем позапрошлогодним днем?

                              ЧТо все уже устарело? Что пора думать о дне завтрашнем?

                              ЗЫ RR по-моему в 1901 году ещё не было. А если взять RR1920, то жигули уже увы, рядом не валялись :))

                              ЗЗЫ Просьба, для исключения недопонимания выражаться более развернуто :)
                              • UFO just landed and posted this here
                                  0
                                  так в чем дело? напишите свою статью, где наглядно продемонстрируйте все превосходство *nix технологий над CISCO. Мы с удовольствием почитаем.
                                    0
                                    Ну что же, достаточно развернуто, спасибо

                                    ВАЗ (любой) быстрее 200 не поедет. РР1920 года поставил рекорд. Кажется 215 км/ч.

                                    Могу ошибаться с годом. Да бензина кушал много

                                    Теперь поговорим на вашем языке:
                                    любой BSD или *nix
                                    Нет таких операционных систем. «Наш порошок в 3 раза лучше обычного»

                                    элементарные — я рад, что для вас они элементарные. Увы, это не для всех так, о чем свидетельствуют массовые положительные отзывы. А также многолетняя практика преподавания

                                    коими IOS не является — ну поведайте скорее же миру, чем является IOS! Мир вздрогнет! Боюсь, правда, что не от откровения а от стиля изложения.

                                    Словоблудие является хорошим способом скрыть невежество. Теперь Вам придётся доказывать обратное, приводя сравнения, таблицы, настройки.

                                    В отличие от Вас, мы не занимаемся словоблудием а учим. Работать на том, что сейчас, как бы вам не хотелось изобразить обратное, является лидером на рынке сетевых инфраструктур.

                                    Любые Ваши аргументы, пожалуйста, теперь подкрепляйте подтверждениями.

                                    ЗЫ Впрочем, боюсь, что их нет. Рад бы ошибиться :)

                                    Удачи! И не злоупотребляйте словоблудием :)
                                    • UFO just landed and posted this here
                                        0
                                        Ну, пусть будет так: не ездил, не пробовал, не участвовал.

                                        Как и предполагал: газирование лужи.

                                        Не надо так напрягаться и оправдываться :)

                                        Я знаю, как эти (и другие) железки работают и сумею с любыми справиться.

                                        А вам желаю побольше гулять и смотреть на мир добрее :)
                                        0
                                        Серег, оставим тролля в покое…
                              0
                              Топология из задачи 2:
                              image

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