antiCisco blogs

Опубликовано P@ve1 25 Июль , 2011

 

Для построения территориально распределенных сетей на текущий момент в большинстве случаев используются виртуальные шифрованные сети поверх интернета. Традиционный подход построения подобных сетей с помощью простого шифрования трафика методом IPsec в туннельном режиме крайне не эффективен в виду сложности настройки, невозможности использования динамических протоколов маршрутизации, не работоспособности multicast трафика, и очень плохой масштабируемости. Добавление новых сайтов в таких сетях зачастую требует перенастройки всех узлов, корректировки огромного числа ACL, статических маршрутов и т.д.

 

Для устранения выше обозначенных недостатков компания Cisco в своих маршрутизаторах (Cisco ASA данным функционалом не обладает!)  предлагает технологию DMVPN (Dynamic Multipoint VPN). Данная технология базируется на следующих базовых принципах:

• Топология Hub & Spoke.
• Виртуальная L2 подсеть на базе point-to-multipoint  интерфейсов mGRE.
• Шифрование проходящего GRE трафика посредством IPsec.
• Использование динамической маршрутизации.

С топологией Hub & Spoke все понятно:  выделяются 2 множества узлов сети – центральные (основной офис/дата-центр), и все остальные (региональные офисы).  При этом Hub-маршрутизаторы должны иметь статические IP адреса из публичного диапазона.  Spoke-маршрутизаторы могут иметь динамические IP адреса из private диапазона, и находиться за NAT. В этом случае маршрутизатор автоматически  определяет наличие NAT на пути, и включает функционал NAT-T, который инкапсулирует IPsec пакеты в udp 4500.

 

Технология mGRE (m – сокращение от multipoint) базируется на немного измененной GRE инкапсуляции с добавление дополнительных 4 байт, а также технологии NHRP (Next hop resolution protocol).  В отличие от классического point-to-point GRE  – Виртуальный интерфейс mGRE работает аналогично интерфейсу point-to-multipoint Frame Relay. Тем самым позволяя в рамках одной L2 сети объединить много устройств.  NHRP в свою очередь является сопутствующим механизмом, позволяющим установить соответствие между реальными физическими IP адресами маршрутизаторов, и их виртуальными туннельными адресами.  Маршрутизаторы могут выступать в роли NHRP серверов,  и NHRP клиентов. Первыми являются Hub-маршрутизаторы.  Они выстраивают динамическую таблицу соответствия реальных и виртуальных адресов по мере регистрации Spoke-маршрутизаторов.  И распространяют эту информацию по всем Spoke-м.

 

Шифрование проходящих GRE пакетов реализуется посредством IPseс.   Критерий  шифрования – присутствие GRE заголовка.

 

Основная цель построения сети на базе виртуальных интерфейсов GRE – получить возможность использовать протоколы динамической маршрутизации для распространения информации о маршрутах и осуществления  отказоустойчивости. В данном случае Cisco настоятельно рекомендует протокол EIGRP.  Основные принципы настройки классические:  не растягивать процесс маршрутизации шире DMVPN облака, использовать по возможности режим Stub в spoke-узлах с целью исключения прохождения транзитного трафика через них, использовать суммаризацию маршрутов.

Логически DMVPN может быть реализован в 2-х вариантах:

1. Spoke-to-spoke deployment.  В этом случае на всех маршрутизаторах виртуальные интерфейсы настраиваются в режиме mGRE.   В результате с точки зрения передачи данных мы получаем full mesh сеть, в которой  unicast трафик между spoke-узлами идет напрямую по динамически устанавливающимся каналам. Для построения динамического туннеля spoke использует полученную от hub-узла NHRP таблицу.  При этом постоянно поддерживаются и участвуют в динамической маршрутизации  только туннели до Hub-узлов.

К минусам данного дизайна относится ограничения по QoS для Spoke-to-Spoke туннелей – что не очень благоприятно для медиа трафика. Также подобный дизайн редко оправдан логически, т.к. в 99% связь используется для доступа к центральному офису компании, в котором находится дата-центр.

2. Hub-and-spoke deployment.  Виртуальные интерфейсы настраиваются в режиме mGRE только на Hub маршрутизаторах.  Все остальные  настраиваются в режиме p2p GRE. В результате сеть ведет себя как классический point-to-multipoint Frame Relay. Весь трафик проходит через Hub маршрутизаторы.

В результате мы имеем систему со следующими преимуществами:

• Простота и наглядность настройки.
• Эффективная масштабируемость. Добавление нового узла – простая типовая процедура.
• Динамическая отказоустойчивость и тонкое управление маршрутизацией на базе протокола динамической маршрутизации.
• Работоспособность multicast.
• Полноценная full mesh топология с точки зрения передачи данных при умеренном объеме служебного трафика.
• Spoke-маршрутизаторы могут находиться за NAT и иметь динамические IP адреса из private диапазона.

А теперь рассмотрим простейший базовый лабораторный стенд:

 

На приведенном лабораторном стенде имеем 1 центральный hub-маршрутизатор и 2 spoke-маршрутизатора.

Loopback интерфейсы эмулируют локальные сети соответствующих офисов. Для эмуляции интернета используем маршрутизатор с аналогичным название.  Связность сети осуществляем с помощью OSPF, не транслируя в него Loopback интерфейсы.

1.) Первоначальная конфигурация:

 

HUB:

interface Loopback0

ip address 10.1.1.1 255.255.255.0

interface FastEthernet0/0

ip address 1.1.1.2 255.255.255.0

router ospf 1

network 1.1.1.0 0.0.0.255 area 0

 

SPOKE_1:

interface Loopback0

ip address 10.2.2.2 255.255.255.0

interface FastEthernet0/0

ip address 2.2.2.2 255.255.255.0

router ospf 1

network 2.2.2.0 0.0.0.255 area 0

 

SPOKE_2:

interface Loopback0

ip address 10.3.3.3 255.255.255.0

interface FastEthernet0/0

ip address 3.3.3.2 255.255.255.0

router ospf 1

network 3.3.3.0 0.0.0.255 area 0

 

2.) Настройка mGRE интерфейсов:

 

Для многоточечной сети mGRE  будем использовать адресное пространство 192.168.0.0/24.

 

HUB:

interface Tunnel1

ip address 192.168.0.1 255.255.255.0

ip mtu 1400

ip nhrp map multicast dynamic

ip nhrp network-id 1

ip nhrp holdtime 400

ip tcp adjust-mss 1360

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel path-mtu-discovery

 

Как видно, для настройки NHRP на Hub-е необходимо настроить network-id (если DMVPN облаков несколько – для каждого необходим уникальный).

Не забываем о необходимости уменьшить MTU – т.к. GRE и ESP инкапсуляции увеличивают размер пакета (команды: ip mtu 1400,  ip tcp adjust-mss 1360, tunnel path-mtu-discovery). Команда ip nhrp holdtime 400  — задает время, которое динамическая запись хранится в базе. По происшествию данного времени запись должна быть обновлена.

 

SPOKE_1:

interface Tunnel1

ip address 192.168.0.101 255.255.255.0

ip mtu 1400

ip nhrp map 192.168.0.1 1.1.1.2

ip nhrp map multicast 1.1.1.2

ip nhrp network-id 1

ip nhrp holdtime 400

ip nhrp nhs 192.168.0.1

ip tcp adjust-mss 1360

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel path-mtu-discovery

 

SPOKE_2:

interface Tunnel1

ip address 192.168.0.102 255.255.255.0

ip mtu 1400

ip nhrp map 192.168.0.1 1.1.1.2

ip nhrp map multicast 1.1.1.2

ip nhrp network-id 1

ip nhrp holdtime 400

ip nhrp nhs 192.168.0.1

ip tcp adjust-mss 1360

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel path-mtu-discovery

 

Здесь все тоже самое. Только в настройках NHRP добавляется статическая запись до HUB-а. И указание, что именно он будет NHRP сервером.  Отсюда понятно, что изначальное соединение может быть инициировано только spoke-маршрутизаторами.

 

Итак, оверлейный транспорт готов.   Проверяем его работоспособность:

 

HUB#sh ip nhrp

192.168.0.101/32 via 192.168.0.101

Tunnel1 created 00:12:23, expire 01:48:48

Type: dynamic, Flags: unique registered

NBMA address: 2.2.2.2

192.168.0.102/32 via 192.168.0.102

Tunnel1 created 00:10:47, expire 01:50:46

Type: dynamic, Flags: unique registered

NBMA address: 3.3.3.2

 

HUB#ping 192.168.0.101

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.101, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 164/212/268 ms

HUB#ping 192.168.0.102

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.102, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 240/280/312 ms

 

3.) Настройка шифрования. Идентично для всех маршрутизаторов:

 

//Предполагается, что читатель уже знаком с настройкой IPsec

 

crypto keyring DMVPN

local-address FastEthernet0/0

pre-shared-key address 0.0.0.0 0.0.0.0 key secret            // ключ аутентификации пиров

!

crypto isakmp policy 10         // Параметры ISAKMP сессии

encr 3des

authentication pre-share

group 2

 

crypto isakmp invalid-spi-recovery

crypto isakmp keepalive 10 periodic

 

crypto isakmp profile DMVPN      // Профиль ISAKMP

keyring DMVPN

match identity address 0.0.0.0

local-address FastEthernet0/0

!

crypto ipsec transform-set ESP-3DES-SHA-HMAC esp-3des esp-sha-hmac

 

crypto ipsec profile DMVPN     // Профиль IPSec шифрования

set transform-set ESP-3DES-SHA-HMAC

set isakmp-profile DMVPN

 

interface Tunnel1

tunnel protection ipsec profile DMVPN      //Применения шифрования к туннельному интерфейсу

 

Важно понимать, что ipsec profile – это завуалированный crypto dynamic-map. Это отчетливо видно, если ввести: show crypto map. При желании/необходимости данную конструкцию можно поменять на классический crypto dynamic-map, c указанием в сопутствующем ACL интересующего трафика GRE.

 

4.) Настраиваем динамическую маршрутизацию:

 

HUB:

router eigrp 1

passive-interface default

no passive-interface Loopback0

no passive-interface Tunnel1

network 10.0.0.0

network 192.168.0.0 0.0.255.255

no auto-summary

 

interface Tunnel1

no ip next-hop-self eigrp 1

no ip split-horizon eigrp 1

 

SPOKE_1:

router eigrp 1

passive-interface default

no passive-interface Loopback0

no passive-interface Tunnel1

eigrp stub connected summary

network 10.0.0.0

network 192.168.0.0 0.0.255.255

no auto-summary

 

interface Tunnel1

no ip next-hop-self eigrp 1

no ip split-horizon eigrp 1

 

SPOKE_2:

router eigrp 1

passive-interface default

no passive-interface Loopback0

no passive-interface Tunnel1

eigrp stub connected summary

network 10.0.0.0

network 192.168.0.0 0.0.255.255

no auto-summary

 

interface Tunnel1

no ip next-hop-self eigrp 1

no ip split-horizon eigrp 1

 

Как видно, в виду point-to-multipoint специфики mGRE по аналогии с Frame-Relay –  для работоспособности EIGRP необходимы команды: no ip next-hop-self eigrp 1 и no ip split-horizon eigrp 1.  Spoke-маршрутизаторы настраиваем в режим Stub, для предотвращения транзитного трафика.

 

Ну вот вроде и все. Теперь проверяем:

 

HUB#sh cry isa sa

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id status

1.1.1.2         2.2.2.2         QM_IDLE           1001 ACTIVE

1.1.1.2         3.3.3.2         QM_IDLE           1002 ACTIVE

 

HUB#sh crypto ipsec sa address

fvrf/address: (none)/1.1.1.2

protocol: ESP

spi: 0x932D0691(2469201553)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

conn id: 3, flow_id: SW:3, sibling_flags 80000046, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4422240/3494)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

spi: 0x8104DABA(2164579002)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

conn id: 7, flow_id: SW:7, sibling_flags 80000046, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4424231/3494)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

 

fvrf/address: (none)/2.2.2.2

protocol: ESP

spi: 0x9AAD12A7(2595033767)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

conn id: 4, flow_id: SW:4, sibling_flags 80000046, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4422239/3494)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

 

fvrf/address: (none)/3.3.3.2

protocol: ESP

spi: 0xA6EE779F(2800646047)

transform: esp-3des esp-sha-hmac ,

in use settings ={Tunnel, }

conn id: 8, flow_id: SW:8, sibling_flags 80000046, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4424231/3494)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

 

HUB#sh ip nhrp

192.168.0.101/32 via 192.168.0.101

Tunnel1 created 00:02:26, expire 00:05:49

Type: dynamic, Flags: unique registered

NBMA address: 2.2.2.2

192.168.0.102/32 via 192.168.0.102

Tunnel1 created 00:02:25, expire 00:05:28

Type: dynamic, Flags: unique registered

NBMA address: 3.3.3.2

 

HUB#sh ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

(sec)         (ms)       Cnt Num

1   192.168.0.102           Tu1               34 00:02:45 1168  5000  0  5

0   192.168.0.101           Tu1               33 00:02:45  364  2184  0  5

 

HUB#sh ip route eigrp

10.0.0.0/24 is subnetted, 3 subnets

D       10.3.3.0 [90/1664000] via 192.168.0.102, 00:00:01, Tunnel1

D       10.2.2.0 [90/1664000] via 192.168.0.101, 00:00:01, Tunnel1

 

HUB#ping 10.2.2.2 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 10.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 224/268/328 ms

 

HUB#ping 10.3.3.3 source loopback 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:

Packet sent with a source address of 10.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 224/307/452 ms

 

Итак, IPSec поднялся, динамическая маршрутизация работает, пакеты бегают. Теперь самое интересное: проверка работы динамического туннеля.

 

SPOKE_1#ping 10.3.3.3 source loopback 0 repeat 20

 

Type escape sequence to abort.

Sending 20, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:

Packet sent with a source address of 10.2.2.2

!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (20/20), round-trip min/avg/max = 212/338/724 ms

 

SPOKE_1#sh cry ipsec sa peer 3.3.3.2

 

interface: Tunnel1

Crypto map tag: Tunnel1-head-0, local addr 2.2.2.2

 

protected vrf: (none)

local  ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)

remote ident (addr/mask/prot/port): (3.3.3.2/255.255.255.255/47/0)

current_peer 3.3.3.2 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 16, #pkts encrypt: 16, #pkts digest: 16

#pkts decaps: 16, #pkts decrypt: 16, #pkts verify: 16

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

 

local crypto endpt.: 2.2.2.2, remote crypto endpt.: 3.3.3.2

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

current outbound spi: 0x0(0)

PFS (Y/N): N, DH group: none

 

inbound esp sas:

 

inbound ah sas:

 

inbound pcp sas:

 

outbound esp sas:

 

outbound ah sas:

 

outbound pcp sas:

 

Самое интересное здесь то, что пингов прошло 20, а в IPSec SA отображается только 16 пакетов.   А значит это, что первые 4 пингов прошли обходным путем через HUB, пока поднимался прямой IPSec туннель.

 

***

В следующей статье рассмотрим сложную топологию со всевозможными вариантами отказоустойчивости.

 

Рекомендуемое чтиво:

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPDG.html

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_trsel.html

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.pdf

 

Не будьте слишком строги к моей первой публикации.  Конструктивная критика приветствуется)

 

С уважением,

 

Павел Попп  aka  P@ve1

 

🙂

 

 

Метки: cisco, DMVPN, IPSec, router, security, VPN
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы