Замена удаленного узла из ASA на маршрутизатор IOS
-
Мне нужно заменить старый маршрутизатор ASA 5520 на маршрутизатор IOS XE. Оба конца некоторое время назад были на ASA, и некоторое время назад я успешно заменил один конец на 4451-X. Это сработало без проблем — просто сопоставьте ACL и криптографические параметры, и все будет работать. Мы используем предварительно разделенные ключи. Простая конфигурация с криптографическими картами и ACL. Когда я пытаюсь заменить другой конец, я сталкиваюсь с проблемой, что уже настроенный 4451, похоже, не хочет забывать ASA-пир. Я выполнил следующие шаги. На старом ASA очистил криптографические данные, затем отключил IKEV1 и IKEV2:
clear crypto ikev1 sa
clear crypto ikev2 sa
clear crypto ipsec sa no crypto ikev1 enable outside
no crypto ikev2 enable outside Подождите 10 минут.
Это должно привести к обнаружению неактивного пира и очистке состояний IKE. Затем я отсоединил ASA и подключил маршрутизатор 4451.
И включил интерфейс на 4451 Затем я пытаюсь запустить туннель, отправляя пинг на некоторый интересный
трафик.
Но он не запускается SA отображается как «QM_IDLE», что в основном означает, что на самом деле ничего не происходит
, но я не могу получить трафик. show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
<localip> <remoteip> QM_IDLE 18833 ACTIVE Поэтому я перезагружаю новый маршрутизатор 4451, и он выдает следующее сообщение: 27 января 03:24:43.032: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: полученный пакет IPSEC имеет недействительный spi для destaddr=<<localip>>, prot=50, spi=0x5ADA2CC2(1524247746), srcaddr=<<remoteip>>, входной интерфейс=Vlan527
января 03:24:51.528: %CRYPTO-4-IKMP_NO_SA: сообщение IKE от <<remoteip>> не имеет SA и не является предложением инициализации И далее показать ошибку диагностики криптографического протокола ISAKMP Таблица путей выхода — статус: включено, текущая запись 4, удалено 0, максимально допустимо 50 Ошибка (2): сбой удаления DH.
[conn id 1001, local <<localip>>:500 remote <<remoteip>>:500] -Traceback= 1#67108551e83a17deda268a8d065e2c84 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2E4A93 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2BF5AE iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2C9D30 Ошибка (2): сбой удаления DH.
[conn id 1001, local <<localip>>:500 remote <<remoteip>>:500] -Traceback= 1#67108551e83a17deda268a8d065e2c84 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2E4A93 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2BF551 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2C9D30 Ошибка (1): не найдено SA для обработки.
удаленный <<remoteip>> -Traceback= 1#67108551e83a17deda268a8d065e2c84 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2E4A93 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2D64D4 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2CA98C Ошибка (1): Не удалось отправить удаление, сосед не аутентифицирован.
[conn id 0, local <<localip>>:500 remote <<remoteip>>:500]
state mask 0x1 -Traceback= 1#67108551e83a17deda268a8d065e2c84 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2E4A93 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2D1772 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+3420D0 iosd_shr_m_uk9_IPSEC_Core_crb:7F983FDA9000+2C981C Все это, похоже, указывает на то, что удаленный 4451 еще не забыл
ASA как партнера и считает, что он по-прежнему связан с ним или должен быть связан. Затем я решил вернуться назад и сделать все в обратном порядке, вернув старый ASA.
И этот туннель появился СРАЗУ. Я повторил все снова, подождав гораздо дольше, но ничего не изменилось. Параметры
срока действия установлены на 86400 как на SA, так и на криптокарте, но
это не должно влиять на снос SA, когда это необходимо. Есть ли способ ускорить этот процесс?
Поможет ли перезагрузка или отключение одного из маршрутизаторов? Однако с практической
точки зрения это не очень осуществимо. Что же мне нужно сделать, чтобы удаленный маршрутизатор 4451 окончательно
и быстро забыл старый SA? -
Привет, @pschulz
Прежде всего, вам явно нужен более стабильный код, поэтому я бы также выполнил эту операцию в рамках процесса. Если вы все равно хотите перейти на IKEv2 и SVTI / маршрутизацию на основе VPN, почему бы не сделать это сейчас? Вы не потеряете доступ. Вы полностью настраиваете удаленный конец для IKEv2 SVTI и маршрутизации (туннель не будет создан, так как локальная сторона еще не настроена), после чего вы настраиваете локальную сторону, создается новый туннель на основе IKEv2, вы проверяете его работоспособность и удаляете старую конфигурацию IKEv1. Настройка удаленного конца ни в коем случае не должна привести к потере доступа к устройству; для безопасности, когда вы вставляете новую конфигурацию, работайте с
перезагрузкой
, если после вставки конфигурации вы не потеряли доступ, отмените запланированную перезагрузку. Не используйте маршрутизацию IKEv2, с самого начала используйте динамическую маршрутизацию; кроме того, используйте SVTI на обеих сторонах. Вы можете использовать следующие документы в качестве руководства. Если у вас возникнут затруднения, опубликуйте конфигурацию, которую вы хотите применить, чтобы мы могли ее проверить: https://www.cisco.com/c/en/us/support/docs/security-vpn/internet-security-association-key-management-protocol-isakmp/223291-implementing-ikev2-route-based-site-to.html https://www.cisco.com/c/en/us/support/docs/routers/enterprise-nfv-infrastructure-software/221678-configure-secure-overlay-with-bgp-route.html https://www.cisco.com/c/en/us/support/docs/security/flexvpn/116346-configure-eigrp-00.html Спасибо, Кристиан. -
Как насчет присвоить новые IP-адреса и настроить новую пару ISAKMP-узлов?
-
@kiwibird
Использование новых IP-адресов на обоих концах и настройка новой пары ISAKMP — безусловно, хорошая идея. Однако тогда у меня возникнет проблема: я не смогу настроить 2 SA с одинаковым интересным трафиком — у меня нет отдельного внеполосного соединения для управления, и мне придется настраивать удаленный узел через это SA. Я не вижу, как обойти это препятствие — было бы лучше, если бы я мог просто запустить его, выполнив вышеуказанные шаги. -
Насколько я помню, вы упомянули, что у вас есть 2 пары IPsec. Находятся ли эти удаленные устройства в одном месте? Давайте предположим, что VPN удаленного устройства A работает, а удаленного устройства B — нет. Можете ли вы просто подключиться к устройству A, а затем перейти с него на устройство B?
-
Здравствуйте
[, @pschulz] Измените IP-адрес, что приведет к полному перезапуску переговоров и позволит избежать всех устаревших состояний SPI/IKE на удаленном 4451... без необходимости очистки или перезагрузки... С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı. -
-
Здравствуйте, @pschulz
Предоставленных данных недостаточно, чтобы убедиться, что конфигурация подходит для обеих сторон. Сообщение
Error(1): Failed to send delete, peer isn't authenticated
(Ошибка (1): не
удалось отправить
удаление, сосед не аутентифицирован) может потенциально указывать на проблему с конфигурацией. Можете ли вы поделиться очищенной конфигурацией обеих сторон? Однако более серьезной и, скорее всего, вашей проблемой, судя по трассировкам, является уровень шифрования контрольной плоскости, который никогда не следует игнорировать, даже если туннель заработает и будет временно функционировать, он может выйти из строя в любой момент, если вам повезет, без сбоя, а если нет, то со сбоем... Похоже, вы столкнулись с одной из этих ошибок или чем-то подобным, поэтому я настоятельно рекомендую в первую очередь обновить обе стороны до стабильной/золотой версии, например 17.9.8 или 17.12.6, а затем повторить попытку. https://bst.cisco.com/bugsearch/bug/CSCvv36247?rfs=qvlogin https://bst.cisco.com/bugsearch/bug/CSCvw38740?rfs=qvlogin Кроме того, я настоятельно рекомендую отказаться от IKEv1, так как со временем вы будете сталкиваться со все большим количеством проблем. Перейдите на IKEv2 и, почему бы и нет, на маршрутизированный IPsec-туннель, а не на IPsec на основе политик (вы ничего не потеряете, а наоборот, получите простоту и гибкость для возможных будущих сценариев высокой доступности и/или быстрого переключения при сбоях). Спасибо, Кристиан. -
@Cristian Matei
Конечно, мы хотим отказаться от IKEv1, но сначала давайте отключим старое устройство, по крайней мере, так я думаю. Если только я сначала не настрою IKEv2, и оно заработает? Я могу попробовать. И использовать VTI, да, это тоже нужно сделать. Если я создам отдельный канал с новыми IP-адресами и буду использовать VTI на новом, то интересный трафик будет обрабатываться маршрутами, которые, вероятно, будут иметь приоритет над ACL в моем старом маршруте. Как я упомянул в ответе kiwibird, я должен управлять удаленным устройством через этот VPN, поэтому у меня нет возможности легко настроить оба одновременно. -
@Cristian Matei
Спасибо за советы. Поскольку я не очень хорошо знаком с VTI, я делаю это в два этапа — настраиваю VTI на обоих концах, но для интересного трафика, не связанного с производственным трафиком. Это работает нормально, после чего я могу просто отключить свой локальный конец, перенастроить удаленный конец на производственный трафик, а затем свой локальный конец, как вы и сказали. -
Привет, @pschulz
Удачи, если возникнут проблемы, вернитесь, желательно с новой темой. Спасибо, Кристиан.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти