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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:15 GMT

Soma-II — Mon, 02 Mar 2026 12:44:15 GMT

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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:14 GMT

Soma-II — Mon, 02 Mar 2026 12:44:14 GMT

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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:13 GMT

Soma-II — Mon, 02 Mar 2026 12:44:13 GMT

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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:12 GMT

Rob Ingram — Mon, 02 Mar 2026 12:44:12 GMT

@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.

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:11 GMT

Soma-II — Mon, 02 Mar 2026 12:44:11 GMT

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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:10 GMT

Rob Ingram — Mon, 02 Mar 2026 12:44:10 GMT

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

Reply to IPSec DVTI <> Криптографическая карта on Mon, 02 Mar 2026 12:44:09 GMT

Rob Ingram — Mon, 02 Mar 2026 12:44:09 GMT

@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, который зеркалирует спицу.