IPSec DVTI <> Криптографическая карта

[Soma-II]

Прежде всего, в настоящее время мы тестируем различные сценарии IPsec. Это конкретное устройство (ROUTER_SPOKE_CRYPTO) оказывается особенно сложным, когда речь заходит об установлении соединения IPsec. Этот сценарий не предполагает использования VRF. У меня есть ROUTER_HUB, который успешно установил туннель с другим маршрутизатором-спицей с помощью SVTI. Сейчас я пытаюсь настроить второй туннель, но на этот раз с помощью Crypto Map (я знаю, что это немного устарело, но я должен его использовать). Я столкнулся с проблемой, которая кажется простой, но я не могу понять, почему она не работает.
![:disappointed_face:] Для справки: на этом устройстве работают другие VTI (ROUTER_SPOKE_CRYPTO), но ни один из них не использует Crypto Map. Вот некоторые подробности:

• Фаза 1
  установлена
• Фаза 2: SA не
  устанавливаются - Ping работает, если мы не используем loopback в качестве источника — в этом случае тест ping завершается с ошибкой (более подробная информация находится в файле) Похоже, это проблема ACL, но я пробовал несколько разных конфигураций без успеха. Я также пробовал альтернативный метод применения криптографической карты, изменив некоторые команды, но все равно безрезультатно. Буду очень благодарен за любую помощь — я честно говоря застрял. У меня такое ощущение, что это что-то очевидное, чего я просто не вижу.

[Rob Ingram]

@Soma-II
, во-первых, вам не нужно зеркалировать крипто-ACL, вам нужен только один ACE — от вашего локального IP-адреса источника до адреса назначения. Вывод команды «show crypto ipsec sa» подразумевает, что трафик, соответствующий вашему крипто-ACL, является интерфейсом виртуального доступа, а не крипто-картой — что вполне соответствует моим ожиданиям. interface: Virtual-Access1
Crypto map tag: Virtual-Access1
-head-0, local addr 172.21.55.70
protected vrf: (none)
local ident (addr/mask/prot/port): (55.55.55.3/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (55.55.55.1/255.255.255.255/0/0)
current_peer 172.22.55.70 port 500 В конфигурации концентратора нет конфигурации криптографической карты. Вы пытаетесь использовать криптографическую карту на спице и dVTI на другом (концентраторе)? Вам нужно использовать криптографическую карту в Амстердаме с криптографическим ACL, который зеркалирует спицу.

[Rob Ingram]

@Soma-II
, чтобы было ясно: вы можете установить туннель только в том случае, если оба узла поддерживают одну и ту же версию IKE. Однако маршрутизатор можно настроить так, чтобы он поддерживал одновременно IKEv1 и IKEv2 и устанавливал туннель с использованием IKEv1 для одного узла и IKEv2 для другого. Я бы рекомендовал перенести все туннели на IKEv2, так как он поддерживает более надежные алгоритмы шифрования по сравнению с IKEv1 и, возможно, менее сложен.

[Soma-II]

Спасибо, Роб, за ответ. Что касается ACL, да, я знаю, что это не обязательно, но я не имел представления, в чем заключалась проблема с пингом, поэтому продолжал снова и снова изменять ACL. Тогда я оставлю только одну строку. Так ты говоришь, что использование Crypto Map spoke с DVTI hub несовместимо? Я думал, что hub может принимать запросы от любого spoke, независимо от их конфигурации. Если это не так, то как хаб вообще принимает конфигурацию ISAKMP от spoke crypto map? Большое спасибо за вашу помощь.

[Rob Ingram]

@Soma-II
, такая конфигурация не поддерживается. При использовании VPN на основе политик (криптографических карт) используйте криптографические карты на обоих маршрутизаторах. При использовании VPN на основе маршрутизации используйте VTI на обоих пирах или VTI на спицах и dVTI на концентраторе, либо используйте туннель с несколькими SA. Туннель Multi SA использует крипто-ACL с интерфейсом туннеля
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/214728-configure-multi-sa-virtual-tunnel-interf.html
. Таким образом, у вас может быть один маршрутизатор с криптографической картой, а другой — с интерфейсом туннеля Multi-SA (не dVTI). В вашем сценарии концентратор сопоставляет любую идентификацию, поэтому запрос на подключение от маршрутизатора, использующего криптографическую карту, вероятно, соответствует этому профилю isakmp, и именно поэтому он, по-видимому, создает виртуальный интерфейс доступа, используя VT 555 в качестве шаблона, и терпит неудачу. crypto isakmp profile Isakmp-Profile-ROUTER_HUB
keyring IPSec_key-ring_ROUTER_HUB
match identity address 0.0.0.0 0.0.0.0
virtual-template 555 Чтобы запрос на подключение из криптографической карты не соответствовал вышеуказанному профилю isakmp, вы можете явно отправить идентификатор из спиц, такой как электронная почта, fqdn, keyid, и быть более конкретным в сопоставлении идентификатора, а не сопоставлять 0.0.0.0/0.0.0.0 (любой). Таким образом, трафик криптографической карты не будет соответствовать профилю isakmp и создавать VA.
Вот пример
использования идентификаторов для IKEV2, тот же принцип должен применяться для IKEv1.

[Soma-II]

Здравствуйте, Роб, Твой ответ очень мне помог, спасибо за него. Просто для уточнения: должен ли я использовать IKEv2 как на хабе, так и на спицах, чтобы поддерживать этот более широкий сценарий? Для нас очень важно построить хаб, который может принимать любое потенциальное соединение. Еще раз спасибо за помощь.

[Soma-II]

Хорошо, Роб, большое спасибо за помощь.
Похоже, мне предстоит немало работы и много нового нужно узнать! Еще раз спасибо за то, что поделился своими знаниями.

[Soma-II]

Привет, Роб! Прежде всего, извини, что снова пишу здесь, хотя этот пост помечен как решенный, но... я нашел проблему! Криптографическая карта может использоваться при подключении к концентратору DVTI! Раньше я не мог этого сделать, потому что была проблема со списочным маршрутизатором, оказалось, что он был просто слишком старым, чтобы завершить фазу 2. Я перенес конфигурацию на другой списочный маршрутизатор, и она сразу заработала. Не пойми меня неправильно, я очень благодарен тебе за помощь. Поэтому я и хотел поделиться с тобой этой хорошей новостью.
Прилагаю результаты нескольких тестов. Спасибо!