Толчок. За ним ещё один, сильнее. Вот и всё. Перед глазами проносились альпийские луга, и девушка в бежевом сарафане, игриво крутя в точёных ручках кружевной зонтик проносилась мимо тоже. Проносилась, не сбавляя скорости, несмотря на то, что я тянул к ней свои менее точенные, но крепкие ручонки, а также жестами и мимикой изображал, в меру сил своих, какой всесторонний кундюшок её может ожидать, раскинь она мне руки навстречу (ну или ещё что раскинь).
Но случилось что случилось, и лишь ловко выхваченный зонтик из её, кстати, не только точённых но и цепких рук, немного оттенял розовыми тонами последние секунды моего пробуждения и согревал разбитое сердце (без зонтика, закрывающего её шевелюру, девушка оказалась на поверку немного, мягко говоря, плешиватой). Открыв глаза я, как то не странно, увидел себя не посреди развалин Ниигаты, и сразу отринул сейсмическую природу толчков. Немного отлегло. Перестал кричать – «Покинуть корабль!». С укором взглянул на начальника отдела трясущего меня за плечо. Который, вместо извинений принёс мне весть, что нас с ним ожидают у директора, для постановки одного маленького, но очень ответственного задания. Не приняв его слова близко к сердцу, я несколько раз пытался вернуться к своей плешивой искусительнице, но начальник продолжал проявлять чудеса настойчивости. Пришлось идти.
Опущу момент пребывания в кабинете у директора и процесс постановки нам боевой задачи — ни к чему вам знать подробности этих преступных сцен преисполненных плохо завуалированных угроз и открытого шантажа, слёз и мольб с показыванием фотокарточек приёмных детей своих родителей, и вздыманием рук над головой, полных отчаяния просьб не губить и бросания трубок с уже набранным номером следователя комитета безопасности (были… были, как видите, и у меня на такой случай козыри в рукаве — а раньше нужно было думать, отчего я так рьяно бросался лично проверять настройки вай-фай на директорских лэптопах, а теперь как говориться — «Who is your Daddy now, darling? А? А БЛ###Ь!?»). Но, так или иначе, задача, была поставлена, и стояла она в полотне Project сервера так, что у увидевших её молоденьких девушек рделись щёки, а прочий женский коллектив с некоторым, знаете ли, отвращением поглядывал на фотокарточки своих рахитичных половинок, стоящих на углах столов пожилых прелестниц. Пути назад не было – задачу нужно было решать.
Итак, суть – необходимо было обеспечить удалённый доступ к некоему серверу для группы лиц, для совершения оными на оном сервере действий явновыраженного коррупционного характера, не терпящих отлагательств и неприемлющих простоя. Сетевая часть данной задачи тяжелым бременем взгромоздилась на мои хрупкие плечи и крепко обняла за шею. Становилось трудно дышать и подниматься по лестницам на верхние этажи.
Вернувшись в кабинет, я сел крепко думать над поставленной задачей и способами получения загранпаспорта из ломбарда назад, не возвращая денег. «Ну что, случиться то может» – успокаивал я себя, — «Интернет у нас стабильный, включу шнурочек, и пущай себе работает, на радость людям и прочему преступному элементу». Отчитавшись начальству, что «Вероятность падения канала – КРАЙНЕ!!! КРАЙНЕ МАЛА!!!», и, приняв эту мысль за аксиому, я, счастливо улыбаясь, вернулся к просмотру видений с лысоватыми девушками в розовых сарафанах. Но, как назло, пытливые умы инженеров нашего уездного оператора связи в аккурат в это время начали подбираться к трём (крайне неприятным мне с той поры) буквам – BGP, и активно осваивать всяческие изыски фильтрации path атрибутов (придуманных, как нам всем известно, шайтаном, с которым, эти инженеры, наверняка, имеют прямые родственные связи), а также испытывать алгоритм выбора маршрута на соответствие заявленному, не доверяя до конца RFC 4274. Вследствие действий этой группы лиц по предварительному сговору (инженеров, а далее – сил зла), в благостной тишине нашего отдела всё чаще и чаще раздавались звонки. Дословное содержание звонков мне неизвестно, но судя по появлению первых седых волос на голове начальника отдела (что при его причёске “под ноль” — довольно тревожный знак) и по его богатой мимике, при пересказе мне впечатлений пользователей сервиса о качестве его (сервиса) предоставления, ситуация требовала оперативного вмешательства.
По результатам непродолжительного мозгового штурма командой высокопрофессиональных сетевых инженеров (мной), было решено подключить резервный канал. Но так как борьба разворачивалась не за определённый участок трассы, который можно было бы тречить по sla и в случае чего преключать канал с основного на резервный, а с силами зла, серьёзно взявшимися за изучение BGP, то необходимо было настроить доступность сервера на обоих каналах единовременно (Рис 1). И в случае недоступности первого адреса из какой-то автономки (откуда то адрес мог быть доступен, а откуда то нет), пользователь бы подключался на второй, но в тоже время другие пользователи, могли бы иметь доступ к серверу, обращаясь на первый адрес.
Рис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
Рис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. И если трансляция
t
cp 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.
Рис 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; Полит Издат.)
