ASA. Резервирование IPSec туннелей, RA VPN.

Итак, с чего бы начать повествование… Пожалуй, начну с того, как все было раньше и как развивалось. Я пришел в компанию-интегратор около двух лет назад. До этого в течении пяти лет я трудился у операторов ШПД и мобилников. Там я занимался магистральной сетью. Здесь же пришлось перейти на другой уровень - сетей предприятия. Если операторские сети характеризуются большим трафиком и кучей маршрутов, то сети предприятий - это интеллектуальные услуги с небольшим трафиком. Везде своя специфики, разные устройства.

Любой интегратор - контора проектная, где прибыль приносят исключительно проекты. Когда специалист занимается настройкой или проектированием по какому-либо проекту, оплата его труда идет из бюджета этого проекта. В компании есть внешние проекты - проекты, которые приносят деньги, и есть внутренние - такие как “Поддержка внутренней сетевой инфраструктуры” и т.д. Внутренние тоже требуют затрат труда, но руководители проектов не любят тратить бюджет вутренний, да и специалисты не любят внутренние проекты из-за того, что по ним час труда стоит меньше (эдакая мотивация заниматься внешними коммерческими проектами). Из вышесказанного можно сделать вывод, что внутренняя структура ИТ находится на уровне “чтобы работало”, но с минимальными затратами.

Когда я пришел в фирму, внутренняя сеть представляла собой классический пример SOHO (даже не SMB). Единственное, что отличало  её от домашней сети - наличие нескольких VLAN (DMZ, WLAN, LAN). На периметре стояла одинокая ASA 5505 с единственным каналом в интернет. На этой железке был поднят сервис Remote Access VPN на Cisco Anyconnect с авторизацией через LDAP. Нужно заметить, что был реализован и доступ через Clientless SSL VPN со всеми его фичами такими как split-tunnel, java-приложения (rdp, vnc, telnet/ssh).

Временами у провайдера случались аварии. И все бы ничего, если бы в один прекрасный день, это не произошло во время электронных торгов, а именно какой-то борьбы за тендер. Так встал вопрос о подключении второго провайдера и резервировании доступа в интернет. Подключили ещё один канал от другого оператора. Новый канал падал чаще, но, тем не менее, они все время падали в разное время.

  На ASA я реализовал автоматическое переключение с использованием IP SLA и Track. Пингуем гугловский публичный днс через основной канал. Если пинги не проходят, убираем статический маршрут “по-умолчанию” с наибольшей метрикой (по срабатывани. track). Остается маршрут постоянный с большей метрикой. Резервирование интернета есть.

 Прошло некоторое время, и у фирмы появился офис в другом городе. Вся инфраструктуара находится, соответственно, в основном офисе. Появилась новая задача - подключить офис к существующим ресурсам с минимальными затратами. Так появилась ещё одно ASA и IPSec site-to-site туннель. И всё шло хорошо до первого падения основного канала. Туннель не резервируется. На ASA основного офиса нет возможности построить два туннеля через разные интерфейсы на один IP адрес т.к. маршрут наружу для удаленного хоста идет только через один интерфейс. В момент падения туннели приходилось переделывать руками.

 Так получилось, что у меня оказалась одна свободная ASA 5505. Я решил задействовать её, переместив на нее резервный канал в интернет. В виду минимальных расходов на собственную инфраструктуру в ядре нашей сети нет коммутатора L3, поэтому пока не реализовано резервирования “шлюза по-умолчанию”, в связи с чем я решил включить вторую ASA в первую (ASA не поддерживает ни один из FHRP). При начилчии коммутатора L3 в ядре резервирование “шлюза по-умолчанию” делается на динамическом протоколе маршрутизации.

 Начальная схема:

         Пока что все понятно. Идем далее. Первый вопрос у меня возник, когда нужно было создать два туннеля на ASA удаленного офисе, с крипто-картами, который вибирают для себя трафик на одни и те же сети. Обе крипто-карты приклеены к одному интерфейсу outside. Я начал гуглить на тему IPSec redundancy. Для отказоустойчивости применяется hsrp между двумя основными устройствами устройствами. Мне этот вариант не подходит по двум причинам. Первое - у меня нет публичной /29 сети, второе - ASA не поддерживает FHRP. Продолжив искать, я нашел, что нужно сделать одну крипто-карту для обоих туннетей, но указать в ней несколько set peer. В графике это выглядет так:

Туннели на две ASA основного филиала.

Единая крипто-карта с указанием двух пиров.

         Сначала пытается поднятся туннель, который указан первым в списке. Если не доступен первый адрес, поднимается второй туннель. По крайней мере я так понял логику. А что, если у нас основной канал работает, но через него по какой-то причине не доступен хост филиала? Сеть филиала будет недоступна несмотря на второй туннель т.к. первая ASA основного офиса выплевывает все в интерфейс Spark (внешний) по дефолтному маршруту. Если мы укажем маршрут для сети 192.168.248.0/24 через 10.255.255.49 (вторая АСА основного офиса), то все заработает, но в случае, когда поднимится туннель через основной маршрут, опять появится эффект черной дыры для этого префикса. Для решения этой проблемы я использовал OSPF и IP SLA. На обеих асах основного офиса я настроил трекер, ктороый срабатывает по доступности/недоступности IP адреса удаленного филиала. Выглядит это так (пример настройки для одной ASA):

!

sla monitor 20

type echo protocol ipIcmpEcho 217.28.235.1 interface outside

num-packets 4

frequency 30

sla monitor schedule 20 life forever start-time now

!

track 20 rtr 20 reachability

!

После этого привязал к треку статический маршрут на сеть удаленного офиса:

!

route outside 192.168.248.0 255.255.255.0 217.28.235.14 200 track 20

!

Отправляем все в OSPF:

!

router ospf 1

router-id 1.1.1.1

network 10.255.255.48 255.255.255.252 area 0

area 0 authentication

log-adj-changes

redistribute static subnets route-map STATIC-TO-OSPF

default-information originate metric 50

!

Всегда при дистрибуции использую роутмапы:

!

route-map STATIC-TO-OSPF permit 1

match ip address prefix-list INT_MSK-OFFICE

!

prefix-list INT_MSK-OFFICE seq 5 permit 192.168.248.0/24

В результате у нас имеется по статическому маршруту с треком на каждой асе. Если падает основной канал Spark, то статический маршрут исчезает из таблицы, на его место становится маршрут из OSPF с большим административным расстоянием.

         Выход в интернет резервируется аналогично через SLA и OSPF. В случае падения канала Spark, исчезает маршрут 0.0.0.0/0, заменяется таким же маршрутом из OSPF, который генерится из статоческого на второй асе с помощью “default-information originate metric 50”.

           Далее нужно зарезервировать и обеспечить одновременную работу на обоих каналах работу сервиса Remote Access VPN. Я решил всять пож это сетку 192.168.251.0/24. Для певрой асы я отдал 192.168.251.10-100/24, для второй дал 192.168.110-150/24. Можно было дать каждой по /24 сети, можно было разбить на /25 или /26. Я просто сделал так как сделал. Вполне заканный вопрос - как маршрутизировать это всё. При подключении клиента, ему выделяется адрес, который аса прописывает в таблицу маршрутизации как статический маршрут с /32 маской. Дописываем в prefix-list строчку, после чего асы будут редистрибутить в OSPF это /32 маршруты:

!

prefix-list VPNRA32 seq 5 permit 192.168.251.0/24 ge 32

!

Для сети 192.168.251.0/24 нужен доступ к сети 192.168.248.0/24. У нас развернута IP телефония. CM стотит в сети основного офиса, сигнализация идет через него, но SIP ходит непосредственно между абонентами. Чтобы пользователи, подключенные по RAVPN могли совершать звонки в удаленный офис, не забывает добавить в крипто-карты префикс сети RA, исключить его из NAT на внешних интерфейсах всех ASA.

В результате получается следующая картинка:

           И тут появляется последняя задача. Есть ресурсы, которые смотрять наружу, такие как ftp-сервер. На основном канале есть трансляция на внутренний сервер с адресом 192.168.247.111. Нужно сделать такую же трансляцию на резервном канале. Тут нужно помнить, что обратный адрес у пакетов будет внешний, а маршрут в мир в таблице маршрутизации один, и он смотрит в основной канал. Таким образом, пришедший с резервного канала пакет пойдет обратно через основной. Отправитель получит ответ с другого адреса, пакет будет отброшен. Работать так не будет. Я использовал двойной нат. Менял не только адрес назначения, но и адрес источника. Для этого сделал пул серывх адресов 192.168.252.0/24 и им закрывал источник пакетов при выходе с интервейса eth1 второй асы.

!

nat (peer,outside) source static test-ftp interface destination static INT_PAT_POOL any service src_tcp_21 src_tcp_21 description Double NAT

!

Сетка 192.168.252.0/24 также светится в OSPF.

Осталось перетянуться ядро на L3 коммутатор и причесать данную схемку. Задачи выполнены. Тут я просто описал ход своего решения поставленных задач.

Итог: