Построение dmVPN с использованием Cisco и S-Terra
7 октября 2013
Так уж получилось, что официально ввоз оборудования со строгим шифрованием (длиной ключа более 56 бит) практически прикрыли. Тема обсуждалась много, и те, кто уже имеет развернутые на Сisco vpn сети, особо не беспокоятся – не трогают, и ладно. А вот организовать новую небольшую филиалку на Cisco или расширить существующую стало несколько проблематично (уходящие в End-of-Sale маршрутизаторы как и темы со сменой ПО с NPE-K9 на K9 и накатывания SEC лицензий рассматривать не буду – это, все-таки, незаконно).
Что из себя представляет классический dmVPN? В двух словах – имеем Центральное устройство — Hub и кучу удаленных Узлов — Spoke, с динамической маршрутизацией между ними и копипастной настройкой новых Spoke – изменения в конфиге минимальны, центральный Hub трогать не надо, маршруты сами разлетятся по сети. Красота!
Что же нужно дописать и доделать, чтобы схема работала не на Cisco, а на связке Cisco плюс S-Terra?
Классическая схема усложняется тем, что шифрование с Cisco выносится на отдельное устройство. Это может быть как модуль в маршрутизатор Cisco ISR, так и отдельный шлюз.
В нашем случае – в Центре ставится Cisco 2851 + модуль MCM, в удаленном узле – Cisco 1941 + HWIC-4ESW + CSP VPN Gate 100.
Хочу заметить, что хотя инициируется соединение всегда удаленным узлом, туннель фактически все время остается поднятым за счет крутящегося внутри OSPF.
Организовываем на Центральном маршрутизаторе dmVPN Hub.
Теперь настраиваем крипто-шлюз. Зайти на него можно через интерфейс Service-Engine:
c2851#service-module Special-Services-Engine 1/0 session
а выйти – нажав Ctrl+Shift+6, затем «x» и набрав
c2851#service-module Special-Services-Engine 1/0 session clear
Итого: пакет приходит на маршрутизатор, упаковывается в GRE на туннельном интерфейсе, отправляется на крипто-шлюз, крипто-шлюз шифрует GRE и выкидывает обратно на Cisco 2851, где он проходит через NAT и улетает в публичную сеть.
Далее он прибывает на Cisco 1941, и проходит тот же путь что и на Cisco 2851, только в обратном порядке.
Теперь осталось настроить CSP VPN Gate 100:
Теперь при включении устройств OSPF поднимет туннели, обменяется маршрутами, и пользователи одной сети смогут успешно достучаться до пользователей другой.
К сожалению, при данной схеме никак не обойти необходимость небольшой настройки Hub при добавлении Spoke – поэтому вся прелесть dmVPN несколько теряется. Однако масшатбы настройки гораздо меньше по сравнению с классическим Site-to-Site, и это не может не радовать.
В заключении хотелось бы сказать, что cisco-like CLI S-Terra – это всего лишь интерпретатор команд, которые затем переводятся в команды для Linux, установленного на всех их устройствах. Работа интерпретатора довольно специфична, впрочем, техподдержка у S-Terra довольно отзывчива и может помочь, если что-то не заладится.
При подготовке использовались материалы cisco.com и s-terra.com, а также переписка с технической поддержкой S-Terra. (http://habrahabr.ru/post/114328/ )
Что из себя представляет классический dmVPN? В двух словах – имеем Центральное устройство — Hub и кучу удаленных Узлов — Spoke, с динамической маршрутизацией между ними и копипастной настройкой новых Spoke – изменения в конфиге минимальны, центральный Hub трогать не надо, маршруты сами разлетятся по сети. Красота!
Что же нужно дописать и доделать, чтобы схема работала не на Cisco, а на связке Cisco плюс S-Terra?
Классическая схема усложняется тем, что шифрование с Cisco выносится на отдельное устройство. Это может быть как модуль в маршрутизатор Cisco ISR, так и отдельный шлюз.
В нашем случае – в Центре ставится Cisco 2851 + модуль MCM, в удаленном узле – Cisco 1941 + HWIC-4ESW + CSP VPN Gate 100.
Хочу заметить, что хотя инициируется соединение всегда удаленным узлом, туннель фактически все время остается поднятым за счет крутящегося внутри OSPF.
Организовываем на Центральном маршрутизаторе dmVPN Hub.
!---Создаем LoopBack через который будут строиться туннели
!
interface Loopback0
description -- loopback interface
ip address 172.31.100.1 255.255.255.255
!
!---Создаем туннельный интерфейс
!
interface Tunnel0
description -- dmvpn hub S-Terra interface
bandwidth 10000
ip address 172.16.0.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication dmvpn172
ip nhrp map multicast dynamic
ip nhrp network-id 172
ip nhrp holdtime 360
ip tcp adjust-mss 1360
ip ospf network broadcast
ip ospf priority 10
delay 1000
tunnel source Loopback0
tunnel mode gre multipoint
tunnel key 100000
!
!---Поднимаем OSPF внутри туннелей
!
router ospf 1
router-id 172.31.100.1
log-adjacency-changes
redistribute connected subnets route-map rm_conn_net
network 172.16.0.0 0.0.0.255 area 0
!
ip access-list extended acl_connected_network
remark -- redistribute networks to ospf
permit ip 192.168.0.0 0.0.0.255 any
permit ip host 172.31.100.1 any
!
route-map rm_conn_net permit 10
match ip address acl_connected_network
!
!
!---Теперь необходимо, чтобы туннелированый трафик шифровался на крипто-шлюзе.
!---Для этого указываем, что loopback удаленного узла доступен через адрес крипто-шлюза
!
ip route 172.31.100.10 255.255.255.255 172.31.0.2 name c1941-loop
!
!---Поднимаем интерфейс до крипто-шлюза
!
interface Special-Services-Engine1/0
ip address 172.31.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
no keepalive
!
!---Пропускаем через NAT шифрованные пакеты
!
ip nat inside source static udp 172.31.0.2 500 10.0.0.1 500 extendable
ip nat inside source static udp 172.31.0.2 4500 10.0.0.1 4500 extendable
!
Теперь настраиваем крипто-шлюз. Зайти на него можно через интерфейс Service-Engine:
c2851#service-module Special-Services-Engine 1/0 session
а выйти – нажав Ctrl+Shift+6, затем «x» и набрав
c2851#service-module Special-Services-Engine 1/0 session clear
!
crypto isakmp identity hostname
ip host csp-c1941 10.0.0.10
hostname csp-nmervpn
!
!
crypto isakmp policy 100
hash sha
encr aes
authentication pre-share
group 2
!
crypto isakmp key dmvpn172 hostname csp-c1941
!
crypto ipsec transform-set ts_dmvpn172 esp-aes esp-sha-hmac
!
ip access-list extended acl_crypto
permit gre host 172.31.100.1 any
!
crypto dynamic-map dm_vpn 100
match address acl_crypto
set transform-set ts_dmvpn172
!
crypto map cm_vpn 100 ipsec-isakmp dynamic dm_vpn
!
interface FastEthernet0/0
ip address 172.31.0.2 255.255.255.0
crypto map cm_vpn
!
ip route 0.0.0.0 0.0.0.0 172.31.0.1
!
Итого: пакет приходит на маршрутизатор, упаковывается в GRE на туннельном интерфейсе, отправляется на крипто-шлюз, крипто-шлюз шифрует GRE и выкидывает обратно на Cisco 2851, где он проходит через NAT и улетает в публичную сеть.
Далее он прибывает на Cisco 1941, и проходит тот же путь что и на Cisco 2851, только в обратном порядке.
!---Создаем LoopBack через который будут строиться туннели
!
interface Loopback0
description -- router id
ip address 172.31.100.10 255.255.255.255
!
!---Создаем туннельный интерфейс
!
interface Tunnel0
description -- dmvpn spoke interface
bandwidth 10000
ip address 172.16.0.10 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication dmvpn172
ip nhrp map 172.16.0.1 172.31.100.1
ip nhrp map multicast 172.31.100.1
ip nhrp network-id 172
ip nhrp nhs 172.16.0.1
ip tcp adjust-mss 1360
ip ospf network broadcast
ip ospf priority 0
delay 1000
tunnel source Loopback0
tunnel mode gre multipoint
tunnel key 100000
!
!---Поднимаем интерфейс до крипто-шлюза
!
interface Vlan2
description -- to S-Terra Gate100
ip address 172.31.10.1 255.255.255.0
ip nat inside
!
!---В порт 0/0/0 будет подключен VPN Gate 100
!
interface FastEthernet0/0/0
description -- to S-Terra Gate100
switchport access vlan 2
!
!---В остальные порты – локальная сеть
!
interface FastEthernet0/0/1
description -- local net
!
interface FastEthernet0/0/2
description -- local net
!
interface FastEthernet0/0/3
description -- local net
!
interface Vlan1
description -- to local net
ip address 192.168.10.1 255.255.255.0
ip nat inside
!
!---Поднимаем OSPF внутри туннелей
!
router ospf 2
router-id 172.31.100.10
log-adjacency-changes
redistribute connected subnets route-map rm_conn_net
network 172.16.0.0 0.0.0.255 area 0
!
ip access-list extended acl_conn_net
remark -- redistribute networks to ospf
permit ip 192.168.10.0 0.0.0.255 any
permit ip host 172.31.100.10 any
!
route-map rm_conn_net permit 10
match ip address acl_conn_net
!
!---Пропускаем через NAT шифрованные пакеты
!
ip nat inside source static udp 172.31.10.2 500 10.0.0.10 500 extendable
ip nat inside source static udp 172.31.10.2 4500 10.0.0.10 4500 extendable
!Теперь осталось настроить CSP VPN Gate 100:
!
crypto isakmp identity hostname
ip host csp-nmervpn 10.0.0.1
hostname csp-c1941
!
crypto isakmp policy 100
hash sha
encr aes
authentication pre-share
group 2
!
crypto isakmp key dmvpn172 hostname csp-nmervpn
!
crypto ipsec transform-set ts_dmvpn172 esp-aes esp-sha-hmac
!
ip access-list extended acl_crypto
permit gre host 172.31.100.10 host 172.31.100.1
!
crypto map cm_vpn 100 ipsec-isakmp
match address acl_crypto
set transform-set ts_dmvpn172
set peer 10.0.0.1
!
interface FastEthernet0/1
description – to c1941-1
ip address 172.31.10.1 255.255.255.0
crypto map cm_vpn
!
ip route 0.0.0.0 0.0.0.0 172.31.10.1
!
crypto isakmp peer address 10.0.0.1
set aggressive-mode client-endpoint ipv4-address 10.0.0.1
!
Теперь при включении устройств OSPF поднимет туннели, обменяется маршрутами, и пользователи одной сети смогут успешно достучаться до пользователей другой.
К сожалению, при данной схеме никак не обойти необходимость небольшой настройки Hub при добавлении Spoke – поэтому вся прелесть dmVPN несколько теряется. Однако масшатбы настройки гораздо меньше по сравнению с классическим Site-to-Site, и это не может не радовать.
В заключении хотелось бы сказать, что cisco-like CLI S-Terra – это всего лишь интерпретатор команд, которые затем переводятся в команды для Linux, установленного на всех их устройствах. Работа интерпретатора довольно специфична, впрочем, техподдержка у S-Terra довольно отзывчива и может помочь, если что-то не заладится.
При подготовке использовались материалы cisco.com и s-terra.com, а также переписка с технической поддержкой S-Terra. (http://habrahabr.ru/post/114328/ )