Left, Right, Center Left, Center, Right Center, Left, Right

Академия

Мы -- официальная сетевая академия Cisco (ID: 20027250)

Хочешь сказать спасибо?

Нравится наш проект?

Хотите нас поддержать (сказать "спасибо")?

Можете воспользоваться для этого следующими кошельками webmoney

R432847347204

Z150172555537

Подписка на новости

Вопрос недели

В какое время Вам будет удобно заниматься?



 

Вход в систему







Забыли пароль?
Регистрация

Про виртуальные сети (часть 10). Рассматриваем настройку VPN (только IPSec), то есть часть 2, в случае, когда маршрутизаторы получают адреса по DHCP (то есть dynamic crypto map)

Статьи

В предыдущей статье про виртуальные сети мы рассматривали вопросы построения виртуальных частных сетей между виртуальными же маршрутизаторами. Звучит довольно забавно, и тем не менее, если перефразировать, то мы строили VPN между VRF на разных физических маршрутизаторах. Фокус статьи был установлен на GRE туннель, защищенный средствами IPSec. Бонусы, которые нам дает такой вид VPN, довольно очевидны. Один из таких, который сразу приходит на ум, - это поддержка Multicast трафика, что означает возможность работы протоколов маршрутизации через такой туннель, что дает возможность построения сквозной маршрутизации в сети без использования различных «костылей». Такой подход хорош, если мы связываем между собой крупные сайты с обширной внутренней адресацией, различными подсетями и так далее и тому подобное. А если мы хотим подключить отдельного пользователя, что называется в западной терминологии «teleworker» или небольшой офис, такой как «soho» (small office, home office) или небольшой филиал компании «Branch», то в строительстве таких GRE туннелей нам нет необходимости, так как нам не зачем поднимать между таким небольшим пользователем и головным офисом какой-либо протокол маршрутизации. Для данного варианта нам вполне хватит обычного шифрованного IPSec туннеля, без GRE. Еще одним кейсом, разбираемым в данной статье, будет тот факт, что IP-адреса некоторых маршрутизаторов получаются по DHCP, соответственно обычные криптомапы (crypto map) тут не подойдут. Необходимо создавать динамические, которые бы позволили реализовать данную задачу.

 

Как это сделать, а конкретно как построить IPSec VPN к виртуальному маршрутизатору и/или с него, в данной статье мы и разберем.

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

 


R1#sh run
! interface FastEthernet0/0.50 encapsulation dot1Q 50 ip vrf forwarding V5R1 ip address dhcp !

Теперь настроим V5R3 на то, чтобы он эти адреса, собственно, раздавал:


R3#sh run ! ip dhcp pool V5R1 network 51.51.51.0 255.255.255.248 default-router 51.51.51.3 domain-name customer.cisco-lab.by ! ip dhcp pool V5R2 network 52.52.52.0 255.255.255.248 default-router 52.52.52.3 domain-name customer2.cisco-lab.by ! interface FastEthernet0/0.50 encapsulation dot1Q 50 ip vrf forwarding V5R3 ip address 51.51.51.3 255.255.255.248 ! interface FastEthernet0/0.51 encapsulation dot1Q 51 ip vrf forwarding V5R3 ip address 52.52.52.3 255.255.255.248 !

Отмечу тут такой момент: в той версии IOS, которая использовалась при настройке макета для данной статьи, привязывать dhcp pool к VRF не надо. Даже наоборот, если ты привяжешь, то работать не будет – в документации на cisco.com описывается, что данная фишка используется для ODAP (on demand address pool) для MPLS. Соответственно, так как мы MPLS пока не используем для наших виртуальных сетей, то нам необходима работа DHCP без MPLS. Однако утверждать, что нет необходимости привязывать в 15-ой версии IOS DHCP к VRF, я не стану – это требует дополнительной проверки: возможно, что-то могло измениться в настройке.

Посмотрим на настройку интерфейса FastEthernet на V5R1:


R1#sh ip int br Fa 0/0.50 Interface IP-Address OK? Method Status Protocol FastEthernet0/0.50 51.51.51.1 YES DHCP up up

Видим, что IP-адрес получен, значит эта часть точно настроена верно.

Для данной топологии, как видно из схемы, настраивать маршрутизацию на V5R3 необходимости нет. На всех остальных маршрутизаторах достаточно указать маршрут по умолчанию в сторону V5R3 через соответствующий FastEthernet 0/0.5X интерфейс.

Теперь начнем настраивать сам IPSec VPN. Какие-то кубики, которые нам необходимы для его настройки, типа IPSec transform-set или ISAKMP мы рассматривали в предыдущей статье (http://cisco-lab.by/study/articles/1350-virtual-network-09.html). Настройка ISAKMP профиля на V5R1 на 100% идентична тому, как мы это делали в предыдущей статье:


R1#sh run ! crypto keyring key_V5R1 vrf V5R1 pre-shared-key address 54.54.54.4 key o1o1o ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 crypto isakmp profile VRF vrf V5R1 keyring key_V5R1 match identity address 54.54.54.4 255.255.255.255 V5R1 !

А вот с другой стороны на V5R4 мы не знаем IP-адреса маршрутизаторов, с которыми будем устанавливать VPN. Этот факт нам необходимо отразить в конфиге, в противном случае ISAKMP security association (sa) установлено не будет. Делаем мы это следующим образом:


R4# ! crypto keyring key_V5R4 vrf V5R4 pre-shared-key address 0.0.0.0 0.0.0.0 key o1o1o ! crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 crypto isakmp profile VRF vrf V5R4 keyring key_V5R4 match identity address 0.0.0.0 V5R4 !

Потенциально, любой человек, в том числе злоумышленник, зная ключ (pre-share-key) сможет подсоединиться к нам и установить VPN соединение. Поэтому надо продумывать вопросы безопасности: как вариант, использовать сертификаты вместо pre-shared-key. Однако данный вопрос безопасности в принципе влияет на использования pre-shared-key для VPN в целом, а не только в случае VRF.

Следующий шаг – создание IPSec transform-set, здесь все так же, как и было, никаких изменений (понятное дело, что создаем мы ее на всех маршрутизаторах, которые вовлечены в процесс IPSec VPN):


R4# ! crypto ipsec transform-set virtualXI esp-aes 256 esp-sha-hmac !

Двигаемся дальше и переходим к созданию crypto map. Одним из параметров, который указывается в crypto map, является трафик, который активирует данное соединение. Этот трафик определяется списком доступа:


R1# ! access-list 101 permit ip 192.168.51.0 0.0.0.255 192.168.54.0 0.0.0.255 !

Теперь сама crypto map (на V5R1 опять же, нет никаких особых отличий, даже к VRF не привязываем):


R1# ! crypto map Virtual 10 ipsec-isakmp set peer 54.54.54.4 set transform-set virtualXI set isakmp-profile VRF match address 101 !

На V5R4 нет каких-то особых фокусов, если у тебя раньше был опыт работы с crypto dynamic-map. Если нет, то тогда они, в смысле эти самые фокусы, и появляются:


R4# ! crypto dynamic-map Virtual 10 set transform-set virtualXI set isakmp-profile VRF match address 101 reverse-route !

В принципе все похоже, за исключением того, что мы не указываем явно «set peer X.X.X.X», что нельзя было не сделать в обычном crypto map. Еще один момент, на который я хочу обратить внимание,- это «reverse-route». Эта команда означает то, что в маршрут к удаленной подсети, к которой организовывается VPN, добавляется в таблицу маршрутизации.

После создания dynamic-map необходимо создать саму crypto map, то есть связать эти настройки:


R4# ! crypto map Vi 10 ipsec-isakmp dynamic Virtual !

Фактически, у нас все готово для того, чтобы запустить в эксплуатацию наш VPN. Финальный штрих, который остается нам сделать, - это привязка crypto map к интерфейсам, откуда будет сам VPN строиться:


R1# ! interface FastEthernet0/0.50 crypto map Virtual !

R4#
! interface FastEthernet0/0.52 crypto map Vi !

Собственно, это все: теперь делаем с V5R1 команду «ping vrf V5R1 192.168.54.1 source loopback 51» и видим, как поднимается наш VPN. Первый пакет потеряется, так как изначально соединение у нас не установлено, и он его инициирует, а остальные пинги добегут и вернуться успешно обратно. Посмотрим, что и как у нас установлено в плане sa (ISAKMP, IPSec):


R1#sh cry ipsec sa interface: FastEthernet0/0.50 Crypto map tag: Virtual, local addr 51.51.51.1 protected vrf: V5R1 local ident (addr/mask/prot/port): (192.168.51.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.54.0/255.255.255.0/0/0) current_peer 54.54.54.4 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 19, #pkts encrypt: 19, #pkts digest: 19 #pkts decaps: 19, #pkts decrypt: 19, #pkts verify: 19 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 31, #recv errors 0 local crypto endpt.: 51.51.51.1, remote crypto endpt.: 54.54.54.4 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0.50 current outbound spi: 0xAFCF2104(2949587204) inbound esp sas: spi: 0x3CFD35EA(1023227370) transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2001, flow_id: SW:1, crypto map: Virtual sa timing: remaining key lifetime (k/sec): (4569338/2904) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xAFCF2104(2949587204) transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 2002, flow_id: SW:2, crypto map: Virtual sa timing: remaining key lifetime (k/sec): (4569338/2903) IV size: 16 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:

Видим, что пакеты передаются через VPN, так как количество зашифрованных/дешифрованных пакетов не нулевое. Если мы пустим еще пинг, то оно увеличиться на количество отправленных/принятых пакетов.

Таблица маршрутизации на R3, после установления VPN с V5R1 и V5R2 выглядит следующим образом:


R4#sh ip ro vrf V5R4
Routing Table: V5R4 Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route
Gateway of last resort is 54.54.54.3 to network 0.0.0.0
54.0.0.0/29 is subnetted, 1 subnets C 54.54.54.0 is directly connected, FastEthernet0/0.52 C 192.168.54.0/24 is directly connected, Loopback54 S 192.168.52.0/24 [1/0] via 52.52.52.1 S 192.168.51.0/24 [1/0] via 51.51.51.1 S* 0.0.0.0/0 [1/0] via 54.54.54.3

Вот и все ? Подведем краткий итог данной статьи. Мы рассмотрели постройку IPSec VPN в случае, когда адрес одного из участников VPN не известен. Для этого нам понадобилось использование dynamic-map, которое позволяет данный функционал реализовать. А адрес у нас не известен, потому что получается от провайдера по DHCP, соответственно мы разобрали еще и настройку DHCP. И все это в виртуальных сетях, для виртуальных маршрутизаторов VRF.

Полный конфиг, по традиции, можно посмотреть здесь. Удачи, друзья!

Пожалуйста, зарегистрируйтесь или войдите в систему для добавления комментариев к этой статье.
Share to Facebook Share to Twitter Share to Linkedin Share to Myspace Share to Google 
.