Cisco Router + 2ISP + NAT. Доступность сервиса через 2ух провайдеров

image

Толчок. За ним ещё один, сильнее. Вот и всё. Перед глазами проносились альпийские луга, и девушка в бежевом сарафане, игриво крутя в точёных ручках кружевной зонтик проносилась мимо тоже. Проносилась, не сбавляя скорости, несмотря на то, что я тянул к ней свои менее точенные, но крепкие ручонки, а также жестами и мимикой изображал, в меру сил своих, какой всесторонний кундюшок её может ожидать, раскинь она мне руки навстречу (ну или ещё что раскинь).
Но случилось что случилось, и лишь ловко выхваченный зонтик из её, кстати, не только точённых но и цепких рук, немного оттенял розовыми тонами последние секунды моего пробуждения и согревал разбитое сердце (без зонтика, закрывающего её шевелюру, девушка оказалась на поверку немного, мягко говоря, плешиватой). Открыв глаза я, как то не странно, увидел себя не посреди развалин Ниигаты, и сразу отринул сейсмическую природу толчков. Немного отлегло. Перестал кричать – «Покинуть корабль!». С укором взглянул на начальника отдела трясущего меня за плечо. Который, вместо извинений принёс мне весть, что нас с ним ожидают у директора, для постановки одного маленького, но очень ответственного задания. Не приняв его слова близко к сердцу, я несколько раз пытался вернуться к своей плешивой искусительнице, но начальник продолжал проявлять чудеса настойчивости. Пришлось идти.

Опущу момент пребывания в кабинете у директора и процесс постановки нам боевой задачи — ни к чему вам знать подробности этих преступных сцен преисполненных плохо завуалированных угроз и открытого шантажа, слёз и мольб с показыванием фотокарточек приёмных детей своих родителей, и вздыманием рук над головой, полных отчаяния просьб не губить и бросания трубок с уже набранным номером следователя комитета безопасности (были… были, как видите, и у меня на такой случай козыри в рукаве — а раньше нужно было думать, отчего я так рьяно бросался лично проверять настройки вай-фай на директорских лэптопах, а теперь как говориться — «Who is your Daddy now, darling? А? А БЛ###Ь!?»). Но, так или иначе, задача, была поставлена, и стояла она в полотне Project сервера так, что у увидевших её молоденьких девушек рделись щёки, а прочий женский коллектив с некоторым, знаете ли, отвращением поглядывал на фотокарточки своих рахитичных половинок, стоящих на углах столов пожилых прелестниц. Пути назад не было – задачу нужно было решать.

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

Вернувшись в кабинет, я сел крепко думать над поставленной задачей и способами получения загранпаспорта из ломбарда назад, не возвращая денег. «Ну что, случиться то может» – успокаивал я себя, — «Интернет у нас стабильный, включу шнурочек, и пущай себе работает, на радость людям и прочему преступному элементу». Отчитавшись начальству, что «Вероятность падения канала – КРАЙНЕ!!! КРАЙНЕ МАЛА!!!», и, приняв эту мысль за аксиому, я, счастливо улыбаясь, вернулся к просмотру видений с лысоватыми девушками в розовых сарафанах. Но, как назло, пытливые умы инженеров нашего уездного оператора связи в аккурат в это время начали подбираться к трём (крайне неприятным мне с той поры) буквам – BGP, и активно осваивать всяческие изыски фильтрации path атрибутов (придуманных, как нам всем известно, шайтаном, с которым, эти инженеры, наверняка, имеют прямые родственные связи), а также испытывать алгоритм выбора маршрута на соответствие заявленному, не доверяя до конца RFC 4274. Вследствие действий этой группы лиц по предварительному сговору (инженеров, а далее – сил зла), в благостной тишине нашего отдела всё чаще и чаще раздавались звонки. Дословное содержание звонков мне неизвестно, но судя по появлению первых седых волос на голове начальника отдела (что при его причёске “под ноль” — довольно тревожный знак) и по его богатой мимике, при пересказе мне впечатлений пользователей сервиса о качестве его (сервиса) предоставления, ситуация требовала оперативного вмешательства.

По результатам непродолжительного мозгового штурма командой высокопрофессиональных сетевых инженеров (мной), было решено подключить резервный канал. Но так как борьба разворачивалась не за определённый участок трассы, который можно было бы тречить по sla и в случае чего преключать канал с основного на резервный, а с силами зла, серьёзно взявшимися за изучение BGP, то необходимо было настроить доступность сервера на обоих каналах единовременно (Рис 1). И в случае недоступности первого адреса из какой-то автономки (откуда то адрес мог быть доступен, а откуда то нет), пользователь бы подключался на второй, но в тоже время другие пользователи, могли бы иметь доступ к серверу, обращаясь на первый адрес.
image
Рис1.

NOTE: Была конечно мыслишка самим взяться да и использовать орудие врага супротив него, но так как при каждом упоминании о BGP весь отдел вскакивал и осенял округу крёстными знамениями, то решено было в RIPE с челобитной не писать, Бога не гневить.

Итак, имея на руках условия и ограничения при решении задачи, было найдено решение, использующее следующие средства: NAT, static routes, route-maps. Рассмотрим данное решение на примере, приведённом на рисунке 2. Схеме адресации в примере использует только приватные адреса. Адреса на участке между офисным маршрутизатором (R1)и гейтом (R2)первого оператора связи (ISP1) изменены на 172.16.12.0/29, а между офисным маршрутизатором (R1)и гейтом (R3) второго оператора связи (ISP2) на 172.16.13.0/29. Локальная сеть, как в жизни, так и в примере использует приватные адреса сети 192.168.1.0/24, где 192.168.1.1 принадлежат маршрутизатору, а 192.168.1.31 серверу.

R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.16.12.1 YES NVRAM up up
FastEthernet0/1 172.16.13.1 YES manual up up
FastEthernet1/0 192.168.1.1 YES NVRAM up up


Для НАТа сервера определим следующие ip адреса в пуле каждого из провайдеров:
ISP1: 192.168.1.31 -> 172.16.12.4
ISP2: 192.168.1.31 -> 172.16.13.4

image
Рис2.

Настраиваем доступность сервера на канале первого провайдера -ISP1.
Дефолтный маршрут через первого провайдера:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2

Определяем интерфейсы, используемые при НАТ трансляциях:
R1(config)#int fa 0/0
R1(config-if)#ip nat outside
R1(config-if)#int fa 1/0
R1(config-if)#ip nat inside


Натим сервер
R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable

На этом всё – сервер доступен для пользователей по адресу 172.168.12.4, и это, безусловно, нестоящий пристального рассмотрения участок настройки, но для общей картины, тем не менее, необходим.
Теперь переходим к настройке доступности сервера на канале второго провайдера -ISP2.
Определяем интерфейсы, используем при НАТ трансляциях:
R1(config)#int fa 0/1
R1(config-if)#ip nat outside


Натим сервер
R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable

И вот теперь мы подошли к наиболее интересному вопросу – как направить ответы от сервера через интерфейс FastEthernet0/1, в случае если клиент пришел через ISP 2. Первое, что приходит на ум, и как выяснилось далее (выяснение велось, посредством нескольких весьма эффективных процедур, заимствованных у испанского отделения трибунала священной канцелярии инквизиции, и результаты сомнению не подлежат) является верным решением – это использование route-map. Итак, на интерфейсе fa1/0 нам необходимо перехватить пакеты, возвращающиеся к клиентам, пришедшим через ISP2. Как заmatchить эти пакеты пока не совсем понятно. Source адрес пакета одинаков – 192.168.1.31, Destination тоже никоим образом не идентифицирует интерфейс, с которого пакет попал на маршрутизатор. Напряжение росло, решение не приходило. Перспективы повторных встреч с коленоликой соблазнительницей уменьшались. После обильного гугления и прочтения трактата “Camouflage and Art: Design for Deception in World War 2. Unicorn Press” решение пришло — вносим в конфигурацию, и чуть позже объясним.
R1(config)#ip nat pool ISP_2nd 192.168.133.0 192.168.133.254 prefix-length 24
R1(config)#access-list 100 permit ip any host 172.16.13.4
R1(config)#ip nat outside source list 100 pool ISP_2nd add-route


Для пакетов приходящих на интерфейс fa 0/1 от второго провайдера мы транслируем адреса пользователей (source ip address) в пул 192.168.133.x/24 и теперь возвращающиеся пакеты к пользователям, обратившихся к серверу через второго оператора, будут на интерфейсе fa 1/0 иметь поле dst ip addr=192.168.133.x что позволит нам провернуть следующие:

R1(config)#access-list 101 permit ip any 192.168.133.0 0.0.0.255
R1(config)#route-map 2ISP permit 10
R1(config-route-map)#match ip address 101
R1(config-route-map)#set ip next-hop 172.16.13.3
R1(config-route-map)#exit
R1(config)# int fa 1/0
R1(config-if)#ip policy route-map 2ISP


И вуаля — работоспособное решение готово. Краткий отчёт руководству, имплементейшн и … казалось бы – закатывай той, лей вино, жги близлежащие деревни, в общем отмечай как обычно выполнение планов за месяц и радуйся жизни, но… но нет. Собрав лабу в GNS3 и, пожалев ресурсов на два клиентских хоста, ограничился одним и заметил следующую особенность – если клиент соединяется с сервером через второго оператора связи на адрес 172.16.13.4 в НАТ трансляциях у нас появляются следующие строчки:
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- --- --- 192.168.133.1 ZZ.ZZ.ZZ.ZZ
tcp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.1:59324 ZZ.ZZ.ZZ.ZZ:59324


Особое внимание обращаем на первую строчку. Теперь если в силу каких либо причин пользователь будет разъединён и переподключится на адрес 172.16.12.4 через ISP1, source address пакетов идущих от него также будет транслирован в пул 192.168.133.x/24 и пакеты от сервера идущие к нему попадут под route-map и будут выкинуты через интерфейс fa0/1 в сеть ISP2. И если трансляция

tcp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.136:59324 ZZ.ZZ.ZZ.ZZ:59324

со временем заэкспайрится и трансляция очиститься по истечению тайм аута, то первая так и остаётся висеть, что создает, согласитесь, серьёзную проблему. И, как говорилось в рекламе, – «Чем я его только не пробовала!», был испробован и дополнительный NAT на первом fa 0/0, и попытки локализовать второй интерфейс в VRF, и NAT NVI, и щедрые кровавые воздаяния уссурийскому мифическому тигру — «дусэ», и даже верный способ выстраивания 7 девственных дев (нагих ессесно, это ритуал, а не утренник в младшей школе) в звезду Давида вокруг маршрутизатора, глаз усладил, но желаемого результата не принес (хотя судя по томным лицам некоторых коллег выбегающих из кабинета в ходе обряда – желаемые результаты у всех разные). Ситуация требовала оперативного сбора всё той же команды высокопрофессиональных инженеров (не путать с инженерами сил зла), и она (ситуация) этот сбор получила. Ну а дальше всё по накатанной схеме – мозговой штурм, решение найдено, имплементейшн, отчёт начальству, той с кровавыми воздаяниями, алое зарево над Сосновкой и т.д.

Ну, приступим быстрее к рассмотрению. Никаких критических изменений топология не притерпивает, единственно добавляется интерфейс loopback 0 c ip адресом 10.0.0.1/32. Что касается используемых IOS features, то это будет опять policy based routing.
image
Рис 3.

Производим конфигурацию (конфигурация производится с 0 – предыдущие настройки удалены).
Определяем интерфейсы для NAT трансляций:
R1(config)#int fa 0/0
R1(config-if)#ip nat outside
R1(config-if)#int lo0
R1(config-if)#ip nat outside
R1(config-if)#int fa 1/00
R1(config-if)#ip nat inside


Особенно стоит отметить, что теперь интерфейс fa 0/1 в операциях NAT не участвует.

Добавляем правила NAT:
R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable
R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable


Дефолтный маршрут через первого провайдера:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2

Итак, доступ через fa0/0 (через ISP1) уже обеспечен, а что касается работы через второго оператора то, если вы ещё не догадались, идея такова, что вместо того чтобы производить NAT трансляцию на интерфейсе fa0/1, мы будем перенаправлять входящие пакеты с этого интерфейса на интерфейс lo0 и натить сервер в 172.16.13.4 там. Это даст нам в последствие возможность при помощи route-map на lo0 отследить пакеты от сервера, которые должны возвращаться через второго провайдера и перенаправить их через fa 0/1 в обход GRT (general routing table). Итого в этом действе будет задействовано 3 route-map:
R1(config)#ip access-list extended from_2ndISP
R1(config-ext-nacl)#permit ip any host 172.16.13.4
R1(config-ext-nacl)#route-map from_2ndISP permit 10
R1(config-route-map)#match ip address from_2ndISP
R1(config-route-map)#set interface Loopback1
R1(config-route-map)#int fa 0/1
R1(config-if)#ip policy route-map from_2ndISP


Эта роут мапа (from_2ndISP) будет перенаправлять все пакеты пришедшие на интерфейс fa0/1 на интерфейс lo0 где будет происходить NAT трансляция и дальнейшая маршрутизация пакетов к серверу посредством connected маршрута в GRT.

Далее,
R1(config)#ip access-list extended srv_2_loop
R1(config-ext-nacl)#permit ip host 192.168.1.31 any
R1(config-ext-nacl)# route-map srv_2_loop permit 10
R1(config-route-map)#match ip address srv_2_loop
R1(config-route-map)#set interface Loopback1
R1(config-route-map)#int fa 1/0
R1(config-if)#ip policy route-map srv_2_loop


С помощью этой роут мапы (srv_2_loop) все пакеты идущие от сервера будут перенаправлены на интерфейс lo0, причём в input queue на интерфейс пакеты попадут уже после прохождения обратной NAT трансляции (в source поле будет уже не 192.168.1.31 а 172.16.13.4 для сессий инициированных через второго оператора связи), что позволит нам
R1(config)#ip access-list extended back_2ndISP
R1(config-ext-nacl)#permit ip host 172.16.13.4 any
R1(config-ext-nacl)# route-map back_2ndISP permit 10
R1(config-route-map)#match ip address back_2ndISP
R1(config-route-map)#set ip nex-hop 172.16.13.3
R1(config-route-map)#int fa lo0
R1(config-if)#ip policy route-map back_2ndISP


пакеты с source 172.16.13.4 перенаправить на шлюз второго оператора связи, а всё что не попало под acl back_2ndISP будет cмаршрутизировано при помощи GRT.

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

За сим оставляю Вас за осмысливанием (возможно кому то было откровение после прочтения, так что не торопитесь), а сам пойду прогуливаться по живописным набережным, освежая окружающий пейзаж своей статной фигурой под бежевым кружевным зонтом.

Используемая литература:

Jeff Doyle, Jennifer DeHaven Carroll. Routing TCP/IP, Volume II (2001 CiscoPress)
И. А. Крывелев. Костром и пыткой против науки и ученых (1933; переизд., 1934).
М. М. Шейнман. Огнем и кровью во имя бога (1924); Папство (1959); От Пия IX до Иоанна XXIII (1966).
И.О. Сусанин. Спортивное ориентирование и азы пользования ГЛОНАСС (2010; Полит Издат.)
Share post

Similar posts

Comments 30

    +3
    Тема нужная и полезная, и обфускация текста замечетельная :)
      0
      Критиковать нельзя хвалить!
        +4
        Обфускация не совсем к месту. Автору надо в литературный кружок. Статья хорошая, но когда настраиваешь киску по чужим мануалам, то не самое удобное время для погружения в мир прозы.
      0
      Обозначте модельку роутера?
        +1
        R1#sh ver
        Cisco IOS Software, 3700 Software (C3725-A3JK9S-M), Version 12.3(14)T7, RELEASE SOFTWARE (fc2)

        Но пока разбирался с поведением NAT outside, менял несколько платформ и IOSов. Решение было испробовано на 2811, 3725 и 3740. На версиях IOS 12.3(x) и 12.4(x).
        +2
        Ах, какой слог!
          0
          забавно. я подобную штуку делал только на 3х маршрутизаторах: два смотрят к двум разным isp, третий во внутреннюю сеть. и на роутерах смотрящих в isp делал одновременно src и dst nat, так чтоб к серверу приходящие пакеты од первого isp имели один src, а от второго isp другой src, и именно так и разделялись каналы.
          а на линупсе с ip tables одновременный src/dst nat для такого случая можно на одной коробке сделать… люблю линупс :)
            0
            Можно. Как раз готовил статью. Но раз тут такое написали про циску — то грех не опубликовать ;)
            –1
            А всего-то можно было серверу два внешних адреса сразу повесить ;).
              0
              я бы сделал (и делал) через nat enable + pbr…
                0
                Смотри первый способ? Про NAT NVI там упомянуто…
                  0
                  там как раз упомянуто, что не получилось. А у меня вроде ничего… Но я не в критику, просто мне кажется изящнее, чем нагружать маршрутизатор, бросая на loopback пакеты (ведь фактически это означает двойную обработку)
                    0
                    Илья, когда то на сером, мне уже давали линк на вашу статью про NAT NVI, возможно это были вы. =) Но:
                    R1#sh ip nat nvi translations
                    Pro Source global Source local Destin local Destin global

                    ------------ OUTPUT OMMITTED ------------

                    tcp 192.168.133.1:16947 ZZ.ZZ.ZZ.ZZ:16947 172.16.12.4:80 192.168.1.31:80
                    tcp 192.168.133.1:19109 ZZ.ZZ.ZZ.ZZ:19109 172.16.13.4:80 192.168.1.31:80
                    --- 192.168.133.1 ZZ.ZZ.ZZ.ZZ --- ---


                    Как видите, поведение абсолютно идентичное тому, с которым я столкнулся при использовании NAT. Просто так бы не писал. Мне было бы очень любопытно увидеть конфиг и версию IOS на котором это работает иначе — с удовольствием добавлю ещё один способ решения с ссылкой на Вас.

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

                        ip nat inside source static 192.168.1.31 172.16.12.4 extendable
                        ip nat inside source static 192.168.1.32 172.16.13.4 extendable


                        :) без заморочек и хитростей. а NVI тут не поможет, согласен
                          0
                          И у Вас это работало?
                          Не могли бы Вы описать чуть подробнее. Сейчас бьюсь над решением задачи, описанной вами в заголовке топика. Но никак не выходит у меня каменный цветок.

                          Одновременная доступность без BGP, я так понял, недостижима. Но PAT с разных IP думаю реален. Но как-то не получается у меня победить 15.0.1
                        0
                        ответил сам себе чуть ниже…
                  0
                  Спасибо, поржал. Я, конечно, не о сути, а о слоге. Видимо, вместе с последней сожженной деревней сгорел мешок чего-то веселящего-)
                    0
                    Феерично. Подача материала оценена мною на 6 баллов по двух-бальной шкале.
                    Сейчас сам ломаю голову над подобной задачей, но есть два но:

                    НО №1 — DMVPN Ph1
                    НО №2 — Не считаю себя гуру по «кошкам».

                    Отсюда 2 вопроса — это можно адаптировать для VPN или не получится, и ломать голову и железо не стоит? Меня терзает сомнение, которое растет из природы VPN, что туннель не поднимится после удара в горе-бубен на стороне одного из провов. Или я все-же не прав. Железо 12 x 2811 (12.4 AdvSec)
                      0
                      да почему, можно все (правда не я автор) :)
                      0
                      скажите, а зачем цизко? Ж))) любая современная ОС для сервера умеет посылать обратно пакеты в тот аплинк с которого они пришли. например в линуксе это реализуется тремя коммандами iptools'ами. в free/open bdsm есть fib'ы и routing-domains соответственно, у solaris'а есть crossbow…

                      вы еще взяли cisco _маршрутизатор_ для того что бы делать nat, — решение годное лишь для очень не больших нагрузок. при возрастании до сколько бы то ни было приличного количества сессий оно будет загибаться. нужно было брать какой из фаерволов: pix, asa. но я щитаю, дешевле и удобнее nat'а чем на писюках нет нигде в лоуэнде.

                      а так вы конешно большой молодец: не только решили проблему но и статью написали. к сожалению, не имею возможности кинуть вам в карму плюсик.
                        +1
                        Ну, как то не странно, но бывают места где наличие Сisco идёт по дефолту, а наличие линуксов (подставить нужное) в качестве маршрутизатора, а тем более установка их ради одного сервиса выглядит довольно нелепо, ну или просто невозможна. Поэтому делалось на том что делалось. =) Насчёт нагрузок всё верно, они не большие — около полусотни единовременных трансляций, но 2811 с 2 гигами оперы на борту выдержит и много больше.

                        А так, если придерживаться такой точки зрения, то ваш вопрос: — скажите, а зачем цизко? Ж))) можно разместить жирным шрифтом на странице блога Cisco, а постинг тут запретить за ненадобностью. :-)
                        0
                        Существует более комфортное решение данной задачи, которое, в частности внедрили у нас в офисе на маршрутизаторе с ценой до $100.

                        Исходные данные:
                        два канала к ISP, при чем разной природы: один скоростной ethernet со статикой, второй — резервный pppoe линк через adsl модем с плавающим ip.

                        Цель: обеспечить схему бесперебойной работы терминального сервера наружу.

                        Средство: покупка VPN PPTP туннеля с постоянным честным ip (за совсем недорого), настройка на офисном маршрутизаторе поднятие PPTP туннеля и получение этого самого IP.

                        Готово.

                        Пользователь на самом деле подключался на ip предоставленный pptp туннелем, а этот самый pptp туннель поднимался на любом из живых каналов. Чистый profit.
                          0
                          Только вот одна проблема — по такому VPN кроме сайтов и интернета ничего гонять низзя. Нет, физически то можно, но вот с точки зрения ИБ такое решение очень сомнительно. Можно и свой туннель поднять внутри, но производительность такоего решения, опять же…
                          Если задача — дать доступ к сайту или публичному FTP — то может и сойдет, а вот объединять сети или терминал вывешивать — я бы не рискнул. Куда рациональнее поднять свой VPN-сервис с балансировкой, а пользователи пусть к нему цепляются и работают уже.
                          Как говорят — «Лучшк перебдеть, чем не добдеть»
                          0
                          Вариант с reflexive ACL рассматривали?
                            0
                            То решение с reflexive acl, что я себе представляю, содержит в себе 4 роутмапы, 2 лупбек интерфейса, акссес групу на каждом лупбеке и 2 рефлексив листа изспользуюшихся в роутмапах.
                            Оно ужастно. Оно просит пристрелить его.
                            0
                            Не знаю как остальным, но вид подачи материала слишком часто отвлекает… может хотя бы разграничивать лирическую и техническую части, раз уж так хочется «излить душу»? )
                              –1
                              нет.
                              0
                              Господа, а каким образом будут передаваться на сервер src_ip? В логах Apache, например, есть необходимость отслеживать все ip адреса, с которых заходили клиенты. Приложение, которое крутится на Apache, на основе src_ip должно отображать определенный контент. Как тут быть?
                                0
                                без слёз не взглянешь. простейшая задача, которая на junuper решается в два счета (да что там на juniper, даже на mikrotik!) на cisco превращается в ламбаду.

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