Анализируй это! (capture on cisco IOS, tcpdump on cisco)

Чуть больше года назад, я уже писал о инструментах подобных 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 (номер, имя)

Запасной 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

vpn1
Совершенна идентична 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 интерфейса.

Защищая себя (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.

Логичным было бы создать примерно следующую политику:

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

Но не выходит. :)
Здесь мы сталкиваемся с ограничением на глубину инспекции в 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

Хочу обратить внимание, что реальной инспекции именно протоколов http и ssh не происходит, пакеты инспектируются до уровня tcp.

Замечу, то что описывается в данной заметке не является официально рекомендуемым  способом обеспечивать безопасность самого устройства. Для этого предназначен - Network Foundation Protection, который я надеюсь рассмотреть немного позже.


Вот мы и познакомились с общими концепциями построение брандмауэров от Cisco. Хочется заметить, представленный метод конечно достаточно громоздок и если у вас всего два  интерфейса между которыми необходимо настроить инспекцию, возможно классический CBAC в этом окажется удобнее, как минимум объем команд меньше.
Если же конфигурация усложняется, или же имеет свойство изменяться, Zone-Based Firewall именно то решение которое необходимо. Конфигурация гораздо легче читается и поддерживать, расширять, её проще.

Мы будем жить теперь по новому! (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

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

Динамический рутинг поверх 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

Соединяя офисные пространства (lan-2-lan ipsec vpn gre)

0. Вводная
Продолжим разборки с различными технологиями vpn предоставляемыми рутерами cisco. Заметка будет больше практического характера. Ориентирована на тех, кто уже знаком с общей теорией работы ipsec и простейшими примерами построения туннелей. Итак, сегодня в качестве примера рассмотрим построение всё такого-же статического туннеля. Отличие только в том, что в данном примере, все пакеты подлежащие шифрованию будут сначалаинкапсулироваться в gre туннель и только потом в ipsec . Зачем такая сложность может ответить любой кто сталкивался с необходимостью пропускать через туннель мультикаст пакеты, которые в свою очередь любят использовать современные протоколы динамической маршрутизации. Впрочем, обо всём по порядку.
Адресация сети снова выглядит следующим образом.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Между внешними интерфейсами у меня находиться pix. В данном случае это не так важно, но он поможет сниффить проходящий траффик.

1. Труба (она же туннель).
Итак, необходимо установить туннель между внешними интерфейсами маршрутизаторов, в данном случае 10.10.11.2 и 10.10.10.2.
Минимальные параметры настройки:
- каждый туннель "привязывается" к конкретному физическому интерфейсу, в данном случае это FastEthernet 1/0.
- поскольку это layer 3 соединения, необходима ip адресация. Для уменьшения путаницы с "лишними" адресами будем использовать адреса физических интерфейсов. Ссылка.
- совершенно очевидно, что раз есть у туннеля начало, значит еть где-то и конец :) Указание второго пира, также обязательный параметр.
В примере приведена конфигурация только одной стороны туннеля, очевидно другая сторона конфигурируется идентично за исключением адреса пира.

//пример конфигурации gre туннеля
RouterA(config)# interface Tunnel10
RouterA(config-if)# tunnel source FastEthernet1/0
RouterA(config-if)# tunnel destination 10.10.10.2
RouterA(config-if)# ip unnumbered FastEthernet1/0

Итак туннель поднят, но не совсем понятно для каких целей, поскольку по нему еще ничего не ходит. Развернем рутинг для сетей 192.168.1.0/24 и 192.168.2.0/24, соответственно в сторону туннеля.
//рутинг в туннель
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10

Для рутера Б, нужно развернуть сеть 192.168.1.0/24.
Теперь внутренние сети находящиеся за рутерами видят друг друга.
//простейшая проверка - ping
RouterA#ping
Protocol [ip]:
Target IP address: 192.168.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/61/104 ms


Как видно пинг проходит успешно, но всегда интересно посмотреть, что же там внутри туннеля, для этих целей на стенде используется PIX с правильно настроеным capture.

// sniff
pixfirewall# show cap anyin
10 packets captured
1: 16:01:56.004577 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
2: 16:01:56.024870 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
(skip)
9: 16:01:56.232715 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
10: 16:01:56.249163 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
10 packets shown

Как и предпологалось, туннель работает нормально. Протокол 47 стека IP И есть gre.

2. Шифруем

Дальше всё просто. Принципиальных отличий между данной и минимальной конфигурацией практически никаких. Всё что нужно сделать это изменить crypto acl определяющий какой трафик подлежит шифрации.
Поскольку сниффер нам показал только gre пакеты между двумя пирами шифровать будем только их. Что в принципе достаточно очевидно. :)
//crypto acl, конечно они должны быть зеркальны с обоих сторон туннеля
RouterA(config)# access-list 150 permit gre host 10.10.11.2 host 10.10.10.2


isakmp, crypto map и прочие безобразия настраиваются совершенно идентично. На всякий случай привожу кусок конфигурации рутера А.

//пример окончательной конфигурации
!
crypto isakmp policy 200
encr aes 256
authentication pre-share
group 2
lifetime 36000
crypto isakmp key sUpeRkEy address 10.10.10.2
!
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.2
set transform-set ts-aes-sha
match address 150
!
interface Tunnel10
ip unnumbered FastEthernet1/0
tunnel source FastEthernet1/0
tunnel destination 10.10.10.2
!
interface FastEthernet1/0
ip address 10.10.11.2 255.255.255.0
duplex auto
speed auto
crypto map cr_outside
!
ip route 192.168.2.0 255.255.255.0 Tunnel10
!
access-list 150 permit gre host 10.10.11.2 host 10.10.10.2
!

// Проведем то же элементарное тестирование с помощью ping. Ниже представлен вывод сниффера.
pixfirewall# show capture anyin
17 packets captured
1: 15:33:57.516788 10.10.11.2.500 > 10.10.10.2.500: udp 144
2: 15:33:57.741477 10.10.10.2.500 > 10.10.11.2.500: udp 104
3: 15:33:57.911284 10.10.11.2.500 > 10.10.10.2.500: udp 304
4: 15:33:58.126153 10.10.10.2.500 > 10.10.11.2.500: udp 304
5: 15:33:58.186025 10.10.11.2.500 > 10.10.10.2.500: udp 108
6: 15:33:58.206059 10.10.10.2.500 > 10.10.11.2.500: udp 76
7: 15:33:58.219852 10.10.11.2.500 > 10.10.10.2.500: udp 172
8: 15:33:58.259401 10.10.10.2.500 > 10.10.11.2.500: udp 172
9: 15:33:58.268388 10.10.11.2.500 > 10.10.10.2.500: udp 60
10: 15:33:59.395807 10.10.11.2 > 10.10.10.2: ip-proto-50, length 164
11: 15:33:59.444541 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
(skip)
17: 15:33:59.556703 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
17 packets shown

Как и ожидалось, конфигурация работает и даже шифрует трафик.
Первые 9 пакетов показывают обмен небольшими udp пакетами по 500 порту. Этот порт используется isakmp при установлении SA.
Далее идёт обмен пакетами протокола 50 стека IP, что и есть, собственно, ipsec.

Соединяя офисные пространства (lan-2-lan vpn pre-shared)

0. Общие слова
Зачем нужен vpn и что с ним делать рассказывать не буду, в сети достаточно много информации на эту тему. Скажу только, что под vpn подразумевается ipsec и в данной заметке описывается построение site to site vpn используя pre-shared keys, т.е. соединение двух локальных сетей, например центрального отделения и филиала через открытую сеть типа интернет. Используемое оборудование - рутер cisco. Заметка сугубо практическая, поскольку рассмотрение теории займет достаточно много места и времени. Краткий обзор: что происходит при построении ipsec туннеля можно найти в одной из предыдущих заметок.

Итак, пройдемся по всем фазам и посмотрим какие команды отвечают за успешное завершение каждой. Адресация сети выглядит следующим образом.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24


Необходимо убедиться, что существующие acl совместимы с ipsec. Как требует документация необходимо разрешить прохождения трафика по протоколам 51 (ah) и 50 (esp) стека ip, зависит от желаемой конфигурации. Порт 500/udp и echo/echo-replay. Впрочем без разрешенного icmp у меня туннель заработал.

1. Установка триггера на трафик подлежащий шифрованию

Задача, соответственно, состоит в том, чтобы позволить пользователям из сети 192.168.1.0/24 получать доступ к компьютерам находящимся в сети 192.168.2.0/24 и наоборот.
На первом этапе ipsec рутер просматривает проходящий через него трафик и если находит пакет совпадающий с определенным acl, шифрует его и передает дальше. Таким образом первая задача - определить трафик подлежащий шифрованию с помощью acl. Логично, что acl должны быть совершенно зеркальны на обоих сторонах туннеля, поскольку SA создаются уникальные для source и destination в прямом и обратном направлении. Соответственно, если acl будут не зеркальны, то и туннель не установится.

//Пример 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
// routerB
RouterB(config)# access-list 120 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255


2. Первая фаза IKE
Следующий этап - создание IKE SA.
Поскольку на каждому рутере может создаваться несколько IKE SA для различных туннелей с различными настройками безопасности используются политики IKE с различными уровнями приоритета (<1-10000), id="ce4u">Каждая политика характеризуется следующими параметрами: алгоритм шифрования, алгоритм хеширования, метод аутентификации, используемая реализация алгоритма Диффи-Хелмана, время жизни SA. Настройки по-умолчанию можно посмотреть следующим образом:

//политика IKE по-умолчанию
RouterA#sh crypto isakmp policy

Global IKE policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

Минимально необходимых, а мы сейчас говорим именно о них, параметров не так много. В данном случае изменим метод аутентификации на pre-shared keys, заменим не рекомендуемый аглоритм шифрования данных, на продвинутый (DES & AES) и Диффи-Хелмана на вторую группу, 1024 бита.
Поскольку в качестве метода аутентификации выбран метод распределенного ключа, его необходимо также указать.
Манипуляции производятся следующими командами.

// Настройки необходимые для IKE SA, в данном случае политика с приоритетом 200
// ключ указывается отдельно от политики, поскольку в общем случае он почти ничего общего с ней не имеет,
// политика может использоваться многократно для нескольких туннелей. Ключ желательно оставлять уникальным для каждого пира.
// Конечно, настройки для рутера Б должны быть идентичны за исключением адреса другого конца туннеля.
RouterA(config)# crypto isakmp policy 200
RouterA(config-isakmp)# encr aes
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# group 2
RouterA(config)# crypto isakmp key sUpeRkEy address 10.10.10.2

3. Вторая фаза IKE
В рамках второй фазы IKE происходит установка ipsec SA которые потом будут использоваться непосредственно для шифрования трафика.
Для этого необходимо указать желаемые параметры: алгоритм и шифрования и хеширования. Происходит это путем создания так называемого transform-set.

// В данном случае:
// ts-aes-sha - имя данного transform-set
// esp-aes 256 - алгоритм шифрования и длина его ключа
// esp-sha-hmac - алгорим хеширования
RouterA(config)# crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac

Следущим этапом идет создание специальной крипто карты, которая связывает всё вместе. Именно эта карта потом привязывается к конкретному интерфейсу.
Поскольку для каждого интерфейса может быть определена только одна крипто карта, здесь используется тот же принцип приоритетов, позволяющий создавать туннели к разным пирам и с различными параметрами безопасности.
Параметров не так много: адрес другого конца туннеля, имя желаемомого transform-set, acl который будет использваться как триггер для данной крипто карты.

//Пример crypto map
RouterA(config)# crypto map cr_outside 200 ipsec-isakmp
RouterA(config-crypto-map)# set peer 10.10.10.2
RouterA(config-crypto-map)# set transform-set ts-aes-sha
RouterA(config-crypto-map)# match address 120

4. Нормальная работа
Почти всё необходимые настойки произведены, осталось только указать интерфейс используемый как источник для создния туннеля и включить "глобальный выключатель" разрешающий использовать IKE и слушать 500/udp порт.

//Привязка созданной крипто карты к интерфейсу
RouterA(config-if)#crypto map cr_outside

//Включить IKE
RouterA(config)#crypto isakmp enable

Туннель создается не сразу, а только после появления трафика подлежащего шифрованию. Посмотреть реально ли создан туннель и шифруется ли трафик можно с помощью следущей команды:

// Просмотр активных туннелей
RouterA#sh crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
2001 FastEthernet1/0 10.10.11.2 set AES256+SHA 9 0
2002 FastEthernet1/0 10.10.11.2 set AES256+SHA 0 9

Насколько видно из примера, создано две SA каждая используется для одного направления. В данном случае SA c ID 2001 используется для шифрования, а c ID 2002 для расшифровывания, что видно по счетчикам пакетов.

Более подробную информацию может дать команда show crypto ipsec sa.

// Доступные SA на рутере.
RouterA#sh crypto ipsec sa

interface: FastEthernet1/0
Crypto map tag: cr_outside, local addr 10.10.11.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
current_peer 10.10.10.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 10.10.11.2, remote crypto endpt.: 10.10.10.2
path mtu 1500, ip mtu 1500
current outbound spi: 0xB2259128(2988806440)

inbound esp sas:
spi: 0x8A02CA5F(2315438687)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: SW:2, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE


inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3363)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

uRPF loose mode

Не так давно я уже писал о Unicast Reverse Path Forwarding технологии и одной из отличитильных особенностей реализации была невозможность её использования при асинхронном рутинге. Связано это с тем, что проверка достижимости проводилась с помощью cef для каждого конкретного интерфейса.
Времена меняються! Собственно они изменились еще с версии 12.2Т IOS, просто я узнал об этом только сейчас. :)

Итак. Старый режим, известный как uRPF, теперь называется uRPF strict mode, а новый uRPF loose mode.
Изменения в первую очередь касаються работы с асинхронным рутингом. Теперь проверка достижимости адреса источника осуществляется для всех интерфейсов. Другими словами неважно откуда пришел пакет, если есть дорога обратно то он легитимен.

Настроить такое поведени можно с помощью команды ip verify unicast source reachable-via выполненой в контексте интерфейса.

RouterA (config-if)# ip verify unicast source reachable-via {rx|any} [allow-default] 

rx - возврат к истокам. strict mode, проверять достижимость источника только для интерфейса через который пакет получен
any - loose mode, проверять доостижимость через любой доступный интерфейс
allow-default - использовать ли для проверки default route

Дополнительно loose mode отбрасывает пакеты с адресами источника:
- адреса зарезервированные для специального применения (0/8, 127/8);
- адреса предназначенные для частных сетей (RFC 1918);
- адреса которые рутятся в интерфейс null на рутере.


Легкий debug
Проверить "работает ли эта штуковина" можно следующими способами:

RouterA# show ip interface Serial1/1 | in verif
RouterA# show ip traffic | in RPF

В обоих случаях можно увидеть счетчики RFP. Увеличение которых, показывает отброшенные пакеты.

Unicast Reverse Path Forwarding

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

Тем не менее многие знают или слышали о такой штуке как Unicast Reverse Path Forwarding.

Как это работает

Для работы Unicast Reverse Path Forwarding должен быть включен cef.
При получении пакета uRPF проверяет соответствует ли адрес источника и интерфейс через который получен пакет значениям в таблице FIB.
По сути выполняется обратный резолвинг адреса источника используя базу (reverse lookup) FIB

Решение конечно не универсальное. Его нельзя применять в случае ассиметричного рутинга (вход по одному интерфейсу, а выход по другому).

Подробнее можно почитать в RFC 2267.

Настройка

Cisco IOS
В конфигурацию интерфейса необходимо добавить строку

routerA(conf-if)# ip verify unicast reverse-path

PIX/ASA
В режиме глобальной конфигурации необходимо выполнить команду

myasa# ip verify reverse-path interface e0


Проверка состояния rpf

В случае Cisco IOS проверить можно поискав строку относящуюся с rpf в выводе команды:

RouterA# show cef interface FastEthernet 0/0

IP unicast RPF check is enabled

В случае PIX/ASA всё выглядит похоже:

myasa# show ip verify statistics
interface outside: 21 unicast rpf drops
interface inside: 2738 unicast rpf drops
interface vpn: 0 unicast rpf drops

Live and learn: кто это сделал!?

Сколько раз возникал у вас такой вопрос? Часто хочется посмотреть кто изменял концигурацию и какие именно команды вводил. Не буду много рассказывать лучше показать. Как это выглядело раньше? Кто-то зашел на железяку и внес какие-то изменения. Об этом в логе останется информация следующая информация:

*Mar 1 00:12:15.675: %SYS-5-CONFIG_I: Configured from console by one on vty0 (10.10.10.1)

И всё!

С некоторой версии ios появилась возможность посмотреть кто и что конкретно сделал. Подробненько. :)
Для этого необходимо добавить в конфигурацию следующие строки:

archive
log config
logging enable
notify syslog
hidekeys


logging enable - писать лог. По умолчанию выключено.
notify syslog - писать лог локально или посылать также на syslog сервер
hidekeys - не записывать в лог пароли

Теперь процесс логина и изменения отобразится примерно следующим образом:
Легко определить что в гости заходил пользователь one и настроил интерфейс FastEthernet1/0.

*Mar 1 00:18:18.839: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:!exec: enable
*Mar 1 00:18:58.003: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:interface FastEthernet1/0
*Mar 1 00:19:11.023: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:ip address 192.168.1.1 255.255.255.0
*Mar 1 00:19:13.715: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:no shutdown
*Mar 1 00:19:15.687: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:19:16.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up

Официальная документация
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080454f8c.html#wp1100253