Policy-based Routing (PBR), как основное назначение (Часть 2)

Как сказали в комментариях к первой статье, что могут руки не дойти до второй статьи, как в воду глядели. Она лежала незавершенная очень долгое время. Сейчас подогнал чуть-чуть, только пришлось отказаться от многих деталей и пожеланий, которые высказывались в комментариях к первой части. Но думаю интерес все таки вызовет данное продолжение статьи, хоть и высказывались, что PBR банальная и избитая тема. В прочем я согласен, но что бы писать следующую статью все таки нужно завершить начатое ранее.

Кому интересно продолжение статьи добро пожаловать под кат

Для дальнейшего знакомства с PBR, я набросал виртуальную схему офиса. Состоит она из 3-х маршрутизаторов, коммутатора, 2-х серверов и символического клиента, который в единственном лице представляет пользовательские ПК: 1. Маршрутизатор нашего офиса (R1). 2. Маршрутизатор провайдера основного (ISP1). 3. Маршрутизатор резервного провайдера (ISP2). 4. Почтовый сервер (mail) 5. Прокси-сервер (proxy) 6. Коммутатор (ws1) 7. Клиент (PC)

Так же, я не отобразил на схеме удаленный офис, но в статье он будет подразумеваться. И так легкое описание схемы. Есть у нас сеть пользователей, 192.168.0.0/27 им нужны сервисы такие как, внутренняя почта, интернет, и другие которые в нашей схеме не зафиксированы. Сервера будут жить у нас в сети 192.168.0.32/29 (на схеме отражены 2 сервера, сервер внутренней почты, и proxy-сервер). Ну и внешние сети (я возьму серые сети, подразумевая под ними белые). Итого получим следующий адресный план.

Исходные данные, мы отобразили теперь перейдем к конфигурации оборудования, вначале я настрою оборудование офиса виртуального, как говориться «что бы работало» (полные конфигурации не буду приводить так, как статья про PBR). При переносе исходных данных в конфигурацию мы получаем, вот такое:

R1#sh run | b int interface Tunnel1 description ### tunnel over ISP1 ### ip address 192.168.1.1 255.255.255.252 tunnel source 10.1.1.2 tunnel destination 10.0.0.2 ! interface Tunnel2 description ### tunnel over ISP2 ### ip address 192.168.2.1 255.255.255.252 tunnel source 10.2.2.2 tunnel destination 10.0.0.2 ! interface GigabitEthernet0/0 no ip address duplex auto speed auto ! interface GigabitEthernet0/0.10 description ### client network ### encapsulation dot1Q 10 ip address 192.168.0.1 255.255.255.224 ! interface GigabitEthernet0/0.20 description ### servers network ### encapsulation dot1Q 20 ip address 192.168.0.33 255.255.255.224 ! interface GigabitEthernet0/0.30 description ### proxy out int #### encapsulation dot1Q 30 ip address 192.168.0.65 255.255.255.252 ! interface GigabitEthernet0/1 no ip address duplex auto speed auto ! interface GigabitEthernet0/1.40 description ### ISP1 p-to-p ### encapsulation dot1Q 40 ip address 10.1.1.2 255.255.255.252 ! interface GigabitEthernet0/1.50 description ### ISP2 p-to-p ### encapsulation dot1Q 50 ip address 10.2.2.2 255.255.255.252

Конфигурацию Коммутатора ws1, я приводить не буду. Поверим на слово что все порты в своих вланах, порты, в mode trunk, пропускают только нужные вланы. Аналогично можно сказать про сервера, они настроены и корректно отрабатывают свою задачу.

Итак вот у нас есть виртуальный офис, и хотим мы контролировать пользователей, считать трафик и т.п. для этого у нас есть proxy сервер(далее просто proxy), следовательно нам нужно завернуть трафик от пользовательской сети, на proxy. Задача есть, приступаем к решению. Для начала нужно выбрать сеть для которой мы будем «рисовать» карту маршрутизации. Это можно делать 2-мя способами через ACL, или метить (применять) трафик, который проходит через логический интерфейс, направляем на porxy. делаем карту либо так:

access-list 101 permit ip 192.168.0.0 0.0.0.31 any ! route-map client permit 5 match ip address 101 set ip next-hop 192.168.0.35

либо так: route-map clientif permit 5 match interface GigabitEthernet0/0.10 set ip next-hop 192.168.0.35 есть еще способ, без применения параметра, match, просто вешается карта с параметром set на интерфейс, но я не уверен в 100 процентной работоспособности, и чревато последствиями, применение его (теоретически), кому интересно можете попробовать посмотреть.

Что мы получаем в итоге. Весь клиентский трафик пойдет у нас на proxy, и дальше proxy уже будет думать советуясь со своей таблицей маршрутизации куда трафик отправить. При такой картине, у нас появляется маленький нюанс. Клиенты (MUA), обращаются к почтовому серверу (MTA), через лишний хоп (proxy), а это уже возможная лишняя проблема предоставления услуг, в частности потового сервиса. Ведь администраторы proxy, могут не только к примеру перегружать сервер, но и вывести из строя работоспособные настройки, да и банальная поломка железа на сервере, а вас как назло нет на месте и нет доступа к роутеру. В общем не совсем корректно, тут лучше обойти этот лишний хоп. Делается это тоже несколькими способами:

1. Способ это — прописать вместо ip next-hop, ip default next-hop. Тем самым карта не будет отрабатывать для mail, так как, он у нас находится в глобальной таблице маршрутизации в сети которая directly connection.

2. Способ переписать наш акцесс лист access-list 101 deny ip 192.168.0.0 0.0.0.31 host 192.168.0.34 access-list 101 permit ip 192.168.0.0 0.0.0.31 any Естественно, тут можно модифицировать, к примеру, что бы у нас обращение клиентов к серверам шло напрямую без участия proxy, тогда вместо: access-list 101 deny ip 192.168.0.0 0.0.0.31 host 192.168.0.34 пишем access-list 101 deny ip 192.168.0.0 0.0.0.31 192.168.0.34 0.0.0.31

Или нарисовать карту с портами. Т.е. к примеру вы хотите контролировать доступ по RDP, на proxy, но клиенты по почтовым портам ходили на прямую, то рисуем так листы:

access-list 101 deny tcp 192.168.0.0 0.0.0.31 host 192.168.0.34 eq smtp access-list 101 permit ip 192.168.0.0 0.0.0.31 any

И так у нас 2 провайдера. Для начала настроим общение нашего роутера с провайдерами. Перво-наперво нарисуем, что бы интерфейсы на роутере отвечал через свой шлюз, это для того что бы избежать петли маршрутизации, т.е. откуда пакет пришел в наш роутер туда он и уйдет. Картину, которую мы пытаемся избежать, выглядит так: у нас есть один из шлюзов в интернет 10.1.1.1, прописан он на роутере как маршрут по умолчанию. При попытки попасть из интернета на роутер по адресу 10.2.2.2, до него пакеты дойдут, но в ответ он будет отправлять через шлюз 10.1.1.1 так как, он у нас маршрут по умолчанию. А там и канал может «лежать» и просто провайдера оборудование не будет знать про сеть 10.2.2.0/30, или задержки большие. Делаем следующие шаги: а. Пишем 2 листа для 2-х независимых сетей провайдера. access-list 105 permit ip 10.1.1.0 0.0.0.3 any access-list 106 permit ip 10.2.2.0 0.0.0.3 any б. рисуем карту маршрутизации route-map r1 permit 10 match ip address 105 set ip next-hop 10.1.1.1

route-map r1 permit 15 match ip address 106 set ip next-hop 10.2.2.1 в. Применяем нашу карту, на локальную политику маршрутизатора. ip local policy route-map r1

тут стоит отметить, что при применении карты к ip local policy будет перенаправление трафика, который генерируется на самом роутере, а трафик который не попадает под обработку роут мапа будет действовать согласно, глобальной политики маршрутизатора. Так же у нас есть и другие сети на маршрутизаторе, которые общаются только между сетями непосредственно подключенными к роутеру, для того что бы остальные сети так же имели шлюз по умолчанию достаточно добавить такого рода строку route-map r1 permit 30 set ip next-hop 192.168.1.2 предполагается, что этот хоп находится на удаленном офисе, с которым нужно обмениваться трафиком с оставшимися сетями. Так как у нас 2 туннеля, через 2 провайдера, то тут справедливо сделать резервирование на случай падения основного, туннеля. Это делается с помощью SLA. Его описали в достаточном объеме и не только на хабре, я этот момент опускаю.

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

ip nat source route-map proxy1 interface GigabitEthernet0/1.40 ip nat source route-map proxy2 interface GigabitEthernet0/1.50

А тут «бабац» и не работает трансляция, nat и locacl policy, не отработают, так как для трансляции адресов, необходим маршрут в глобальной таблице маршрутизации. Т.е. необходимость прописать маршруты по умолчанию на 2-х провайдеров, никто не отменял. Ну и трекинг сюда же прикручиваем.

В предыдущей части в комментариях, проскакивали вопросы и пожелания описать загрузку процессора маршрутизатора. Скажу что кушает он мало и видимой нагрузки не заметим. К примеру на каталисте 4948e при роутинге через PBR в районе 3-х гигов загрузки практически не наблюдается. Да и раз уж зашла тема по загрузке. То Скажу PBR с версии 12.0 поддерживает технологию cef (cisco express forvarding) она включена по умолчанию, для того что бы выключить cef для PBR достаточно дать команду ip route-cache policy на интерфейсе который держит карту (естественно на физическом а не на сабинтерфейсе.), который включает тем самым fast-switching который хранит маршруты в кеше и так же не сильно загружает процессор, но c fast-switching не поддерживает команду set ip default next-hop. По этому, думаю стоит не экспериментировать, и использовать cef. Ну и без описания и подробностей, скажу что проверять отрабатывает pbr или нет можно такими коммандами sh route-map all или имя непосредственно карты, наиболее важные данные показываются в виде: Policy routing matches: 76013668 packets, 3726692270 bytes

debug ip policy тут не забываем, что можно положить роутер загрузив cpu ключевые слова policy routed это значит что пакет ушел согласно нарисованой карты, и policy rejected — normal forwarding обратная ситуация, когда пакет пошел согласно глобальной таблицы.