Чуть больше года назад, я уже писал о инструментах подобных tcpdump в cisco рутерах и файрволлах. Напомню вкратце, для PIX/ASA существует удобный инструмент capture с помощью которого можно захватывать и просматривать трафик, для IOS приходилось довольствоваться командой дебаг предварительно уточнив её с помощью access-list.
В свеженькой версии IOS 12.4(20)Т появилась новый и удобный функционал решающий эту проблему более элегантно. Конечно, версия достаточно новая и мало кто рискнет поставить её в реальную работу, но рано или поздно функционал появится и в стабильных версиях.
Первым делом необходимо создать буфер в который будут складывается пойманные пакеты. Как видно из команды ниже буферов может быть много и самых разных.
// buf1 - название буфера
// size и max-size - размер буфера и максимальный размер элемента в буфере, соответственно
// circular или linear - тип буфера, будут ли старые элементы вытеснятся новыми или нет
R2#monitor capture buffer buf1 size 256 max-size 256 circular
Далее создадим "точку ловли" (capture point), которая сообщит рутеру где ожидать трафика и в каком направлении он будет двигаться.
// ip cef - метод коммутации, мы используем cef
// cappoint - название точки
// далее следует интерфейс на котором слушать и в каком направлении - в обоих
R2#monitor capture point ip cef cappoint fa 0/0 both
После создания, появится следующее сообщение с логах.
*Oct 27 15:23:23.859: %BUFCAP-6-CREATE: Capture Point cappoint created.
Следующий шаг - ассоциация созданной точки с буфером, так как и точек и буферов может быть достаточно большое количество, это просто указывает в какой буфер складывать пакеты.
// синтаксис просто, даже не знаю что писать - всё очевидно
R2#monitor capture point associate cappoint buf1
// Проверить конфигурацю можно следующей командой
R2#show monitor capture point all
Status Information for Capture Point cappoint
IPv4 CEF
Switch Path: IPv4 CEF , Capture Buffer: buf1
Status : Inactive
Configuration:
monitor capture point ip cef cappoint FastEthernet0/0 both
Всё готово для траблшута, осталось только включить. В данный момент статус - Inactive.
// Включаем. В данном случае all, но можно включить и отдельную "точку" по имени
R2#monitor capture point start all
Появится следующее сообщение в логах.
*Oct 27 15:25:05.195: %BUFCAP-6-ENABLE: Capture Point cappoint enabled
// проверим статус еще раз, как можно заметить статус изменился на активный
R2#show monitor capture point all
Status Information for Capture Point cappoint
IPv4 CEF
Switch Path: IPv4 CEF , Capture Buffer: buf1
Status : Active
Configuration:
monitor capture point ip cef cappoint FastEthernet0/0 both
Посмотреть что же мы там наловили можно следующей командой
R2#show monitor capture buffer buf1 dump
15:29:24.251 UTC Oct 27 2008 : IPv4 CEF Turbo : Fa0/0 None
67BB35C0: CA000A00 0000C200 08340001 08004500 J.....B..4....E.
67BB35D0: 00640014 0000FE01 946E0A0A 0A020A0A .d....~..n......
67BB35E0: 0A010800 EEC20004 00000000 0000000F ....nB..........
67BB35F0: 8F74ABCD ABCDABCD ABCDABCD ABCDABCD .t+M+M+M+M+M+M+M
67BB3600: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3610: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3620: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3630: ABCD00 +M.
15:29:24.251 UTC Oct 27 2008 : IPv4 LES CEF : Fa0/0 None
67BB35C0: CA000A00 0000C200 08340001 08004500 J.....B..4....E.
67BB35D0: 00640014 0000FE01 946E0A0A 0A020A0A .d....~..n......
67BB35E0: 0A010800 EEC20004 00000000 0000000F ....nB..........
67BB35F0: 8F74ABCD ABCDABCD ABCDABCD ABCDABCD .t+M+M+M+M+M+M+M
67BB3600: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3610: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3620: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3630: ABCD00 +M.
Не слишком понятно, правда? А ведь это был обычный ping, ничего более. Для упрощения анализа полученные данные можно экспортировать в формат pcap и анализировать на PC в любимом инструменте, например wireshark.
//экспорт буфера, вариантов много - tftp, ftp, scp и другие Xtp :)
R2#monitor capture buffer buf1 export (куда)
Но всё таки чего-то не хватает, зачем например собирать данные со всего интерфейса если интересует всего один IP и более того, только один протокол? Конечно решение есть. При создании буфера можно указать фильтр для отбора пакетов из потока. Делается это с помощью access-list.
R2#monitor capture buffer buf1 filter access-list (номер, имя)
Tuesday, October 28, 2008
Sunday, October 5, 2008
Есть браузер – нет проблем. Немного теории и начальная конфигурация.
Недавно мне в руки попала достаточно интересная железяка – Juniper SA-2000, предназначенная для организации построения VPN по технологии SSL. Следующие несколько заметок будут посвящены именно этой теме. В документации производителя она так же называется IVE. Итак, начнем.
Заголовок выбран неслучайно ведь основным преимуществом и отличием SSL VPN от хорошо знакомого IPSec является именно возможность подключится к шлюзу с помощью обычного браузера. Т.е. при полном отсутствии клиентской части, например из гостиницы или интернет кафе.
С технической точки зрения, Juniper, впрочем как и остальные вендоры, предоставляет два основных вида туннелей:
- чистый SSL
- network connect
Чистый SSL
Пользователь, используя обычный http, заходит на страничку удалённого доступа, вводит данные необходимые для аутентификации и попадает на SSL портал. На портале ему могут быть доступны следующие сервисы:
- web доступ, если внутри есть web сервер доступ к которому должен быть защищен это тот самый случай;
- файловый доступ, заворачивает NBT и NFS протоколы в SSL обертку;
- SAM, расшифровывается как Secure Application Manager, представляет собой Java либо ActiveX приложение поддерживающее туннель к заранее известным серверам. Сложно написал, но по-сути это тот же SSH туннель только с помощью SSL;
- Telnet/SSH, Java приложение являющееся клиентом Telnet либо SSH соответственно;
- Terminal Services, такое же Java приложение но для протоколов RDP и ICA;
- Meeting, защищенное место для проведения собраний, тема отдельной заметки по-хорошему;
- Email Client, такое же Java приложение.
Network Connect
В терминологии Juniper называется это называется Network Connect - загружаемое win32 либо Java приложение которое после аутентификации устанавливает виртуальный драйвер и поднимает полноценный VPN туннель. Опять таки двумя различными способами, полноценный IPSec либо заворачивая всё в SSL. Для первого способа необходимо открыть порт udp/4500. Также для NC (Network Connect) необходимо иметь права администратора на клиентском компьютере.
Включаем
Надеюсь я понятно описал возможные опции, теперь перейдем к конфигурации.
Первоначальная конфигурация производится с помощью стандартного консольного соединения. После пары вопросов типа, "а не новый ли это член кластера?" или "согласны ли вы с лицензионным соглашением?", железяка примерно такое меню:
Welcome to the Juniper Networks IVE Serial Console!
Current version: 6.3R1 (build 13557)
Rollback version: 6.2R2-1 (build 13525)
Reset version: 5.1R2 (build 9029)
Licensing Hardware ID: XXXXXXX
Serial Number: XXXXXXXX
Please choose from among the following options:
1. Network Settings and Tools
2. Create admin username and password
3. Display log/status
4. System Operations
5. Toggle password protection for the console (Off)
6. Create a Super Admin session.
7. System Snapshot
8. Reset allowed encryption strength for SSL
10. Toggle SSL HW Acceleration (system will reboot when this setting is modified): off
Choice:
в котром в первую очередь нас должны интересовать два пункта, которые так и называются: первый и второй. :) Первый позволяет указать основные сетевые настройки интерфейсов, в второй создать локального пользователя с правами администратора.
Остальные пункты позволяют просмотреть некоторые локальные логи, перезагрузить, выключить IVE или откатится на предыдущую версию ПО. И еще несколько базовых возможностей.
Описывать настройку сети я не буду, она достаточно тривиальна. После конфигурации сетевых параметров web-интерфейс доступен по адресу: https://<IP_address>/admin. К сожалению в SSL устройствах Juniper не предоставляет возможности управления из командной строки.
Интерфейс
Следующий скриншот может дать определённое представление как выглядит интерфейс. Он кликабелен, можно рассмотреть подробнее.
Описывать интерфейс занятие муторное и бесполезное, потому делать я этого не буду. Однако расскажу о некоторых терминах и принципах конфигурирования.
Начнем с конца.
Первым делом необходимо создать и настроить серверы аутентификации (auth. servers), т.е. место откуда устройство будет черпать информацию о пользователях. Это может быть radius, LDAP, Active Directory, локальная база и еще пара менее популярных вариантов.
Каждому прошедшему аутентификацию пользователю присваивается роль или несколько (User Role). Именно на уровне роли пользователи получают доступ к различным возможностях IVE как например web, network connect или файловый доступ. Отмечу, кроме разрешения на уровне роли, должна быть создана ресурсная политика (Resource Police) разрешающая доступ к данному ресурсу.
Далее необходимо создать пользовательскую область (User Realm), подскажите лучший перевод если знаете. :) В реалме указывается несколько важных параметров: способ которым пользователи будут аутентифицироваться (указывается сервер настроенный в пункте auth. servers) и правила (Role Mapping) по которым пользователь будет оцениваться как подходящий для данной пользовательской роли. Например это может быть требование состоять в определённой группе.
Следующий шаг – страницы входа (Sign-in Page). Достаточно простая вещь позволяет создать страничку с необходимыми настройками как например: фирменный логотип, инструкция по использованию и т.д.
Страница входа назначается политике входа (Sign-in Police), также в политике входа настраивается адрес по которому будет доступна эта страница (например hostname/sign-in page) и user realm который будет использоваться для аутентификации.
Таким образом, в правильном (со стороны пользователя) порядке цепочка будет выглядеть следующим образом:
Sign-in Page -> Sign-in Police -> User Realm -> User Role
Практический пример последует в следующей части, обратите внимание на вопросы.
Вопросы
Я прекрасно понимаю, читать текстовое описание настройки достаточно скучно, не говоря уже о том, что это запутывает. В связи с этим вопрос.
Подскажите каким образом лучше описывать конфигурацию в заметке? С устройствами конфигурируемыми посредством командной строки это достаточно просто, а как быть в случае графического инсталлятора? Пичкать пол-сотни скриншотов для объяснения мне не кажется выходом, описывать по типу пункт меню 1-> Пункт меню 2 -> галочка напротив пункта номер семь тоже достаточно скучно, да и не даст совершенно никакого представления тем у кого нет доступа к железу, а почитать и разобраться всё таки хочется. Может быть делать короткий анонс в блоге, а само описание перенести в презентацию? А может лучше записывать скринкасты? Меня интересует ваше мнение, читатели. :)
Monday, September 8, 2008
Отчет о поездке на FUDCon
На прошедших выходных мне удалось попасть на достаточно интересную конференцию посвященную Linux - FUDCon. Как можно догадаться из названия посвящена она дистрибутиву Fedora пользователем которого я не являюсь. :) Несмотря на это информация была достаточно интересна для меня.Расскажу подробнее об организации мероприятия.
Всё происходило в здании факультета информатики университета имени Масарика в городе Брно. Первые восторги вызвало само здание - отлично оборудованное, чистое и светлое. Всё настолько удобно и практично - наши студенты бы обзавидовались.
В фотографиях можно найти несколько отличных снимков аудиторий. Организация мероприятия, расселение и питание также оказалось на высоте. При этом участие было бесплатным, а некоторых участникам RedHat даже частично компенсировал затраты.
С докладами оказалось хуже.
Нет, темы были интересны и вопросы обсуждались правильные, но всё таки большинство технических людей не умеет читать презентации, что конечно сказалось на качестве.
Однако самое ценное - полученная информация и общение с интересными людьми позволяют закрыть глаза на мелкие недочеты докладчиков. В большинстве случаев, человек который просто ужасно только что прочитал презентацию, оказывался замечательным собеседником.
С докладами оказалось хуже.
Нет, темы были интересны и вопросы обсуждались правильные, но всё таки большинство технических людей не умеет читать презентации, что конечно сказалось на качестве.
Однако самое ценное - полученная информация и общение с интересными людьми позволяют закрыть глаза на мелкие недочеты докладчиков. В большинстве случаев, человек который просто ужасно только что прочитал презентацию, оказывался замечательным собеседником.
Увидел и пощупал знаменитый долгострой - OpenMoko. Даже с двумя разными прошивками - родной и Nokia. На устройстве на фотографии слева установлена qtopia от финнов.
Конечно всем выдавали бесплатные футболки. :)
К сожалению посетить я смог только один день конференции, но зато самый главный. :)
Доклады на которых я присутствовал:
- sec tool. Достаточно простая утилита для анализа конфигураций компьютера. Изначально заложены простые принципы - проверка конфигурационных файлов основных сервисов (как ssh например), прав доступа (если, скажем, установить домашней директории права на запись для всем - утилита выдаст предупреждение).
- oVirt Продукт от Fedora который в идеале не должен уступать коммерческим реализациям VmWare. В качестве сердцевины используется стандартный KVM, также проект предлагает готовые образы "нод" для развертывания. Я так понял это выглядит следующим образом: есть один главный сервер и какое-то количество рабочих лошадок называемых нодами. На ноды устанавливается образы ОС и подключаются к консоли главного сервера. После этого на сервере создается (импортируется) виртуальная машина и всё готово к запуску. Сервер сам выберет ноду из пула которая загружена менее всего и запустит на ней VM. По словам докладчика, если через некоторое время нода даст сбой, то сервер способен перевести виртуальную машину на другую ноду даже без прекращение работы. Я спрашивал про tcp сессии в данном случае - сказали сессис выживут.
- Spacewalk
- sec tool. Достаточно простая утилита для анализа конфигураций компьютера. Изначально заложены простые принципы - проверка конфигурационных файлов основных сервисов (как ssh например), прав доступа (если, скажем, установить домашней директории права на запись для всем - утилита выдаст предупреждение).
- oVirt Продукт от Fedora который в идеале не должен уступать коммерческим реализациям VmWare. В качестве сердцевины используется стандартный KVM, также проект предлагает готовые образы "нод" для развертывания. Я так понял это выглядит следующим образом: есть один главный сервер и какое-то количество рабочих лошадок называемых нодами. На ноды устанавливается образы ОС и подключаются к консоли главного сервера. После этого на сервере создается (импортируется) виртуальная машина и всё готово к запуску. Сервер сам выберет ноду из пула которая загружена менее всего и запустит на ней VM. По словам докладчика, если через некоторое время нода даст сбой, то сервер способен перевести виртуальную машину на другую ноду даже без прекращение работы. Я спрашивал про tcp сессии в данном случае - сказали сессис выживут.
- Spacewalk
Spacewalk это то, что ранее называлось RedHat network и было доступно платным подписчикам. Сейчас (три месяца назад) продукт выпустили в open source и переименовали в Spacewalk. Предназначен для управления большим количеством серверов или рабочих станций под управлением Fedora. Например, если необходимо на 1000 рабочих станций установить новое ПО, добавить пользователя или провести любые другие изменения - то в этом случае Spacewalk то что нужно использовать. Достаточно интересное решение, призвано упростить миграцию на Linux в корпоративном секторе.
- State of RPM Откровенно скучная презентация. Сначала 20 минут рассказывали о истории rpm, упоминая даже о минорных версиях, потом рассказывали что будет с ним дальше (практически никаких изменений, исправление ошибок). Сложилось впечатление, что вся презентация была необходима ради одного слайда - RPM not dead. -) С середины я ушел и перешел на Fedora Ar.
- Fedora Art
Вообщем-то ничего интересного я здесь тоже не увидел.
- State of RPM Откровенно скучная презентация. Сначала 20 минут рассказывали о истории rpm, упоминая даже о минорных версиях, потом рассказывали что будет с ним дальше (практически никаких изменений, исправление ошибок). Сложилось впечатление, что вся презентация была необходима ради одного слайда - RPM not dead. -) С середины я ушел и перешел на Fedora Ar.
- Fedora Art
Вообщем-то ничего интересного я здесь тоже не увидел.
Это была неформальная секция: на травке под деревом собралось пять человек интересующихся развитием интерфейса Fedora и прорисовкой обоев на рабочий стол с её логотипами. У них нашлась бутылка бурчака (молодого чешского вина). Итог - приятно провели время. :)
После краткого курса чешского языка, мы переместились в паб неподалеку и началась не менее интересная неофициальная часть мероприятия.
Ссылки
1. Base WIKI - http://fedoraproject.org/wiki/FUDCon/FUDConPrague2008
2. Фото - http://www.flickr.com/groups/fudconbrno/
На страничке wiki достаточно много ссылок на отчеты и доклады.
Ссылки
1. Base WIKI - http://fedoraproject.org/wiki/FUDCon/FUDConPrague2008
2. Фото - http://www.flickr.com/groups/fudconbrno/
На страничке wiki достаточно много ссылок на отчеты и доклады.
Tuesday, July 15, 2008
Запасной VPN (ipsec failover high availability stateless)
0. Вводная
Думаю не нужно объяснять зачем это нужно и где применяется. Всё просто - если для вас потеря vpn соединения критична и работа останавливается, возможно стоит подумать о конфигурировании некоторой избыточности. Основных подходов в данном случае два:- отказоустойчивый узел из двух или более устройств при этом активным является только одно устройство и данные о сессиях протокола более высокого уровня не синхронизируются между устройствами (stateless);
- отказоустойчивый узел из двух или более устройств, активно только одно, данные о сессиях синхронизированы (stateful).
Как очевидно основное отличие между двумя подходами в том, что при переключении с основного на резервное устройство и наборот текущие сессии ipsec сбрасываются. Конечно ситуация отрабатывается протоколами инкапсулироваными в ipsec пакеты, как tcp/udp, и скорее всего произойдет только некоторое "замораживание" соединения. Из опыта могу сказать, что задержка обычно немногим больше задержки возникающей при создании нового туннеля. Для большинства приложений этого достаточно.
1. Схема
Шифрации подлежит трафик
10.10.200.0/24 <-> 10.10.1.0/24
10.10.100.0/24 <-> 10.10.1.0/24
2. Конфигурация
Удивительно, но процесс настройки оказался достаточно простым. Основой всего является протокол HSRP (если словосочетание незнакомо, крайне рекомендую пройтись по ссылке) и ipsec собственно. Я не буду вдаваться в нюансы настройки HSRP или ipsec, для этого были написаны специальные заметки - HSRP, static ipsec . :)
По сути изменяется всего две команды.
В первую очередь необходимо добавить имя в конфигурацию hsrp
//конфигурация hsrp, добавлено имя
vpn0(config-if)#standby version 2
vpn0(config-if)#standby 100 ip 10.10.11.1
vpn0(config-if)#standby 100 priority 150
vpn0(config-if)#standby 100 preempt
vpn0(config-if)#standby 100 name vpn
Вторая команда - при применении crypto map к интерфейсу указывается имя hsrp группы которая будет обеспечивать отказоустойчивость.
//применение отказоустойчивого vpn
vpn0(config-if)#crypto map cr_outside redundancy vpn
В качестве дополнения приведу полную конфигурацию.
vpn0
Базовая конфигурация
crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.10
set transform-set ts-aes-sha
match address 120
!
interface FastEthernet0/0
ip address 10.10.11.10 255.255.255.0
duplex auto
speed auto
standby version 2
standby 100 ip 10.10.11.1
standby 100 priority 150
standby 100 preempt
standby 100 name vpn
crypto map cr_outside redundancy vpn
!
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.10
set transform-set ts-aes-sha
match address 120
!
interface FastEthernet0/0
ip address 10.10.11.10 255.255.255.0
duplex auto
speed auto
standby version 2
standby 100 ip 10.10.11.1
standby 100 priority 150
standby 100 preempt
standby 100 name vpn
crypto map cr_outside redundancy vpn
!
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255
Совершенна идентична vpn0 за исключением адреса интерфейса и приоритета hsrp
crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.10
set transform-set ts-aes-sha
match address 120
interface FastEthernet0/0
ip address 10.10.11.20 255.255.255.0
duplex auto
speed auto
standby version 2
standby 100 ip 10.10.11.1
standby 100 priority 101
standby 100 preempt
standby 100 name vpn
crypto map cr_outside redundancy vpn
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255
client1
Простейшее из возможного
crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.11.1
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.11.1
set transform-set ts-aes-sha
match address 120
interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
duplex auto
speed auto
crypto map cr_outside
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255
3. Проверка
Проверялось всё это хозяйство путем установки telnet сессии с маршрутизатора srv на client1 и принудительной остановкой интерфейса FastEthernet0/0 на vpn0. Показательно, что сессия telnet при этом не разорвалась хотя "замерла" на примерно 10-15 секунд.
Также необходимо обратить внимание на правильную маршрутизацию внутри vpn рутеров, в моём случае это сделано с помощью простейшей конфигурации ospf, подобной описанной в одной из прошлых заметок, однако можно использовать тот же hsrp с опцией трекинга outside интерфейса.
Thursday, July 3, 2008
Защищая себя (zone-based firewall self)
В предыдущей заметке была рассмотрена функциональность под названием Zone-Based firewall, которую компания Cisco позиционирует как замену достаточно широко используемой CBAC.
Были показаны основные команды конфигурирования и типичный сценарий применения.
К сожалению я совершенно забыл о такой необходимости как защита самого маршрутизатора.
Сегодня поговорим об этом.
Для управлением трафиком предназначенным непосредственно маршрутизатору или трафику создаваемому им самим, в понимании ZBF предназначена специальная зона - self.
Соответственно, да контроля, например, доступа к маршрутизатору из интернета, необходимо создать цепочку (zone-pair) internet -> self и уже в контексте её политики задавать необходимы разрешения..
По умолчанию зона уже создана. Одно из основных отличий от "нормальных" зон - поведение по-умолчанию, трафик к/от self зоны разрешен.
Также отмечу, self зона достаточно обрезана в функциональности инспекция возможна только для протоколов tcp, udp, icmp, H.323
Опять таки, простейший пример конфигурации:
- из интернета запретить всё кроме icmp;
- из интранета, дополнительно к icmp разрешить ssh и https для задач управления.
Значительно облегчит задачу существующий по-умолчанию класс - class-default выделяющий весь трафик, наподобие permit any any acl.
Логичным было бы создать примерно следующую политику:
Были показаны основные команды конфигурирования и типичный сценарий применения.
К сожалению я совершенно забыл о такой необходимости как защита самого маршрутизатора.
Сегодня поговорим об этом.
Для управлением трафиком предназначенным непосредственно маршрутизатору или трафику создаваемому им самим, в понимании ZBF предназначена специальная зона - self.
Соответственно, да контроля, например, доступа к маршрутизатору из интернета, необходимо создать цепочку (zone-pair) internet -> self и уже в контексте её политики задавать необходимы разрешения..
По умолчанию зона уже создана. Одно из основных отличий от "нормальных" зон - поведение по-умолчанию, трафик к/от self зоны разрешен.
Также отмечу, self зона достаточно обрезана в функциональности инспекция возможна только для протоколов tcp, udp, icmp, H.323
Опять таки, простейший пример конфигурации:
- из интернета запретить всё кроме icmp;
- из интранета, дополнительно к icmp разрешить ssh и https для задач управления.
Значительно облегчит задачу существующий по-умолчанию класс - class-default выделяющий весь трафик, наподобие permit any any acl.
Логичным было бы создать примерно следующую политику:
R1(config)#class-map type inspect match-all cm_manage
R1(config-cmap)#match protocol icmp
R1(config-cmap)#match protocol ssh
R1(config-cmap)#match protocol https
R1(config)#policy-map type inspect in-self
R1(config-pmap)#class type inspect cm_manage
R1(config-pmap-c)#inspect
R1(config-pmap)#class class-default
R1(config-pmap-c)#drop
R1(config)#zone-pair security in-self source inside destination self
R1(config-sec-zone-pair)#service-policy type inspect in-self
R1(config-cmap)#match protocol icmp
R1(config-cmap)#match protocol ssh
R1(config-cmap)#match protocol https
R1(config)#policy-map type inspect in-self
R1(config-pmap)#class type inspect cm_manage
R1(config-pmap-c)#inspect
R1(config-pmap)#class class-default
R1(config-pmap-c)#drop
R1(config)#zone-pair security in-self source inside destination self
R1(config-sec-zone-pair)#service-policy type inspect in-self
Но не выходит. :)
Здесь мы сталкиваемся с ограничением на глубину инспекции в self зонах. Как сказано выше, максимальный уровень инспекции в данном случае - L3/L4. При применении получаем сообщение вида:
Здесь мы сталкиваемся с ограничением на глубину инспекции в self зонах. Как сказано выше, максимальный уровень инспекции в данном случае - L3/L4. При применении получаем сообщение вида:
R1(config-sec-zone-pair)#service-policy type inspect out-self
%Protocol https configured in class-map cm_manage cannot be configured for the self zone. Please remove the protocol and retry
Inspect service-policy attachment failed
Заставить злобную железяку всё таки разрешать соединения по протоколам ssh и https можно следующим образом:
R1(config)#access-list 198 permit tcp any any eq 22
R1(config)#access-list 198 permit tcp any any eq 443
R1(config)#class-map type inspect match-any cm_manage
R1(config-cmap)#match protocol icmp
R1(config-cmap)#match access-group 198
R1(config)#policy-map type inspect in-self
R1(config-pmap)#class type inspect cm_manage
R1(config-pmap-c)#inspect
R1(config-pmap)#class class-default
R1(config-pmap-c)#drop
R1(config)#zone-pair security in-self source inside destination self
R1(config-sec-zone-pair)#service-policy type inspect in-self
R1(config)#access-list 198 permit tcp any any eq 22
R1(config)#access-list 198 permit tcp any any eq 443
R1(config)#class-map type inspect match-any cm_manage
R1(config-cmap)#match protocol icmp
R1(config-cmap)#match access-group 198
R1(config)#policy-map type inspect in-self
R1(config-pmap)#class type inspect cm_manage
R1(config-pmap-c)#inspect
R1(config-pmap)#class class-default
R1(config-pmap-c)#drop
R1(config)#zone-pair security in-self source inside destination self
R1(config-sec-zone-pair)#service-policy type inspect in-self
Хочу обратить внимание, что реальной инспекции именно протоколов http и ssh не происходит, пакеты инспектируются до уровня tcp.
Замечу, то что описывается в данной заметке не является официально рекомендуемым способом обеспечивать безопасность самого устройства. Для этого предназначен - Network Foundation Protection, который я надеюсь рассмотреть немного позже.
Вот мы и познакомились с общими концепциями построение брандмауэров от Cisco. Хочется заметить, представленный метод конечно достаточно громоздок и если у вас всего два интерфейса между которыми необходимо настроить инспекцию, возможно классический CBAC в этом окажется удобнее, как минимум объем команд меньше.
Если же конфигурация усложняется, или же имеет свойство изменяться, Zone-Based Firewall именно то решение которое необходимо. Конфигурация гораздо легче читается и поддерживать, расширять, её проще.
Monday, June 30, 2008
Мы будем жить теперь по новому! (zone-based firewall)
0. Ссылки
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_configuration_example09186a00809492a4.shtml
Начиная с версии IOS 12.4(6)T в рутерах Cisco появилась функциональность называемая Zone-Based Firewall, именно она призвана заменить собой классический firewall (CBAC). В чем отличие, какие основные возможности я и попробую ответить в этой заметке.
1. Немного теории
Основное отличие модели ZBF от CBAC в том, что первый, как очевидно из названия, оперирует на уровне зон, второй на уровне интерфейсов. Второе значительное улучшение -позможность применения политики в определенному трафику. Дело в то том, что в классическом CBAC невозможно применять к различные политики к различным группам трафика в пределах одного интерфейса. К примеру, если за внутренним интерфейсом находиться не одна сеть, а несколько, то в случае CBAC применять для них различные политики инспектирования
не представляется возможным. С ZBF же это достаточно тривиальная задача.
Синтаксис конфигурации, называемый Cisco Policy Language (CPL) достаточно похож на MPF в устройствах ASA.
Несколько фактов облегчающих понимание "как это работает".
- Зона может состоять из интерфейса или нескольких интерфейсов.
- Политика применяется к направлению между зонами. Т.е. inside-outside и outside-inside это две разных политики.
- Важное изменение, политика по умолчанию - deny any any.
- Можно использовать CBAC и ZBF одновременно, но на разных интерфейсах.
- Если два интерфейса не принадлежат ни к одной зоне - трафик разрешен.
- Если один из интерфейсов принадлежит к какой-либо зоне, другой нет - трафик запрещен.
- Если два интерфейса принадлежат к разным зонам - трафик запрещен до явного разрешения.
- Трафик в пределах одной зоны не подвергается инспектированию.
Элементы конфигурации:
class-map - служит для выделения конкретного трафика из потока, например с помощью acl или выделение по протоколам. Может быть вложенным, т.е. можно выделить трафик с source 192.168.0.0/24 по протоколу http.
policy-map - применение политики, Существует всего три возможных действия - drop, pass, inspect.
Стенд
Конфигурация сети следующая:
insideA - 10.10.11.1/24
insideB - 10.10.12.1/24
outside - 10.10.10.1/24
dmzA - 10.10.20.1/24
2. Базовая модель
Начнем с простейшей конфигурации. Забудем пока о наличии ДМЗ и решим самую типичную задачу - предоставление доступа в интернет с инспектированием трафика. Все, остальные конфигурации по сути своей будут строиться на этой как на базовой. Здесь же удобно рассмотреть основные командыконфигурирования, комментарии по тексту.
// определим зоны безопасности, в данном случае только две интернет и интранет
// никакого применения политик пока нет - просто имена.
R1(config)#zone security outside
R1(config-sec-zone)#description Big and Scary internet
R1(config)#zone security inside
R1(config-sec-zone)# description Shy and modest intranet
// назначим интерфейсы в зоны, необходимо учитывать,
// что сразу после этого шага любой трафик между зонами будет запрещен
// ouside
R1(config)#interface FastEthernet0/0
R1(config-if)#zone-member security outside
R1(config-if)#description ouside
//inside, растянутый на два интерфейса
R1(config)#interface FastEthernet0/1.800
R1(config-subif)#description insideB
R1(config-subif)#zone-member security inside
R1(config)#interface FastEthernet0/1.900
R1(config-subif)#description insideA
R1(config-subif)#zone-member security inside
Ну вот и отлично, всё что можно запретили - безопасность на уровне. :)
Теперь займемся разрешением.
// определение протоколов по которым пользователям разрешен в интернет,
// например, http, smtp, dns
// class-map может быть двух типов - с логикой AND и с логикой OR. В
// данном случае OR - любой из трех протоколов
R1(config)#class-map type inspect match-any cm_http-dns-smtp
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol smtp
R1(config-cmap)#match protocol dns
// это пример class-map с логикой AND. Данная карта выбирает
// фильтрует трафик с source 10.10.12.0/24 и любым из протоколов http, dns, smtp
R1(config)#access-list 120 permit ip 10.10.12.0 0.0.0.255 any
R1(config)#class-map type inspect match-all cm_insideB_web
R1(config-cmap)#match class-map cm_http-dns-smtp
R1(config-cmap)#match access-group 120
//создание политики
R1(config)#policy-map type inspect in-out
R1(config-pmap)#class type inspect cm_insideB_web
R1(config-pmap-c)#inspect
// Момент истины, создадим цепочку inside -> outside и наделим
// интернетом счастливых пользователей insideB
R1(config)#zone-pair security inside-outside source inside destination outside
R1(config-sec-zone-pair)#service-policy type inspect in-out
Еще раз хочу обратить внимание, при всей этой конфигурации трафик в
пределах зоны, т.е. между интерфейсами insideA и insideB разрешен.
3. Усложненная конфигурация.
Усложняется она использованием ДМЗ, все остальные параметры остаются теми же.
//Определим новую зону и назначим её интерфейсу
R1(config)#zone security dmz
R1(config-sec-zone)#description Controlled DMZ
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_configuration_example09186a00809492a4.shtml
Начиная с версии IOS 12.4(6)T в рутерах Cisco появилась функциональность называемая Zone-Based Firewall, именно она призвана заменить собой классический firewall (CBAC). В чем отличие, какие основные возможности я и попробую ответить в этой заметке.
1. Немного теории
Основное отличие модели ZBF от CBAC в том, что первый, как очевидно из названия, оперирует на уровне зон, второй на уровне интерфейсов. Второе значительное улучшение -позможность применения политики в определенному трафику. Дело в то том, что в классическом CBAC невозможно применять к различные политики к различным группам трафика в пределах одного интерфейса. К примеру, если за внутренним интерфейсом находиться не одна сеть, а несколько, то в случае CBAC применять для них различные политики инспектирования
не представляется возможным. С ZBF же это достаточно тривиальная задача.
Синтаксис конфигурации, называемый Cisco Policy Language (CPL) достаточно похож на MPF в устройствах ASA.
Несколько фактов облегчающих понимание "как это работает".
- Зона может состоять из интерфейса или нескольких интерфейсов.
- Политика применяется к направлению между зонами. Т.е. inside-outside и outside-inside это две разных политики.
- Важное изменение, политика по умолчанию - deny any any.
- Можно использовать CBAC и ZBF одновременно, но на разных интерфейсах.
- Если два интерфейса не принадлежат ни к одной зоне - трафик разрешен.
- Если один из интерфейсов принадлежит к какой-либо зоне, другой нет - трафик запрещен.
- Если два интерфейса принадлежат к разным зонам - трафик запрещен до явного разрешения.
- Трафик в пределах одной зоны не подвергается инспектированию.
Элементы конфигурации:
class-map - служит для выделения конкретного трафика из потока, например с помощью acl или выделение по протоколам. Может быть вложенным, т.е. можно выделить трафик с source 192.168.0.0/24 по протоколу http.
policy-map - применение политики, Существует всего три возможных действия - drop, pass, inspect.
Стенд
Конфигурация сети следующая:
insideA - 10.10.11.1/24
insideB - 10.10.12.1/24
outside - 10.10.10.1/24
dmzA - 10.10.20.1/24
2. Базовая модель
Начнем с простейшей конфигурации. Забудем пока о наличии ДМЗ и решим самую типичную задачу - предоставление доступа в интернет с инспектированием трафика. Все, остальные конфигурации по сути своей будут строиться на этой как на базовой. Здесь же удобно рассмотреть основные командыконфигурирования, комментарии по тексту.
// определим зоны безопасности, в данном случае только две интернет и интранет
// никакого применения политик пока нет - просто имена.
R1(config)#zone security outside
R1(config-sec-zone)#description Big and Scary internet
R1(config)#zone security inside
R1(config-sec-zone)# description Shy and modest intranet
// назначим интерфейсы в зоны, необходимо учитывать,
// что сразу после этого шага любой трафик между зонами будет запрещен
// ouside
R1(config)#interface FastEthernet0/0
R1(config-if)#zone-member security outside
R1(config-if)#description ouside
//inside, растянутый на два интерфейса
R1(config)#interface FastEthernet0/1.800
R1(config-subif)#description insideB
R1(config-subif)#zone-member security inside
R1(config)#interface FastEthernet0/1.900
R1(config-subif)#description insideA
R1(config-subif)#zone-member security inside
Ну вот и отлично, всё что можно запретили - безопасность на уровне. :)
Теперь займемся разрешением.
// определение протоколов по которым пользователям разрешен в интернет,
// например, http, smtp, dns
// class-map может быть двух типов - с логикой AND и с логикой OR. В
// данном случае OR - любой из трех протоколов
R1(config)#class-map type inspect match-any cm_http-dns-smtp
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol smtp
R1(config-cmap)#match protocol dns
// это пример class-map с логикой AND. Данная карта выбирает
// фильтрует трафик с source 10.10.12.0/24 и любым из протоколов http, dns, smtp
R1(config)#access-list 120 permit ip 10.10.12.0 0.0.0.255 any
R1(config)#class-map type inspect match-all cm_insideB_web
R1(config-cmap)#match class-map cm_http-dns-smtp
R1(config-cmap)#match access-group 120
//создание политики
R1(config)#policy-map type inspect in-out
R1(config-pmap)#class type inspect cm_insideB_web
R1(config-pmap-c)#inspect
// Момент истины, создадим цепочку inside -> outside и наделим
// интернетом счастливых пользователей insideB
R1(config)#zone-pair security inside-outside source inside destination outside
R1(config-sec-zone-pair)#service-policy type inspect in-out
Еще раз хочу обратить внимание, при всей этой конфигурации трафик в
пределах зоны, т.е. между интерфейсами insideA и insideB разрешен.
3. Усложненная конфигурация.
Усложняется она использованием ДМЗ, все остальные параметры остаются теми же.
//Определим новую зону и назначим её интерфейсу
R1(config)#zone security dmz
R1(config-sec-zone)#description Controlled DMZ
R1(config)#int fa0/1.700
R1(config-subif)#zone-member security dmz
//выделим сервер или группу подлежащую публикации
R1(config)#access-list 199 remark Publishing web server
R1(config)#access-list 199 permit ip any host 10.10.20.2
//определим по каким протоколам серверы будет виден снаружи
R1(config)#class-map type inspect match-all pub-web
R1(config-cmap)#match access-group 199
R1(config-cmap)#match protocol http
//создадим политику разрешающую доступ
R1(config)#policy-map type inspect www-dmz
R1(config-pmap)#class type inspect pub-web
R1(config-pmap-c)#inspect
//создадим цепочку outside -> dmz
R1(config)#zone-pair security out-dmz source outside destination dmz
Теперь сервер 10.10.20.2 доступен в интернет по протоколу http, если
необходимо добавить еще один сервер достаточно просто изменить acl 199
R1(config-subif)#zone-member security dmz
//выделим сервер или группу подлежащую публикации
R1(config)#access-list 199 remark Publishing web server
R1(config)#access-list 199 permit ip any host 10.10.20.2
//определим по каким протоколам серверы будет виден снаружи
R1(config)#class-map type inspect match-all pub-web
R1(config-cmap)#match access-group 199
R1(config-cmap)#match protocol http
//создадим политику разрешающую доступ
R1(config)#policy-map type inspect www-dmz
R1(config-pmap)#class type inspect pub-web
R1(config-pmap-c)#inspect
//создадим цепочку outside -> dmz
R1(config)#zone-pair security out-dmz source outside destination dmz
Теперь сервер 10.10.20.2 доступен в интернет по протоколу http, если
необходимо добавить еще один сервер достаточно просто изменить acl 199
Sunday, May 4, 2008
Динамический рутинг поверх vpn (ospf over gre ipsec)
0. Зачем
После прочтения заметки о конфигурации gre ipsec может остаться некоторое недопонимание того зачем, собственно, так усложнять достаточно простую первоначальную конфигурацию.
Данная запись призвана ответить на эти вопросы.
Тем читателям, которые попали сюда по поиску из google или еще каким путем я настоятельно рекомендую прочитать предыдущую часть о настройке gre ipsec, а уже потом возвращаться сюда.
Итак речь идёт о запуске динамических протоколов маршрутизации, в данном случае ospf, поверх существующего vpn соединения.
В случае статической конфигурации, необходимо жесткое указание сетей подлежащих шифрованию. Для этого в конфигурации без gre используются crypto acl.
Если же конфигурация сетей меняется необходимо менять и конфигурацию. Представим довольно жизненную ситуацию - головной офис и определённое количество филиалов.
С случае появления в головном отделении новых ip сетей, необходимо произвести перенастройку всех рутеров, как в центрального так и филиальных. При большом количестве филиалов это может быть непосильной задачей.
1. Описание стенда
Настройка продолжается ровно с того места на котором закончилась статья о конфигурировании gre ipsec. Итак у нас есть следующая конфигурации IP сетей.
Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24
Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24
Допустим, что А это филиал, а Б головное отделение. В случае статического ipsec туннеля указание какой трафик подлежит шифрации с помощью crypto acl.
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
В случае gre ipsec необходимо статическим маршрутом указать куда напрявлять трафик для определённой сети.
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10
После этого трафик попадает в туннель, инкапсулируется в gre, а crypto acl настроеные между пирами пропускали его через процедуру шифрации.
Теперь представим, что в центральном офисе (сеть Б) появилась новая сеть, например 10.200.1.0/24, для обеспечения её видимости в филиалах, необходимо либо добавить по строчке вcrypto acl (static ipsec) либо добавить маршрут (gre ipsec ), что конечно не составляет проблемы для десятка устройств. Но мы же помним, что организация у нас большая и туннелей условно бесконечное количество. :)
2. Конфигурация
Простейшая конфигурация ospf достаточно проста и не вызывает особых проблем. Я не буду рассказывать о принципах работы, алгоритме или прочих ньансах работы этого протокола. В сети достаточно много информации по этой теме. Цель данной заметки показать практическое применение и не дать себе забыть эту простую но в то же время крайне эффективную конфигурацию. :)
Описание настройки.
- число после слова ospf обозначает просто номер процесса ospf на данном устройстве, нет смысла стремиться к его идентичности
- логирование изменений
- ключевая строка, описание сети которые будут анонсироваться от данного рутера. О том что такое area можно говорить долго, но не сейчас. Обратите внимание, используется не маска сети, а wildcard, как в acl.
//Настройка ospf. RouterA
RouterA(config)# router ospf 100
RouterA(config-router)# log-adjacency-changes
RouterA(config-router)# network 192.168.1.0 0.0.0.255 area 10
Практически анологична настройка ospf на рутере Б, исключение составляет дополнительная сеть.
//Настройка ospf. RouterB
RouterB(config)# router ospf 100
RouterB(config-router)# log-adjacency-changes
RouterB(config-router)# network 10.150.1.0 0.0.0.255 area 10
RouterB(config-router)# network 192.168.2.0 0.0.0.255 area 10
В принципе в документации сказано о том, что для указания процессу ospf работать на конкретном интерфейсе необходимо указать сеть относящуюся к данному интерфейсу в конфигурации network.
Т.е. в данном случае сети 10.10.11.0/24 и 10.10.10.0/24 также должны быть указаны. Если у вас версия IOS менее чем 12.4 так и придется сделать. Я же сделаю немного по-другому.
//Настройка ospf. RouterA
RouterA(config)# interface Tunnel10
RouterA(config)# ip ospf 100 area 10
Это просто указание процессу работать на данном интерфейсе. Об этом трюке я узнал от простого словацкого парня Ивана, чей блог я с удовольствием читаю.
После настройки ospf указание статического маршрута более не нужно. Т.е. для рутера А.
//удаление статического маршрута
RouterA(config)# no ip route 192.168.2.0 255.255.255.0 Tunnel10
Теперь можно взглянуть на таблицу маршрутизации во всей красе.
RouterA#sh ip route | beg Gateway
Gateway of last resort is 10.10.11.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.11.0/24 is directly connected, FastEthernet1/0
O 10.150.1.0/24 [110/11122] via 10.10.10.2, 00:00:22, Tunnel10
C 192.168.1.0/24 is directly connected, FastEthernet0/1
O 192.168.2.0/24 [110/11121] via 10.10.10.2, 00:00:22, Tunnel10
S* 0.0.0.0/0 [1/0] via 10.10.11.1
Как видно, анонсы сетей прошли и рутер А видит маршруты в сети за рутером Б через ospf, что и было необходимо.
Теперь при появлении в центральном отделении новых сетей, конфигурация филиалов не нуждается в изменениях. Всё что необходимо, добавить новую строчкуnetwork в конфигурацию ospf на рутере в центральном офисе. Филиалы узнают об этом практически мгновенно. :)
upd 14.05.08, спасибо Vadim
//Посмотрим на наших соседей.
RouterA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/ - 00:00:37 10.10.10.2 Tunnel10
После прочтения заметки о конфигурации gre ipsec может остаться некоторое недопонимание того зачем, собственно, так усложнять достаточно простую первоначальную конфигурацию.
Данная запись призвана ответить на эти вопросы.
Тем читателям, которые попали сюда по поиску из google или еще каким путем я настоятельно рекомендую прочитать предыдущую часть о настройке gre ipsec, а уже потом возвращаться сюда.
Итак речь идёт о запуске динамических протоколов маршрутизации, в данном случае ospf, поверх существующего vpn соединения.
В случае статической конфигурации, необходимо жесткое указание сетей подлежащих шифрованию. Для этого в конфигурации без gre используются crypto acl.
Если же конфигурация сетей меняется необходимо менять и конфигурацию. Представим довольно жизненную ситуацию - головной офис и определённое количество филиалов.
С случае появления в головном отделении новых ip сетей, необходимо произвести перенастройку всех рутеров, как в центрального так и филиальных. При большом количестве филиалов это может быть непосильной задачей.
1. Описание стенда
Настройка продолжается ровно с того места на котором закончилась статья о конфигурировании gre ipsec. Итак у нас есть следующая конфигурации IP сетей.
Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24
Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24
Допустим, что А это филиал, а Б головное отделение. В случае статического ipsec туннеля указание какой трафик подлежит шифрации с помощью crypto acl.
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
В случае gre ipsec необходимо статическим маршрутом указать куда напрявлять трафик для определённой сети.
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10
После этого трафик попадает в туннель, инкапсулируется в gre, а crypto acl настроеные между пирами пропускали его через процедуру шифрации.
Теперь представим, что в центральном офисе (сеть Б) появилась новая сеть, например 10.200.1.0/24, для обеспечения её видимости в филиалах, необходимо либо добавить по строчке вcrypto acl (static ipsec) либо добавить маршрут (gre ipsec ), что конечно не составляет проблемы для десятка устройств. Но мы же помним, что организация у нас большая и туннелей условно бесконечное количество. :)
2. Конфигурация
Простейшая конфигурация ospf достаточно проста и не вызывает особых проблем. Я не буду рассказывать о принципах работы, алгоритме или прочих ньансах работы этого протокола. В сети достаточно много информации по этой теме. Цель данной заметки показать практическое применение и не дать себе забыть эту простую но в то же время крайне эффективную конфигурацию. :)
Описание настройки.
- число после слова ospf обозначает просто номер процесса ospf на данном устройстве, нет смысла стремиться к его идентичности
- логирование изменений
- ключевая строка, описание сети которые будут анонсироваться от данного рутера. О том что такое area можно говорить долго, но не сейчас. Обратите внимание, используется не маска сети, а wildcard, как в acl.
//Настройка ospf. RouterA
RouterA(config)# router ospf 100
RouterA(config-router)# log-adjacency-changes
RouterA(config-router)# network 192.168.1.0 0.0.0.255 area 10
Практически анологична настройка ospf на рутере Б, исключение составляет дополнительная сеть.
//Настройка ospf. RouterB
RouterB(config)# router ospf 100
RouterB(config-router)# log-adjacency-changes
RouterB(config-router)# network 10.150.1.0 0.0.0.255 area 10
RouterB(config-router)# network 192.168.2.0 0.0.0.255 area 10
В принципе в документации сказано о том, что для указания процессу ospf работать на конкретном интерфейсе необходимо указать сеть относящуюся к данному интерфейсу в конфигурации network.
Т.е. в данном случае сети 10.10.11.0/24 и 10.10.10.0/24 также должны быть указаны. Если у вас версия IOS менее чем 12.4 так и придется сделать. Я же сделаю немного по-другому.
//Настройка ospf. RouterA
RouterA(config)# interface Tunnel10
RouterA(config)# ip ospf 100 area 10
Это просто указание процессу работать на данном интерфейсе. Об этом трюке я узнал от простого словацкого парня Ивана, чей блог я с удовольствием читаю.
После настройки ospf указание статического маршрута более не нужно. Т.е. для рутера А.
//удаление статического маршрута
RouterA(config)# no ip route 192.168.2.0 255.255.255.0 Tunnel10
Теперь можно взглянуть на таблицу маршрутизации во всей красе.
RouterA#sh ip route | beg Gateway
Gateway of last resort is 10.10.11.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.11.0/24 is directly connected, FastEthernet1/0
O 10.150.1.0/24 [110/11122] via 10.10.10.2, 00:00:22, Tunnel10
C 192.168.1.0/24 is directly connected, FastEthernet0/1
O 192.168.2.0/24 [110/11121] via 10.10.10.2, 00:00:22, Tunnel10
S* 0.0.0.0/0 [1/0] via 10.10.11.1
Как видно, анонсы сетей прошли и рутер А видит маршруты в сети за рутером Б через ospf, что и было необходимо.
Теперь при появлении в центральном отделении новых сетей, конфигурация филиалов не нуждается в изменениях. Всё что необходимо, добавить новую строчкуnetwork в конфигурацию ospf на рутере в центральном офисе. Филиалы узнают об этом практически мгновенно. :)
upd 14.05.08, спасибо Vadim
//Посмотрим на наших соседей.
RouterA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/ - 00:00:37 10.10.10.2 Tunnel10
Subscribe to:
Posts (Atom)
