IPSec VPN между Cisco ASA и IOS с резервированием

Исходная задача выглядит следующим образом: имеется центральный офис (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 в центральном офисе невозможно.

Начнем с настроек IPSec VPN. И тут же сталкиваемся с первым ограничением: Cisco ASA не поддерживает IPSec VPN GRE (в сети есть упоминания о том, что IPSec VPN GRE все-таки можно заставить работать на ASA, но для этого на внешних интерфейсах необходимо прописать access-list размещающий любой трафик «permit ip any any», естественно такие настройки допустимы только на тестовом стенде). Поэтому придется довольствоваться тем, что в терминологии ASA называется IPSec VPN LAT-to-LAN (l2l).

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:

Если же нет, то шлюзом по умолчанию прописывается канал MPLS VPN L3:

Таким образом, обеспечивается переключение IPSec VPN peer’а с основного 198.18.131.2 на резервный 172.17.1.2.

Следующая проблема – это обеспечение маршрутизации трафика в локальной сети центрального офиса: 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 – нет. Виной тому асимметрия в маршрутизации:

Т.е. трафик, идущий из сети DO (192.168.1.0/24) в CO (192.168.2.0/24), не будет попадать на CO-ASA, т.е. она не будет видеть инициирующих пакетов TCP SYN. Проблема в том, что у Cisco ASA существует механизм носящий название Adaptive Security Algorithm. Он призван обеспечить безопасность всех сессий TCP путем ведения их учета. Поэтому если соответствующий пакет TCP SYN через Cisco ASA не проходил, то последняя считает, что TCP-сессия не устанавливалась и весь трафик принадлежащий ей отбрасывается. Для решения данной проблемы задействуем на CO-ASA функционал «TCP State Bypass»:

!
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. Вот такая получается загогулина в маршрутизации трафика 🙂

Конечно, схема получилась крайне запутанная и сложная в понимании. Однако поверьте мне, я был поставлен в жесткие рамки и вынужден придумать такой вот ребус. На будущее хочу пожелать вам хорошенько продумывать и проектировать топологию своих сетей. Известному советскому авиаконструктору Андрей Николаевичу Туполеву принадлежит фраза: «Хорошо летать могут только красивые самолеты». Так вот правильно и хорошо спроектированная сеть смотрится красиво и легко администрируется. И тогда нет нужды придумывать и внедрять сложные решения.

Архив с полными конфигами оборудования.

Поделиться ссылкой:

  1. У меня вот есть один вопрос. А не проще DMVPN плюс динамика, и ASA дать заниматься своим делом - фаэрвол плюс удаленный доступ сотрудников? И принимать провайдеров на фаерволы и роутеры не сильно хорошо.

    • еще я надеюсь у Вас нет 192,168,0,0 в продакшене......

    • Ответ на вопрос, откуда и зачем появилась такая сложная и запутанная схема, находится чуть выше, в предпоследнем абзаце заметки 😉 Также в ней нигде не содержится упоминания о подсети 192.168.0.0/24. Что же касается продакшена, то сеть, для которой это все придумывалось, уже не существует в виду ряда организационных изменений. Остались только вот эти наработки 🙂

Оставить комментарий


Примечание - Вы можете использовать эти HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>