Отказоустойчивость VPN-сервера Cisco ASA

Недавно мы заменили международные MPLS новыми ASA 5510 и VPN-соединениями. Однако, когда мы развернули это, мы столкнулись с проблемой, когда в каждом удаленном местоположении есть 2 провайдера для резервирования, но при включении VPN на обоих интерфейсах он закрывается между ними, а туннель - вверх и вниз по мере того, как туннель срывается и перемещается между Интернет-провайдеры. Cisco работает над этим уже 8 месяцев, и у нас все еще нет стабильных туннелей с несколькими интернет-провайдерами.

Удаленный офис:

список доступа RWS_TUNNEL примечание Интересный трафик для туннеля IND-RWS
access-list RWS_TUNNEL расширенное разрешение ip object-group BNG_tunnel_NETS объект-группа CORP_tunnel_NETS
криптографическая карта RWS_TUNNEL 1 адрес соответствия RWS_TUNNEL
криптографическая карта RWS_TUNNEL 1 set peer 216.xxx.102.2
криптографическая карта RWS_TUNNEL 1 набор преобразований IND-RWS
туннельная группа 216.xxx.102.2 тип ipsec-l2l
туннельная группа 216.xxx.102.2 ipsec-attributes
 pre-shared-key *****


маршрут вне 0.0.0.0 0.0.0.0 216.xxx.206.1 1 трек 2
маршрут outside2 0.0.0.0 0.0.0.0 182.xxx.26.229 100
монитор sla 55
 тип echo protocol ipIcmpEcho 63.251.61.142 интерфейс снаружи
 num-packages 5
 таймаут 1000
 частота 10
sla monitor schedule 55 life forever start-time now
трек 2 rtr 55 достижимость

Центральный офис:

список доступа BNG_TUNNEL примечание Интересный трафик для туннеля IND-RWS
список доступа BNG_TUNNEL расширенное разрешение ip object-group CORP_tunnel_NETS объект-группа BNG_tunnel_NETS

route outside2 0.0.0.0 0.0.0.0 216.xxx.102.1
криптографическая карта BNG_TUNNEL 1 адрес соответствия BNG_TUNNEL
криптографическая карта BNG_TUNNEL 1 набор одноранговых узлов 182.xxx.26.230 216.xxx.206.4
криптографическая карта BNG_TUNNEL 1 набор преобразований L2L

туннельная группа 182.xxx.26.230 тип ipsec-l2l
туннельная группа 182.xxx.26.230 ipsec-attributes
 pre-shared-key *****
туннельная группа 216.xxx.206.4 тип ipsec-l2l
туннельная группа 216.xxx.206.4 ipsec-attributes
 pre-shared-key *****

Итак, я обнаружил, что когда ISAKMP включен на обоих внешних интерфейсах (удаленный офис), и оба IP-адреса настроены как одноранговые узлы (центральный офис), VPN успешно появляется на обоих интерфейсах, но в какой-то момент начнет раскачиваться между IP-адресами. Это верно или без мониторинга SLA, поэтому, даже если маршруты все статичны, поведение по-прежнему происходит.

Любое понимание понимается.

19 голосов | спросил Scott Boultinghouse 8 Mayam13 2013, 02:47:22

5 ответов


12

Я просто переношу сайты из виртуальных сетей на основе политик именно по этой причине. Виртуальные VPN на основе политики слишком непредсказуемы, когда дело доходит до поведения при отказе. Я предпочитаю туннели IPsec, основанные на маршрутах, либо от точки к точке, либо от DMVPN. К сожалению, насколько мне известно, платформа ASA по-прежнему не поддерживает туннели на основе маршрутов.

ответил Jeremy Stretch 8 Mayam13 2013, 04:28:19
7

Я бы рекомендовал использовать решение DMVPN для подключения удаленных сайтов через туннели IPSec L2L (Lan-to-Lan) между ASAs. Решение DMVPN намного проще, чище и позволяет разговаривать и с коммуникационным сообщением.

ответил twidfeki 8 Mayam13 2013, 03:42:54
2

Я согласен с вышеприведенными утверждениями. Пройдите простой IPSEC на основе VTI или, альтернативно, DMVPN. Просто не забудьте запустить разные экземпляры procotol маршрутизации внутри туннелей и без них. Да, вам придется заменить ASAs на ISR.

Оба провайдера возвращаются в один головной офис ASA или два? Если мне кажется, что это трудно увидеть (с доступной конфигурацией, по крайней мере), как это может происходить, но если его одна и та же ASA (или та же пара) может быть связана.

ответил wintermute000 8 Mayam13 2013, 09:33:22
2

Может быть:

CSCub92666

ASA: старые соединения разрушают туннель IPSEC vpn при переключении

Симптом: В туннеле IPsec vpn сбой в конфигурации на ASA работает сбой от первичной к резервной ссылке. Но после второго отказа от резервного копирования на первичный канал vpn туннель начинает захлопываться через несколько минут и остается нестабильным. Поведение наблюдается из-за старого оставшегося соединения, которое все еще указывает на резервную копию isp.

ответил t0i 9 FebruaryEurope/MoscowbSun, 09 Feb 2014 03:21:42 +0400000000amSun, 09 Feb 2014 03:21:42 +040014 2014, 03:21:42
1

В качестве продолжения этого вопроса я уже более года работаю с Cisco TAC. Наконец, они определили, что это ошибка, связанная с тем, как платформа ASA обрабатывает соединения. по сути, он не очищал соединения от одного интерфейса, когда он переместил туннель на другой интерфейс, и он вырвался из-под контроля, когда он начал видеть записи в таблице соединений из обоих интерфейсов.

Я развернул версию IOS 8.4.7 на брандмауэре с двумя интернет-провайдерами, и на самом деле он работает правильно. Отказоустойчивость происходит, когда основной интерфейс отключается, а затем возвращается назад, когда этот интерфейс возвращается и остается на этом интерфейсе. Посмотрим.

ответил Scott Boultinghouse 21 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 21 Sep 2013 01:02:04 +0400 2013, 01:02:04

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132