NAT на Cisco. Часть 1

    Добрый день, коллеги!

    судя по многочисленным вопросам на форуме (ссылка в конце поста), от слушателей и коллег, работа 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
    Поделиться публикацией

    Похожие публикации

    Комментарии 67
      –10
      Ох уж эти циски, телесины и тд, километры текста писать надо, трудно им нормальный GUI сделать?
        +4
        лол, такие вещи не конфигурабельны из GUI.
          +1
          Это потому что тебе изначально дали консоль и сказали «жри, блеать». А вообще, веб-морду для настройки ната захерачить можно, и даже без потери функционала. Да вот только нахер это не надо… Особенно, если представить количество ручек/перделок на странице :)
            –1
            у вочгарда сделан гуй и там нат делается в 3 клика
              0
              понятия не имею что такое «вочгард» и иметь не желаю. нат бывает разный. без затейства вывести локалку в интернет и в cisco cli «три клика»:

              ip access-list standart nat
              permit ip 10.0.0.0 0.255.255.255
              ip nat source list nat interface fa1/0
              int fa1/0
              ip nat outside
              int fa1/1
              ip nat inside

              где nat — ацл с указанием локалки, fa1/0 — внешний интерфейс с ойпи в который натить, fa1/1 — внутренний интерфейс. как-то так, мог где-нибудь соврать, писал на память.

              и не в цисках дело. у той же freebsd для этого же надо добавить семь строчек в rc.conf:

              firewall_enable=«YES» #включить фаервол
              firewall_type=«SIMPLE» #имя режима из дефолтового сценария
              firewall_simple_iif=«em1» #внутренний интерфейс
              firewall_simple_oif=«em0» #внешний интерфейс
              firewall_simple_inet=«10.0.0.0/8» #внутренняя сеть
              firewall_nat_enable=«YES» #включить нат
              firewall_nat_interface=«em0» #использовать ойпи внешнего интерфейса для ната

              еще проще при спользовании pf:

              rc.conf:
              pf_enable=«YES»

              pf.conf:
              extif=em0
              intif=em1
              intnet=10/8
              nat on $extif inet from $intnet to any -> $extif
              pass all

              таке чего сложного? :) как мне кажется все просто и понятно, особенно для тех кто посещал уроки английского в школе.

              а вот GUI сложности начинаются ровно в тот момент когда нужно отойти от «простого» сценария. например пробросить гору портов, сделать фильтр-базед пбр и так далее. лично был свидетелем как доблестный одминчег с упорством, достойным лучшего применения, добавлял правило за правилом в вебинтерфейсе делинка… потратив на это около получаса он исчерпал лимит правил. результат — эпик фейл: и времени вагон убил, и задачу не выполнил. а в ненавистном вами cli эти вещи решаются «тремя строчками с копипастой» :D
                0
                ну раз на то пошло :)
                Ubuntu Linux
                edit /etc/sysctl.conf #net.ipv4.ip_forward=1 >>> net.ipv4.ip_forward=1
                iptables -t nat -A POSTROUTING -s $IPNET -j MASQUERADE
                где $IPNET=10.0.0.0/24 наверное это всё нужно в /etc/rc.local перед exit 0
                    –1
                    нет, спасибо. очередное линукс-поделие мне не интересно. угадайте что общего у vyatta, mikrotik'а, ideco ics и т.п. с этим вашим fireware os? правильно, везде линукс в разной обертке, одинакого ущербный и унылый, и за бабло. :)

                    ненавижу зайчиков пользующих подобные решения. потому что эти зайчики как правило вообще не в курсе что хотят сделать. крайний раз одни товарищи купили себе ideco фаервол, который потом сами же и не смогли приготовить. не смотря на все эти красочные веб-интерфейсы и прочее. GUI снижает планку уровня вхождения, а вместе с этим снижается и уровень подготовки реципиента. нет, спасибо. с такими реципиентами невозможно работать. у них «GUI головного мозга» :D

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

                    ps: вы наверно и windows server одмините кликаньем :D там же GUI Ж)))
                      +1
                      Да, всё что вы написали всё верно. Я тупой идиот и быдло.
                        +1
                        ребята, давайте жить дружно и не переходить на личности
                        0
                        а микротик-то тут каким боком? тут cli
                          –1
                          некротик то в глаза видели? :) у него есть и вебморда, и гуи-тулза виндовая (http://wiki.mikrotik.com/wiki/Manual:Winbox) для конфигурирования. и наверно самый убогий кли в мире :)
                            0
                            У меня RouterBOARD 750G, вижу его ежедневно по несколько раз.

                            1) Веб-морда у него никакая, она там и не нужна.
                            2) Отличный виндовый гуй для быстрых операций.
                            3) Полноценный CLI

                            Так что Ваша неправда. CLI там обычно профессионалами и используется.
                              –1
                              профессионалы не используют не(в|к)ротик. :P

                              регулярно ковыряете cli в soho-коробчонке дома/на_роботе? это не повод считать себя профессионалом или надеятся что все делают так же.

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

                              у каждого своя правда, да.
                                0
                                Что-то не то Вам мерещится. Я-то как раз не профессионал.
                          0
                          Дается задача, железки выделяются под задачу. Дают денег внедряем.
                          Предлагаете в офис на 60пк покупать циски?
                          А может достаточно керио для цеха и вочгарда для офиса?
                          Бля, да я вообще тебя и автора не обвиняю нив чем, просто выражаю свое мнение.

                          Понадобится по задачам купить циску и настроить, купим и настроим.
                            +1
                            верно, у циски своя ниша, даже спорить не о чем
                              +2
                              эээ… вобще-то никто не говорил про офис из 60 компьютеров, да и речи про какой-то сценарий внедрения не шло вообще. речь была за cli vs gui. причем тут вообще какие-то циски и офисы? в своем примере про поднятие nat'а я не зря упомянул про freebsd, что какбэ намекаэ «не циской единой».

                              и уж не знаю кто в здравом уме пойдет покупать циско, да еще и новую, да еще и за GPL :) циско уже давно не торт везде кроме голоса, как по фичам, так и по цена/результат, особенно по цена/результат. есть такой миф «ЦИСКО ЭТО КРУТО», но мы тут не развенчивать мифы собирались. я не любитель cisco или какого еще вендора, я любитель комфортной и эффективной работы с оборудованием в этом вопросе. и в этом вопросе GUI никуда не уперлось, потому что сложных вещей на нем не сделать, а простые (как выше было показано) и в тексте выглядят просто.

                              >А может достаточно керио для цеха и вочгарда для офиса?

                              за керио надо бить по лицу ногами, его вечно непонятные безмозглые упыри-экономисты-дрочеры ссаного «ынтырпрайз» говна ставят, а потом ноют что ничего не работает. я считаю «не шаришь — не лезь» и пускай контора наймет того кто «шарит».

                              насчет вочгардов благо не в курсе и надеюсь и останусь не вкурсе.

                              по мне так на предложенные вами условия хватит и старого пня 200мгц с близжайшей свалки с цф флешкой и фряхой на борту. для любителей cisco можно понабрать б/у: цена cisco 3745 $390, цена коммутатора WS-C2950G-48 ~$220, итого $1050 за три свища и маршрутизатор вместе с доставкой и всеми делами. кстате, не думаю что выйдет дороже ваших вочгардов с управляемыми свищами делинк.

                              ps: тут про упырей, как и до про зайчиков, говорится не с целью вас обидеть и вообще не в ваш адрес. не нужно это принимать на свой счет. я же не знаю, может у вас все замечательно и четко работает на kerio и вы никому не поласкаете мозги. :)
                                0
                                Kerio winroute купил и поставил 2.5 года назад, работает как часы, чем меня очень сильно радует. Трафика неучтенного нет, кто куда ходит видно — красота.
                                Никаких глюгов страшных замечено не был, обновлял регулярно.
                                Можно меня бить по лицу за то что работает, но я буду сопротивляться ))))

                                Ноют те, кто читать доки не умеет, о чем весь разговор тут.
                                  –1
                                  Лучше купить нормальное оборудование чем платить ежемесячно быдло админу который поставит какое нить убогое керио.
                                  Дешевле выходит.

                                  Решения же на основе линукса и бзди вполне себе вариант если у вас не слишком много объектов, и если интернет сервисы не особо критичные для бизнеса.

                                  Что же касается поборников дороговизны циски и прочего оборудования.
                                  То она весьма относительна.
                                  По сравнению с затратами на строительство, одного рабочего места даже сотня баксов на порт коммутатора и станции это НЕДОРОГО.

                                    0
                                    Блядь, я сам быдло админ и поставлю и керио и черта лысого.

                                    Всё зависит от задач, бюджета и срока реализации.
                                      0
                                      А еще чаще все зависит от некомпетентных Итшников которые втирают бизнесу всякую хрень которая удобна им.
                                        0
                                        Успокойся, выше мы выяснили что я тот самый быдло-админ, тупица и редкое говно.
                                  0
                                  цена cisco 3745 $390 не подскажете где найти за такую цену? а то наш админ очень любит себе покупать всякие железки.
                    –1
                    Почему не используется GUI, а CLI — ответ очень простой. CLI надежней.
                      0
                      да на самом деле — пусть был бы гуи. но для маршрутизатора должен быть единый интерфейс (в пределах одной железки) (когда куча разных — можно легко запутаться).
                      когда нужно просто сделать НАТ — можно и воспользоваться гуём если он адекватный.
                      а когда этот роутер — на самом деле не просто рядовой роутер, а ядро сети — тут начинаются проблемы.
                      не видел ни одного адекватного гуи в таких железках, хотя уверен, что такой можно сделать.
                      поэтому пока я выбираю консоль. да и копипаст решает и мышка, которая по идее призвана помогать, — только мешает.
                        0
                        В микротике сделано очень логично. Единые названия команд CLI и функций в интерфейсе GUI.
                          0
                          Ну кстати да, как-то забыл про него. Отличная железка, понятный интерфейс. Можно потренероваться на gui — потом комманду в консоль забацать.
                          Консоль правда в нём не очень удобная.
                      +4
                      после веб-гуя на домашних (говно)роутерах хочется как раз нормальной консоли.
                        0
                        есть гуи… но не будем о грустном. Да и тут больше о функционировании, команд всего-ничего.
                        +1
                        GUI давно имеется, вот только он даёт возможность базовой настройки. А если нужно тщательно выверить и подобрать необходимые параметры или получить доступ ко Всем опциям- тогда, да, добро пожаловать в старую добрую коммандную строку.
                          –1
                          Видимо Вы очень мало настраивали cisco через GUI. Там можно всё то же самое что и в консоли, если уметь это делать.
                            +1
                            очень хорошо, может я тоже пропустил. покажите мне MPLS VPN в гуи
                              0
                              или средней сложности QoS :)
                          0
                          Интересно почитать
                          +1
                          инструмент 21 века
                            –3
                            Зато потом на обычных смертных мышевозов можешь сверху смотреть и плевать на них, ты крут, ты циску настраивал.
                            Извините за сарказм.
                              0
                              Да-да, поюзайте свой гуй из тьмутаракани с тормозным и теряющим пакеты GPRS соединением, и при этом имея в наличии только мобильник.
                              А SSH работает.
                                0
                                Судя по всему Вы не умете киски настраивать?
                                  0
                                  Задач не было. По виду команд похоже на телесин, а его я из телнета настраивал, так что свой подъеб оставьте себе.
                                    –2
                                    команды похожи. а поведение нет. Статья именно о поведении
                                      +1
                                      Думаете вы единственный кто научился читать доки? )))
                                        0
                                        и в мыслях не было :) но во-первых, изложенное в статье скорее результат моего личного опыта (исключая команды, конечно), чем изучения доков, а во-вторых, практика показывает, что кому-то это интересно
                                          0
                                          Мир, дружба, жвачка.
                              0
                              Статья как раз во время, спасибо.
                              PS А что все так набросились на командную строку? Отличный инструмент для тех, кто спокойно запоминает команды. Канешь для тех кто циски конфигурит копированием команд из ворда были бы рады гую, но надеюсь таких очень мало.
                                0
                                лол :) таке не из ворда, а из нотпада. и копируются не комманды, а целые сценарии. ибо унылый ios изменения применяет на лету, возможности отката изменений нет. поэтому составляешь один сценарий для применения нужных изменений и другой сценарий для его отката, на коте пишешь релоад ин 10, и копипастишь, и молишься чтобы ничего не отломалось :) и да, наверно таких людей мало, толковых людей вообще мало, да. :(

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

                                  ps в новых версиях иоса есть откат конфигурации, но он конечно не такой удобный как в том же джунипере =)
                                    0
                                    да это ясень пень. терминальные серверы для этого есть. ну или думать надо не затронут ли изменения доступность железки.

                                    да, junos решаэ :) и не только в откатах конфигов. .)
                                      0
                                      reload in
                                    0
                                    пожалуйста.
                                    0
                                    Спасибо. А про полиси-NAT будет?
                                      0
                                      пожалуйста :) да в принципе, почему бы и нет, расскажу и про полиси-НАТ
                                      +1
                                      Неплохая статья. Хотя эта статья мне гораздо больше понравилась www.ebooki.moy.su/publ/4-1-0-1, когда разбирался — там как-то проще всё написано что-ли.

                                      Хорошо бы увидеть в следующей части вопрос производительности, оптимизации и тп =)
                                        +1
                                        Хотя, конечно, та статья явно не такая подробная, как Ваша)
                                          0
                                          цель статьи не столько основы рассказать, сколько особенности поведения. Но за отзыв спасибо :) Вопрос производительности подумаю, как осветить, но не в следующей части, надо сначала остальные варианты НАТ расписать
                                        0
                                        Спасибо за очень интересную статью!

                                        Очень долго делал ненужное действие при обратной трансляции пока сам не понял, что это вовсе необязательно, а Вы — раз и сразу в статье про это указали:
                                        Для обратной трансляции не обязательно наличие метки inside на каком-либо интерфейсе. Все равно, если прямая трансляция существует, обратная трансляция сработает до маршрутизации.


                                        С удовольствием почетал-бы про трансляцию с одного outside на другой outside
                                          0
                                          :) пожалуйста. про трансляции между outside… Напишите в личку, если есть желание, конечно, схему и ожидаемое поведение. Но возможно Вам будет интересна моя же статья в этом блоге про NAT enable
                                            0
                                            я бы теорию сетей почитал, порекомендуй книжек, пжлста.
                                              0
                                              ну если отбросить вендорские книги, то мне очень нравится трехтомник Дугласа Камера, правда там не все, но что есть — хорошо описано.
                                          0
                                          Если кошка не умеет аппаратный NAT — лучше его там не использовать. CPU съедает ещё как.

                                            0
                                            верно. Но вроде на современных роутерах падение производительности не критично (10-15%).
                                              0
                                              7206VRX-G2 — 600Mbit/sec НАТ включен — CPU-95%.
                                              Натить можно на 76XX серии, ASR-ах, ну ещё на 65XX каталистах с NAT модулем.
                                              Как не удивительно НАТ хорошо работает на обычных компах
                                                0
                                                72хх серия вообще в плане многого CPU-зависима. Но вот ISR современные у меня на НАТ реагируют спокойно.
                                                  0
                                                  ну так я и говорю — что для НАТ-а надо спецом кошку подбирать.
                                                  А вот цена такой кошатины — ууууу…
                                                    0
                                                    ну не спецом… ISR, ASR, 76xx, 65хх — это довольно большое семейство, согласитесь. Да и 76хх и 65хх — все больше коммутаторы, хотя и уровня ядра. Для них поддержка ната не основное. 7206 — да, но уж больно древняя железка. ЕЕ и айписек укладывает враз.

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

                                          Самое читаемое