Исходная задача выглядит следующим образом: имеется центральный офис (CO) и набор дополнительных офисов (DO). Каждый из них подключен к Internet, а также между CO и DO арендованы каналы MPLS VPN L3 типа «точка-точка». Канал Internet в CO подключен к Cisco ASA v8.4 (CO-ASA), MPLS VPN L3 – к Cisco IOS (CO-R). В DO все каналы сводятся в Cisco ASA v8.4 (DO-ASA).
Необходимо обеспечить маршрутизацию трафика между офисными сетями CO (192.168.2.0/24, 192.168.7.0/24) и DO (192.168.1.0/24) посредством IPSec VPN с обеспечением резервирования. Т.е. IPSec VPN, идущий через Internet является основным, в случае его неработоспособности происходит автоматическое переключение на резервный IPSec VPN поверх MPLS VPN L3. Ситуация усложняется тем, что шлюзом по умолчанию в офисной сети CO является CO-ASA, а сеть 192.168.7.0/24 включена напрямую в CO-R. В виду ряда организационных и технических проблем переключение всех каналов на одно устройство CO-ASA или CO-R в центральном офисе невозможно.
CO-R:
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key YtPCnXYKiL94sgLvqXdfYTO93ByIx7V8 address 172.17.1.1
!
crypto ipsec transform-set vpn-set esp-3des esp-md5-hmac
!
crypto map do-vpn-map 1 ipsec-isakmp
set peer 172.17.1.1
set transform-set vpn-set
match address 100
!
interface FastEthernet4
ip address 172.17.1.2 255.255.255.0
duplex auto
speed auto
crypto map do-vpn-map
!
access-list 100 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 100 permit ip 192.168.7.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 100 deny ip any any
!
CO-ASA:
!
object network obj-do-lan
subnet 192.168.1.0 255.255.255.0
object-group network obj-local-lan
network-object 192.168.2.0 255.255.255.0
network-object 192.168.7.0 255.255.255.0
!
access-list vpn_access extended permit ip object-group obj-local-lan object obj-do-lan
!
nat (lan,wan) source static obj-local-lan obj-local-lan destination static obj-do-lan obj-do-lan
!
crypto ipsec ikev1 transform-set vpn-set esp-3des esp-md5-hmac
crypto map co-vpn 1 match address vpn_access
crypto map co-vpn 1 set pfs
crypto map co-vpn 1 set peer 198.18.131.1
crypto map co-vpn 1 set ikev1 transform-set vpn-set
crypto map co-vpn interface wan
crypto ikev1 enable wan
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
!
tunnel-group 198.18.131.1 type ipsec-l2l
tunnel-group 198.18.131.1 ipsec-attributes
ikev1 pre-shared-key INo8YKu4xrYDwk1TWpKuHBiB023PC1LP
!
DO-ASA:
!
object network obj-local-lan
subnet 192.168.1.0 255.255.255.0
object-group network obj-co-lan
network-object 192.168.2.0 255.255.255.0
network-object 192.168.7.0 255.255.255.0
!
access-list vpn_access extended permit ip object obj-local-lan object-group obj-co-lan
!
nat (lan,wan) source static obj-local-lan obj-local-lan destination static obj-co-lan obj-co-lan
!
crypto ipsec ikev1 transform-set vpn-set esp-3des esp-md5-hmac
crypto map co-vpn 1 match address vpn_access
crypto map co-vpn 1 set pfs
crypto map co-vpn 1 set peer 198.18.131.2 172.17.1.2
crypto map co-vpn 1 set ikev1 transform-set vpn-set
crypto map co-vpn interface wan
crypto map co-vpn interface man
crypto ikev1 enable wan
crypto ikev1 enable man
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
!
tunnel-group 172.17.1.2 type ipsec-l2l
tunnel-group 172.17.1.2 ipsec-attributes
ikev1 pre-shared-key YtPCnXYKiL94sgLvqXdfYTO93ByIx7V8
tunnel-group 198.18.131.2 type ipsec-l2l
tunnel-group 198.18.131.2 ipsec-attributes
ikev1 pre-shared-key INo8YKu4xrYDwk1TWpKuHBiB023PC1LP
!
Обратите внимание на особенность настройки DO-ASA: мы прописываем IPSec VPN сразу к двум хостам: «crypto map co-vpn 1 set peer 198.18.131.2 172.17.1.2». Это значит, что первоначально будет предпринята попытка поднять IPSec VPN с peer’ом 198.18.131.2. Если она потерпит неудачу, то будет совершена вторая попытка с peer’ом 172.17.1.2.
Однако сейчас этот механизм работать не будет. Для этого необходимо обеспечить динамическую перенастройку таблицы маршрутизации на DO-ASA. Для этих целей используется функционал «sla monitor»:
!
route wan 0.0.0.0 0.0.0.0 198.18.131.2 1 track 1
route man 0.0.0.0 0.0.0.0 172.17.1.2 2
!
sla monitor 1
type echo protocol ipIcmpEcho 198.18.131.2 interface wan
num-packets 3
request-data-size 100
threshold 2500
sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
Таким образом DO-ASA посредством пакетов ICMP Echo request постоянно контролирует доступность CO-ASA. Если последняя пингуется, то весь трафик направляется в Internet:
Следующая проблема – это обеспечение маршрутизации трафика в локальной сети центрального офиса: 192.168.2.0/24. Напомню, что в ней маршрутом по умолчанию является CO-ASA (192.168.2.6), поэтому пока работает основной канал IPSec VPN, никаких проблем не возникает. Однако, как только он отваливается, необходимо перенаправлять весь трафик, адресованный в сеть DO (192.168.1.0/24), на CO-R (192.168.2.7). Правильным решением в подобной ситуации является использование динамической маршрутизации на базе протокола OSPF. Но тут нас ждет очередное разочарование в Cisco ASA. Из отсутствия поддержки IPSec VPN GRE следует необходимость использования на внешнем интерфейсе ASA тип сети «ospf network point-to-point non-broadcast». Поддержки чего-либо наподобие «ip ospf network point-to-multipoint non-broadcast» в ASA нет. А когда интерфейс настроен как point-to-point, на нем не может быть более одного соседа OSPF. Поэтому эта схема может использоваться только для связи двух точек. Напомню, что по исходному заданию дополнительный офис у нас не один, а их множество. Исходя из этого запустить OSPF на CO-ASA не представляется возможным 🙁
Поэтому придется обходиться уже известным нам методом манипулирования статическими маршрутами посредством sla monitor.
CO-ASA:
!
route wan 192.168.1.0 255.255.255.0 198.18.131.1 1 track 1
route lan 192.168.1.0 255.255.255.0 192.168.2.7 2
!
sla monitor 1
type echo protocol ipIcmpEcho 198.18.131.1 interface wan
num-packets 3
request-data-size 100
threshold 2500
sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1 reachability
!
Т.е. CO-ASA пингует DO-ASA (198.18.131.1) и в случае недоступности оного весь трафик перенаправляется на CO-R (192.168.2.7). Соответственно получается, что в случае сбоя хосты локальной сети CO (192.168.2.0/24) будут направлять весь трафик на CO-ASA (192.168.2.6), а та в свою очередь перенаправлять его на CO-R (192.168.2.7). Для того, что бы такое перенаправление работало, необходимо на CO-ASA добавить следующую опцию:
!
same-security-traffic permit intra-interface
!
Поскольку оба маршрутизатора и CO-ASA, и CO-R находятся в одной общей сети 192.168.2.0/24, то есть вероятность, что CO-ASA будет бомбардировать хосты локальной сети 192.168.2.0/24 пакетами ICMP Redirect, что может приводить к глюкам маршрутизации у рабочих станций.
Следующая проблема: при переключении на резервный канал трафик ICMP и UDP будет ходить без проблем, а вот TCP – нет. Виной тому асимметрия в маршрутизации:
!
access-list vpn_tcp_bypass_access extended permit ip object-group obj-local-lan object obj-do-lan
!
class-map vpn_tcp_bypass
match access-list vpn_tcp_bypass_access
!
policy-map vpn_tcp_bypass_policy
class vpn_tcp_bypass
set connection advanced-options tcp-state-bypass
!
service-policy vpn_tcp_bypass_policy interface lan
!
Теперь весь трафик, идущий из сетей CO (192.168.2.0/24, 192.168.7.0/24) в DO (192.168.1.0/24) не будет попадать под действие Adaptive Security Algorithm на CO-ASA.
До сих пор в тени оставалась сеть 192.168.7.0/24. С ней тоже существует проблема, поскольку включена он напрямую в CO-R, а на последнем весь исходящий трафик будет отправляться через канал MPLS VPN L3 независимо от того активен ли в настоящее время резервный канал IPSec VPN или нет. Происходить это будет просто в виду настроек статической маршрутизации:
!
ip route 0.0.0.0 0.0.0.0 172.17.1.1
!
Тут нам на помощь приходит Policy-based Routing (PBR), который настраивается на CO-R:
!
interface Vlan2
ip address 192.168.7.1 255.255.255.0
ip policy route-map pcs-vpn
!
access-list 101 permit ip 192.168.7.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 101 deny ip any any
!
route-map pcs-vpn permit 10
match ip address 101
set ip next-hop 192.168.2.6
!
Т.е. весь трафик из CO (192.168.7.0/24) будет в принудительном порядке отправлять на CO-ASA (192.168.2.6), а уже она либо отправит его через основной канал IPSec VPN, либо в случае сбоя отправит обратно на CO-R (192.168.2.7), а уже тот в свою очередь задействует резервный канал IPSec VPN. Вот такая получается загогулина в маршрутизации трафика 🙂
Конечно, схема получилась крайне запутанная и сложная в понимании. Однако поверьте мне, я был поставлен в жесткие рамки и вынужден придумать такой вот ребус. На будущее хочу пожелать вам хорошенько продумывать и проектировать топологию своих сетей. Известному советскому авиаконструктору Андрей Николаевичу Туполеву принадлежит фраза: «Хорошо летать могут только красивые самолеты». Так вот правильно и хорошо спроектированная сеть смотрится красиво и легко администрируется. И тогда нет нужды придумывать и внедрять сложные решения.
Архив с полными конфигами оборудования.