отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Спросить эксперта: IPsec VPN на платформах Cisco ASA и IOS

с Сергеем Морозом

Read the bio

В ходе сессии "Спросить Эксперта" эксперт Cisco Сергей Мороз ответит на вопросы о настройке и отладке IPsec VPN туннелей на платформах Cisco ASA и Cisco IOS: IPsec LAN-to-LAN, EazyVPN, GRE/IPsec, VTI/IPsec, DMVPN, GetVPN, FlexVPN. Так же Вы сможете узнать и рекомендованных решениях и топологиях VPN для ваших задач.

Сергей Мороз - инженер центра технической поддержки Cisco (TAC). Работает в группе Security & VPN и поддерживает платформы Cisco ASA/FWSM, IPS, MARS, VPN3000, IOS.  Он имеет богатый опыт траблшутинга всех видов защищенных туннелей VPN на оборудовании Cisco. Имеет сертификаты CCIE R&S и Security #20950, а так же сертификат MCSE.

Пожалуйста, не забывайте оценивать ответы Сергея, чтобы он знал, что вы получили совет, который вам помог. Общение может быть продолжено на нашем форуме и после окончании сессии. Сессия продлится до 26-го июля.

Теги (6)
48 ОТВЕТ.
New Member

Спросить эксперта: IPsec VPN на платфор

Где-то читал, что ASA не поддерживает туннельные интерфейсы, верно? Будет ли реализована такая возможность в будущих версиях? Так уж случилось, что ASA у нас используется как маршрутизатор, держит EIGRP, и хотелось бы обойтись без крипто карт, а направлять траффик в туннель с помощью маршрутизации.

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

На сегодняшний день туннельные интерфейсы (GRE/IPsec) на платформе Cisco ASA не поддерживаются и поддержка их в ближайшее время не планируется.  Т.е. официально данный функционал не находится на roadmap.

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

На сегодняшний день на ASA поддерживаются только крипто мапы, и динамический роутинг через крипто мапы невозможен.  Единственное исключение - OSPF на ASA.  OSPF на ASA может работать через туннели L2L с крипто мапами, но с выполнением следующих ограничений:

1. Тип сети OSPF на интерфейсе с крипто мапом должен быть point-to-point.  Как следствие, OSPF может иметь только одного neighbor-а (и только один adjacency) на интерфейсе с крипто мапом.  Иными словами, динамический роутинг возможен только через один L2L туннель на каждом интерфейсе.

2. На обоих концах туннеля должна быть Cisco ASA.  При работе OSPF через IPsec L2L туннель, смежные интерфейсы роутеров OSPF оказываются в разных IP подсетях.  Маршрутизатор Cisco IOS не будет устанавливать OSPF adjacency между IP адресами из разных IP подсетей - это умеет делать только Cisco ASA.

C уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

А если с одной стороны туннеля у меня IOS маршрутизатор, то на нём я всё равно вынужден использовать криптокарты? Это связано с ProxyID списком доступа, так?

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

Если у вас с одной стороны ASA а с другой IOS, то вы можете сделать следующие виды туннелей:

1. IPsec LAN-to-LAN, и crypto map с обоих сторон.

2. EazyVPN: настроить одно устройство (скажем, IOS  роутер), как EazyVPN клиент, а другое (cкажем, ASA), как EazyVPN  server.  Или наоборот.  Тоже с crypto map с обоих сторон.

Динамического роутинга через туннель в любом случае  уже не будет, если у вас хотя бы с одной стороны IOS.  Возможен только  статический роутинг.

Вообще, будет лучше, если вы  опишете вашу дизайнерскую задачу, т.е. конечную цель, которой вы хотите  добиться.  Некоторые задачи с маршрутизацией через туннели решаются  механизмом RRI (Reverse Route Injection) даже при отсутствии  полноценного динамического роутинга.

C уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

Сергей,

мне бы хотелось избавиться от списков доступа ProxyID. Из-за рваных подсетей с обоих сторон и большого их количества эти списки разрастаются, и управлять ими уже не так удобно. Между IOS маршрутизаторами я настраиваю Site-to-Site с помощью туннельных интерфейсов и траффик, который нужно шифровать, выбирается по маршрутизации. Но с ASA и с криптокартами нужны эти списки, и, однажды, из-за моей ошибки в этих списках туннель падал. На аса можно ещё сделать такой финт:

object-group network ONE_SIDE

network 192.168.1.0 255.255.255.0

object-group network OTHER_SIDE

network 192.168.2.0 255.255.255.0

access-list CRYPTO extendet permit ip object-group ONE_SIDE obect-group OTHER_SIDE

Т.е. список доступа из одной строчки, а подсети - в object-group. Но на IOS это уже невозможно сделать, object-group для IPSec там неприменимы и  в конфиге полотно из нескольких десятков строк.

Туннель - самый простой Site-to-Site между двумя площадками. С одной стороный 2921 маршрутизатор, с другой ASA 5510, между ними два канала, поэтому настроен EIGRP, ну и тот IPSec c криптокартами.

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

Если вы настраиваете на ASA  object-groups, то это уменьшает размер конфига по выводу команды show  run или show run access-list, но абсолютно не уменьшает реальный размер  аксесс-листов и количество IPsec SA на ваших туннелях. 

Перед  тем, как воспользоваться аксесс-листом, ASA "раскрывает" все входящие в  него object-groups и приводит все аксесс-листы к нормализованному виду  со стандартными правилами типа permit/deny     с явно указанными IP адресами.

Если  вы наберете show access-list и show crypto ipsec sa на ASA, то вы  увидите, что истиннные аксесс-листы и туннели на вашей ASA после  раскрытия всех object-group абсолютно симметричны аксесс-листам и  туннелям на стороне IOS, и имеют точно такой же размер.  Так что, с  точки зрения траблшутинга, внедрением object-groups вы на ASA ничего не  выигрываете, и если на IOS все-таки реализовать object-groups для Crypto  ACL, то вы этим ничего не выиграете тоже.

C точки  зрения настройки и траблшутинга, желательно использовать как можно  меньше правил в Crypto ACL.  В идеале - одно выражение permit ip  на один туннель.  C IP адресами, а не с группами.

Для того, чтобы этого добиться, нужно сделать две вещи:

1. Реорганизовать IP адресацию, чтобы она позволяла сделать 1 правило типа permit на один туннель (в идеале)

2.  Никогда не использовать Crypto ACL (равно как и NAT) для контроля  доступа.  Т.е. не указывать дополнительными правилами внутри Crypto ACL  для одного туннеля, какой трафик должен ходить через туннель, а какой не  должен.  Crypto ACL должен содержать один-единственный permit, условно  говоря, на всю сеть, доступную через туннель, а контроль доступа должен  быть отделен от Crypto ACL, и реализован отдельным аксесс-листом на  подходящем внутреннем интерфейсе роутера или ASA.

Какие  еще возможны способы дополнительно облегчить себе жизнь  (нижеперечисленное имеет смысл только при очень большом количестве  туннелей; при небольшом лучше оставить классический IPsec L2L - проще будет):

1. сделать с одной стороны туннеля (на споке)  статический крипто мап, а с другой стороны (на хабе) динамический.  Это  позволит настраивать crypto ACL только с одной стороны (в два раза меньше труда), однако не  уменьшит его размера и создаст дополнительные сложности:

-  Хаб не застрахован от ошибок конфигурации Crypto ACL на споке, т.к. не  имеет своего Crypto ACL, контролирующего туннельный трафик

-  На споке нужно настраивать постоянные генераторы трафика через туннель  (скажем, IP SLA или NTP).  На каждый IPsec SA нужен один генератор со  своим приватным source IP и со своим destination IP за туннелем.  Каждый  SA поднимается только по инициативе спока, и, как следствие, спок  должен постоянно посылать трафик через каждый SA, чтобы держать его  постоянно поднятым.

2. Можно настроить на одном  устройстве (споке) EazyVPN клиент а на другом (хабе) - EazyVPN сервер.   Этот способ похож на предыдущий - туннель поднимается по инициативе  спока.  Тем не менее, данный способ реально даст эффект в виде упрощения  конфигурации только в случае уже переделанной IP адресации (т.е. за  каждым споком-клиентом - только directly connected IP сети).  Если у вас  рваные IP сети, и они не directly connected на споке, то вам по-любому придется  конфигурить аксесс-листы с обоих сторон, описывающие сети и с той и с другой стороны, а результирующий набор IPsec SA для каждого спока будет генерироваться  путем наложения этих аксесс-листов.  Т.е. в случае рваных сетей конфиг  EazyVPN может оказаться еще запутаннее и сложнее в отладке, чем в случае  простого IPsec L2L.

Краткое резюме всего сказанного - если вы упростите IP адресацию, у вас и IPsec L2L будет работать без проблем :-)

C уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Сергей,

Я начинаю понимать, в настоящий момент на маршрутизаторе на криптокарте висит список доступа, регулирующий доступ между площадками, а также есть CryptoACL, в котором указаны подсети, но в теории мне ничего не мешает сделать CryptoACL следующего вида:

permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255

верно?

Тем более, что между площадками нет другого траффика, кроме esp и EIGRP. Возможны ли здесь какие-либо подводные камни?

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

Подводный камень только один - если на одном устройстве есть несколько туннелей в одном крипто мапе на одном интерфейсе (т.е. несколько set peer в одном крипто мапе) то они должны иметь непересекающиеся уникальные Crypto ACLs.  Иными словами, любой пакет, проходящий через крипто мап, должен подпадать только под один Crypto ACL, и не подпадать под остальные Crypto ACL, и тогда он будет отправлен правильному peer-у, указанному оператором set peer

Если какой-то Crypto ACL "охватывает" трафик сразу нескольких туннелей, то весь этот трафик пойдет одному peer-у, вместо того, чтобы идти на несколько разных peer-ов.  Работать, соответственно, ничего не будет.

Если же у вас, к примеру, всего два устройства, между которыми поднят туннель, и с обоих сторон этих устройств есть многочисленные сети 192.168.x.0/24, то вполне можно сделать так, как вы написали - permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255.

С уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

Сергей,

последний вопрос, если список CryptoACL будет таким:

permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255

то как поведёт себя EIGRP, в нём же Update пакеты используют src dst адреса маршрутизаторов(они попадают в эту маску), то есть они будут заворачиваться в туннель, или я не прав?

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

Я не вижу вашей топологии, но в любом случае EIGRP пакеты не должны попадать в туннель и шифроваться.  Если вы поставите работу EIGRP в зависимость от работы IPsec туннеля, а работа IPsec туннеля в свою очередь, будет зависеть от EIGRP роутинга, то у вас в итоге может вообще ничего не работать.  Или сломаться при первом же переключении на резервный ISP.

Если EIGRP работает на внешнем интерфейсе роутера, то крипто мап не данном интерфейсе не должен шифровать пакеты с адресами этого интерфейса.  Если внешние интерфейсы роутеров, на которых запущен EIGRP, не принадлежат диапазону 192.168.0.0 0.0.255.255, то проблем у вас, собственно, не будет. 

Если же принадлежат - то нужно как-то это разрулить - или сделать другой crypto ACL, или поменять адресацию, или добавить в начало вашего crypto ACL выражение типа deny ... которое будет исключать трафик внешнего интерфейса роутера из шифрования.  Можно даже просто deny ip host x.x.x.x any + deny ip any host x.x.x.x где x.x.x.x - адрес внешнего интерфейса роутера.  На другом конце туннеля - аналогично, но уже с адресом интерфейса с той стороны. 

Выражения типа deny в Crypto ACL могут не совпадать на обоих концах туннеля, в отличие от выражений permit.  При подъеме IPsec туннеля операторы deny в Crypto ACL на пирах не согласовываются - согласовываются только операторы permit.

При этом количество IPsec SA все равно будет равняться количеству операторов permit в Crypto ACL (согласованных), просто при наличии deny в начале этого ACL часть пакетов "не дойдет" до IPsec SA, и будет отправлена во внешний мир без шифрования.  Т.е. оператор deny будет выполнять функцию "обхода" шифрования (bypass).  Оператор deny в Crypto ACL имеет чисто локальное значение и действует только на данный роутер, как локальный фильтр.  Другому роутеру он не передается.

Хотя в идеале я бы, конечно, сделал разные IP сети на внутреннем и внешнем интерфейсах роутера.  И крипто мапом на внешнем интерфейсе шифровал бы только внутренние сети.

C уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

Если использовать deny в acl будет ли иметь смысл вот такая строчка: deny eigrp any any, например?

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Игорь,

Можно и так, но я бы сделал deny host, чтобы исключить из L2L не только юникастовый EIGRP трафик, но и весь остальной собственный трафик роутера. 

А мультикастовый EIGRP трафик в IPsec L2L все равно не попадет.

С уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Спасибо, Сергей, порисовал схемы и склонился к тому, чтобы поменять адресацию на внешних интерфейсах, из другого приватного диапазона (172.16...)

New Member

Спросить эксперта: IPsec VPN на платфор

Добрый день, Сергей!

В нашем небольшом офисе установлена ciscoasa5505 Version 9.0(1). В  качестве одной из функция, я использую ее, как VPN для remoute access  users. Например сотруднику из дому подключиться к 1С и т.п.

В  group-policy для сотрудников в split-tunnel назначается только адрес  сервака, в атрибутах users вешаются ACL для фильтрации по портам, и  конечно же исключения NAT (точнее NAT Rule Before "Network Object").  Ничего особенного, все работает, все довольны!

Для себя, админа, я создал отдельный group-policy, со  split-tunnel'ем всей сети (192.168.0.0/24) и в атрибутах своего  пользователя назначил ACL permit ip. В итоге, у меня тоже все хорошо,  вся сеть видна, все работает. Но!

Я не могу подключиться к АСе по ip внутреннего  интерфейса (192.168.0.1). Выхожу из ситуации с помощью RDP на сервак, а  от туда уже на АСу.

Команда типа "ssh x.x.x.x y.y.y.y outside", даже если в ней  указны ip моего remout access клиента, меня немного смущают тем, что АСА  начнет прослушивать 22 порт на внешнем интерфейсе в целом. Да и  все-равно такая команда не помогает =)

Других дел много, самому сесть, обложиться гайдами и разобраться с такой мелочью пока не так много времени свободного... Быть может дело в какой-то мелочи? Подскажите, пожалуйста, где копать.

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Петр,

Вообще-то такая задача обычно решается командой "management-access inside", где "inside" - это имя внутреннего интерфейса. 

Она позволит обратиться к интерфейсу inside из внешней сети (т.е. из outside), но с одним ограничением - работать такое обращение будет только через туннель (IPsec или SSL VPN).  Попробуйте это сконфигурить.

С уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

Сергей, увы, не помогло... Являюсь ipsec клиентом.

Стоит упомянуть, что при этом inside-интерфейс даже не пингуется (в атрибутах пользователя, в ACL icmp permit).

А что делать с командой "ssh 192.168.5.1 255.255.255.255" inside (или outside)? Собственно оба варианта по прежнему не помогают...

192.168.5.1 - ip моего удаленного клиента.

Сообщение отредактировал: Petr Zuzanov

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Петр,

Для траблшутинга нужен ваш конфиг, топология, и выводы, из которых видно ACL, примененные к пользователю и к туннелю:

Cобрать с ASA в момент подключения:

  show version

  show run

  show vpn-sessiondb ra-ikev1-ipsec

  show uauth

  show route

C клиента:

  ipconfig /all

  route print

  точный username, под которым логинится пользователь

Если вы не хотите публиковать здесь полные конфиги, то лучше открыть кейс в TAC.

С уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Было сел в конфиге "замазывать" ip'шники, логины и пароли, но на последок решил немного потраблешутить сам... В итоге нашел https://supportforums.cisco.com/thread/2120561

И в общем то помогло! Абсолютно схожая ситуация, разве что вместо site-to-site у меня remote access.

Спасибо за внимание и за то, что разъяснили назначение команды "management-access inside"!)

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Петр,

Да, такая проблема у нас действительно есть - начиная с ASA 8.4.2 изменилось поведение NAT.  Команда "management-access-inside" может не работать при наличии правила NAT, выполняющего identity NAT для трафика, идущего от VPN клиента на внутренний интерфейс ASA, если в этом правиле нет ключевого слова "route-lookup".

Документировано это в Release notes для бага:

CSCtr16184    To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2

Это не работает:

! Overlapping NAT statement:

nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn

Это работает:

! New Statement:

nat (inside,outside) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-vpn obj-vpn route-lookup

Причина неработоспособности первого варианта в том, что первая команда выполняет для входящего трафика функцию NAT divert (маршрутизация трафика на интерфейс, указанный в команде NAT, т.е. на inside).  Этот механизм более приоритетен, чем таблица маршрутизации.  Начиная с 8.4.2 механизм NAT divert выбрасывает трафик, идущий на собственный IP адрес интерфейса inside, в локальную сеть, присоединенную к интерфейсу inside, вместо того, чтобы отдавать этот трафик самому интерфейсу.  В локальной сети получателей такого трафика нет, и в итоге пакеты дропаются.

Указание ключа route-lookup по сути отключает NAT divert для данного правила NAT, и заставляет ASA принять во внимание таблицу маршрутизации.  При этом пакеты, адресованные интерфейсу inside, отдаются самому интерфейсу, а не выбрасываются в сегмент сети inside.

Важно: в рамках бага CSCtr16184 данная проблема не исправлена, а документирована.  Т.е. это новое поведение NAT, начиная с версии ASA 8.4.2 и возвращать его к предыдущему варианту не планируется.  Для решения проблемы нужно добавлять "route-lookup" к соответствующему правилу NAT, если такое правило есть.

Единственное, что реально исправлено в данном баге - это миграция конфига при апгрейде ASA с предыдущих версий до ASA 8.4.2 и выше - теперь ключ "route-lookup" при апгрейдах вставляется автоматически.

С уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Добрый день!
Перестраиваем несколько неудачный дизайн. ASA работает IPSEC-концентратором site-to-site
Есть необходимость перенести внешний адрес, на который коннектятся клиенты, на внутренний интерфейс.
Т.е. грубо говоря есть сети (доступные в интернете)
Х.Х.Х.40/30 - g1 интерфейс, внешняя сеть, 42й адрес на АСА, на него коннектятся клиенты ipsecом

Х.Х.Х.44/30 - g2 интерфейс, внутренняя сеть, 46й адрес на сервисном оборудовании, его также надо сохранить, так как его также используют клиенты

Возможно ли совместить эти сети в сеть Х.Х.Х.40/29, перенести внутрь, на g2 чтобы
1) на 42й адрес можно было коннектится IPSECом
2) после получения внутренней сети клиенты могли работать с адресом 46 через IPSEC соединение? Я так понимаю, именно этот вопрос может быть проблемой
Спасибо



Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Константин,

См. ответ на предыдущий вопрос выше.  Коротко говоря - нельзя. 

Архитектура IP стека на ASA такова, что обратиться на ASA можно только по IP адресу ближайшего к клиенту интерфейса.  Т.е. IPsec из внешней сети можно терминировать только на внешнем интерфейсе и нельзя терминировать на внутреннем.   И наоборот: IPsec из внутренней сети можно терминировать на внутреннем интерфейсе и нельзя - на внешнем.

Единственное исключение из данного правила - команда management-access inside, описанная выше.  но она имеет существенное ограничение - она позволяет добраться из сети outside то интерфейса inside только через уже установленный туннель (любой - IPsec или SSL VPN).

Иными словами, IPsec из внешней сети вы можете терминировать только на внешнем интерфейсе, но после того, как вы установите IPsec, вы можете обратиться и на внутренний интерфейс тоже (при наличии команды management-access inside).  Но уже не IPsec-ом, а теми протоколами, которыми вы обращаетесь на саму ASA - т.е. management protocols: SSH, Telnet, Ping, и т.д.

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

С уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Мне нужно сделать redundancy как АСА, так и сервисного устройства.

При этом сохранив адреса 42 и 46

Это можно сделать сетью /29 внутри - 41,42 на АСА (для backup адреса и для рабочего) и 44,45,46 для VRRP для сервисного устрйства.

Но раз дело обстоит так, как вы говорите, то мне вопрос меняется
Как я могу сделать redundancy на АСА, если мне нужно сохранить сеть /30 на внешнем интерфейсе для IPSEC?
Проблему с 46 адресом я могу теоретически решить другими методами
А вот стандартный redundancy для АСА, если мне нужно сохранить /30 для пира, я не представляю

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Константин,

Вопрос про сервисное устройство мне, к сожалению, непонятен - нужна топология.

По поводу ASA - есть один способ сделать failover с сетью /30 на интерфейсе, но мы его обычно не рекомендуем - он ухудшает функциональность failover. 

В failover-ной конфигурации можно настроить на интерфейсе только основной IP адрес и не настраивать standby IP адрес.  Таким образом вы истратите для интерфейса ASA только один IP адрес из сети /30, а второй останется для вашего пира.  

interface Vlan3

   nameif dmz

   security-level 50

   ip address 2.2.2.2 255.255.255.252

При этом, мониторинг данного интерфейса средствами failover работать не будет, так как одной из составных частей процесса мониторинга является обмен пакетами failover poll между двумя ASA через все интерфейсы, на которых мониторинг включен.  Пакеты failover poll являются юникастовыми, и при мониторинге интерфейса они пересылаются между одноименными интерфейсами двух ASA в кластере: с основного IP адреса интерфейса на standby IP адрес того же интерфейса, и обратно.  Если Standby IP адрес для интерфейса не сконфигурен, тестирование интерфейса на standby ASA путем передачи failover polls между двумя ASA невозможно. 

По умолчанию мониторинг включен на всех физических интерфейсах и выключен на всех субинтерфейсах

Для интерфейса без standby IP адреса нужно выключить мониторинг принудительно:

no monitoring-interface dmz

Результат вывода команды "show failover" после этого должен выглядеть вот так - standby IP для данного интерфейса должен быть 0.0.0.0 и статус мониторинга - Not-Monitored.  Основной IP должен быть на своем месте.

BSNS-ASA5505-16(config)# show failover

...

        This host: Secondary - Active

                  ...

                  Interface dmz (2.2.2.2): Waiting (Not-Monitored)

        Other host: Primary - Standby

                  ...

                  Interface dmz (0.0.0.0): Unknown (Not-Monitored)

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

Обращаю внимание, что при отключении мониторинга на интерфейсе, отказы данного интерфейса не будут приводить к переключению ролей в failover.  Поэтому такая конфигурация не рекомендуется.

С уважением,

Сергей.

New Member

Спросить эксперта: IPsec VPN на платфор

Спасибо!


Про сервисный девайс не беспокойтесь, вопрос только по АСА
Правильно я понимаю, если я сделаю внешний интерфейс по тому варианту, что вы предложили, у меня не будет мониторится этот линк, при этом если я сделаю все остальные линки с мониторингом, в том числе линк для поддержания stateful то я рискую не переключится только в случае падения этого линка, на котором я монтиторинг отключил?
Есть ли на АСА другие способы обеспечить мониторинг этого отдельного линка?
по IP доступности пира, скажем?
Может быть некий аналог "event manager" на IOS?

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Константин,

Konstantin Goncharenko написал(а):

Спасибо!


Про сервисный девайс не беспокойтесь, вопрос только по АСА
Правильно я понимаю, если я сделаю внешний интерфейс по тому варианту, что вы предложили, у меня не будет мониторится этот линк, при этом если я сделаю все остальные линки с мониторингом, в том числе линк для поддержания stateful то я рискую не переключится только в случае падения этого линка, на котором я монтиторинг отключил?

Да, правильно.  C одним замечанием: помимо выхода из строя интерфейса, который не мониторится, есть и другие документированные сценарии, в которых что-то разрывается, а failover не происходит.  Например, при разрыве failover link или stateful failover link, но сохранении связи между ASA через остальные интерфейсы посредством failover polls, обе ASA "заморозят" свое последнее состояние и не будут переключать роли Active/Standby.  А вот после потери связи абсолютно через все интерфейсы - обе ASA станут Active. 


Рекомендую посмотреть таблицу Failover Actions в документации на ASA:

http://www.cisco.com/en/US/partner/docs/security/asa/asa84/configuration/guide/ha_active_standby.html#wp1079555


Есть ли на АСА другие способы обеспечить мониторинг этого отдельного линка?
по IP доступности пира, скажем?
Может быть некий аналог "event manager" на IOS?

К сожалению, нету.   IP SLA и трекеры на ASA настроить можно, но нельзя прикрутить их к failover.

Кроме того, доступность линка, на котором нету IP адреса (т.е. интерфейса на Standby ASA, на котором нет standby IP адреса) все равно полноценно протестировать нельзя.  Т.е. даже если вы знаете, что у вас отказал линк на Active ASA, вы не знаете статуса того же линка на Standby ASA.  И возникает вопрос - переключаться все-таки при отказе, или нет ?...

С уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

Подскажите пожалуйста еще, Сегрей.

Я могу принимать один и тот же айписек на два внешних интерфейса?
Чтобы постепенно перевести клиентов с одного адреса (который без резервирования) на другой (с резервированием)?
Так, чтобы у клиентов ничего, кроме ip-адреса  для коннекта, не менялось?

Спасибо

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Константин,

С точки зрения IPsec - да, можно.  И на IOS и на ASA.  Единственное но - на оборудовании Cisco не рекомендуется привязывать один и тот же крипто мап к двум интерфейсам.  Сделайте два одинаковых крипто мапа с полностью одинаковыми параметрами, включая Crypto ACL, и привяжите их к разным интерфейсам.

Тем не менее, проблема у вас все равно возникнет, но не с IPsec, а с таблицей маршрутизации. 

Default route на вашем устройстве всего один.  Вопрос - что будет если default route маршрутизирует весь трафик в Интернет через интерфейс Gig0/1, а часть IPsec клиентов коннектится к Gig0/2 ?  Ответ - в большинстве случаев Gig0/2 не будет работать.

Для того, чтобы решить проблему с роутингом, нужно знать точный сценарий:  тип устройства, терминирующего IPsec, тип IPsec туннеля, какие в точности IPsec клиенты у вас коннектятся на данное устройство, и тип конфига IPsec. 

Для каждого сценария будет свой ответ на вопрос про роутинг. 

В зависимости от конкретного сценария IPsec, решить проблему с роутингом через два внешних интерфейса может оказаться либо легко, либо сложно, либо невозможно :-)

С уважением,

Сергей.

New Member

Re: Спросить эксперта: IPsec VPN на платф

>Default route на вашем устройстве всего один.  Вопрос - что будет если default route маршрутизирует весь трафик в >Интернет через интерфейс Gig0/1, а часть IPsec клиентов коннектится к Gig0/2 ?  Ответ - в большинстве случаев >Gig0/2 не будет работать.
Допустим, я могу добавить для каждого клиента статику, чтобы выпускать его обратно именно через g0/2
Это сработает?
Спасибо!

Re: Спросить эксперта: IPsec VPN на платф

Здравствуйте, Константин,

Для ответа на ваш вопрос мне как раз и нужно понимать ваш сценарий - я выше об этом написал.  Вы говорите о той ASA, о которой спрашивали раньше, или о каком-то другом устройстве ?

В зависимости от VPN сервера (ASA или IOS) и от топологии, ответ будет отличаться.

Если, к примеру, у вас Remote Access клиенты (Cisco VPN Client) то прописывать статические маршруты для RA клиентов бессмысленно: и у RA клиентов интерфейса Gig0/1, и у RA клиентов интерфейса Gig0/2 - произвольные динамические IP адреса, которые заранее неизвестны. 

Если у вас статические клиенты - L2L, GRE/IPsec, VTI, то ответ положительный:  да, по мере перевода клиентов на Gig 0/2 вы можете добавлять на VPN сервер статические маршруты /32 на публичные адреса пиров, доступных через интерфейс Gig0/2.  Единственное но - на приватные сети, доступные через туннели на Gig0/2, на ASA тоже должны откуда-то появиться статические маршруты, и тоже через Gig0/2.  Проще всего их тоже вручную добавить командой ip route.  Как альтернативу статическим маршрутам на приватные сети, можно использовать RRI (команда reverse-route в крипто мапе), но тут возникают нюансы - на IOS это будет работать адекватно, создавая и удаляя маршруты при подключении клиента, а на ASA - не совсем.  На ASA на сегодняшний день автоматическое создание/удаление маршрутов средствами RRI работает только в динамическом крипто мапе (документировано в CSCsx67450 ).  В случае же статического крипто мапа, маршрут RRI создается в момент создания крипто мапа, а не в момент подключения клиента.  Поэтому статический крипто мап на ASA не сможет автоматически отследить подключение IPsec клиента то на один, то на другой интерфейс - маршруты на приватные сети переключаться не будут.  А динамический крипто мап только принимает соединения и не может их инициировать.  Иными словами, чтобы на стороне ASA работал RRI, на ASA делается динамический крипто мап, а у каждого статического клиента со статическим крипто мапом должен быть свой генератор трафика, поднимающий туннель.  На клиентах IOS можно в качестве генераторов трафика использовать трекеры IP SLA с явным указанием желаемых src IP и dst IP для подъема конкретного IPsec SA простыми пингами, а вот на клиентах ASA это уже проблема - там нельзя указать Source IP для IP SLA.  В общем, если вариант с генераторами невыполним - то только статические маршруты, причем несколько штук на каждого клиента.

Если у вас DMVPN, то проблема похожа на первую (с Remote Access), т.к. адреса споков динамические, но имеет документированное решение - можно создать на хабе два туннельных интерфейса с разными tunnel source , привязать трафик этих туннелей к разным ISP командами tunnel route-via , и и создать два default route с одинаковыми метриками через разных ISP.  Дальше споки смогут коннектиться на любой из этих туннельных интерфейсов.  Команда tunnel route-via заставит туннельный интерфейс воспользоваться только одним из двух default route, присутствующих в таблице маршрутизации, и передавать весь трафик туннеля через него.  Правда, придется после этого преодолеть все побочные эффекты, которые возникнут от создания двух default route на одном маршрутизаторе (в частности привязать не-туннельный трафик, идущий в Интернет через NAT, к какому-нибудь одному внешнему интерфейсу при помощи простого PBR, а  собственный трафик роутера, скажем, Telnet/SSH, тоже привязать к какому-нибудь одному внешнему интерфейсу, но уже при помощи Local PBR ).

В любом сценарии с двумя ISP я рекомендую открывать кейс в TAC, т.к. нужно обсуждать очень много деталей.

С уважением,

Сергей.

10186
Просмотры
123
Полезный материал
48
Ответы