Этот документ содержит описание типичных команд debug, которые используются для поиска и устранения неполадок IPsec в программном обеспечении Cisco IOS? И на устройствах PIX/ASA. В этом документе предполагается, что настройка IPsec выполнена. Дополнительная информация представлена в документах "Типичные сообщения об ошибках IPsec" и "Типичные проблемы IPsec".
Обратитесь к документу Наиболее распространенные решения для устранения неполадок сетей IPsec VPN L2L и сетей удаленного доступа для получения информации о наиболее распространенных решениях проблем с IPSec VPN. Этот документ содержит контрольный список общих процедур, которые можно выполнить перед началом поиска и устранения неполадок соединения и перед обращением в службу технической поддержки Cisco.
Для этого документа отсутствуют особые требования.
Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ CISCO IOS
Набор функций IPsec.
56i — указывает на функцию стандарта одинарного шифрования данных (DES) (в программном обеспечении Cisco IOS версии 11.2 и более поздних версий).
k2 — на На Указывает на функцию стандарта тройного шифрования DES (в программном обеспечении Cisco IOS версии 12.0 и более поздних версий). Стандарт тройного шифрования DES поддерживается в Cisco серии 2600 и более новый версиях.
PIX — версия 5.0 и более поздние версии, где для активации требуется лицензионный ключ для стандарта одинарного или тройного шифрования DES.
Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
Темы, содержащиеся в этом разделе, описывают команды отладки программного обеспечения Cisco IOS. Дополнительная информация представлена в документах "Типичные сообщения об ошибках IPsec" и "Типичные проблемы IPsec".
Эта команда показывает сопоставления безопасности (SA) протокола управления ключами и сопоставлениями безопасности в Интернете (ISAKMP), созданные между одноранговыми узлами.
dst src state conn-id slot 12.1.1.2 12.1.1.1 QM_IDLE 1 0
Эта команда отображает ассоциации безопасности IPSec, установленные между одноранговыми сторонами. Между узлами 12.1.1.1 и 12.1.1.2 создается зашифрованный туннель, обеспечивающий передачу трафика между сетями 20.1.1.0 и 10.1.1.0. Можно видеть, что входящий и исходящий потоки формируют две ассоциации безопасности (SA) протокола инкапсулирующей защиты содержимого (ESP). Заголовок проверки подлинности (AH) не используется, т. к. для него отсутствуют SA.
В этих выходных данных показан пример выполнения команды show crypto ipsec sa.
interface: FastEthernet0 Crypto map tag: test, local addr. 12.1.1.1 local ident (addr/mask/prot/port): (20.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) current_peer: 12.1.1.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 7767918, #pkts encrypt: 7767918, #pkts digest 7767918 #pkts decaps: 7760382, #pkts decrypt: 7760382, #pkts verify 7760382 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0, #send errors 1, #recv errors 0 local crypto endpt.: 12.1.1.1, remote crypto endpt.: 12.1.1.2 path mtu 1500, media mtu 1500 current outbound spi: 3D3 inbound esp sas: spi: 0x136A010F(325714191) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3442, flow_id: 1443, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: inbound pcp sas: outbound esp sas: spi: 0x3D3(979) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 3443, flow_id: 1444, crypto map: test sa timing: remaining key lifetime (k/sec): (4608000/52) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:
Данная команда показывает каждый Phase 2 SA и объем отправленного трафика. Начиная с этапа 2 (сопоставления безопасности), SA являются однонаправлены, каждое сопоставление SA показывает трафик только в одном направлении (шифрование для исходящего трафика, расшифровка для входящего).
В этих выходных данных показан пример выполнения команды debug crypto isakmp.
processing SA payload. message ID = 0 Checking ISAKMP transform against priority 1 policy encryption DES-CBC hash SHA default group 2 auth pre-share life type in seconds life duration (basic) of 240 atts are acceptable. Next payload is 0 processing KE payload. message ID = 0 processing NONCE payload. message ID = 0 processing ID payload. message ID = 0 SKEYID state generated processing HASH payload. message ID = 0 SA has been authenticated processing SA payload. message ID = 800032287
Эта команда показывает источник и назначение оконечных устройств туннеля IPSec. Src_proxy и dest_proxy являются клиентскими подсетями. Два сообщения "sa created" появляются в каждой подсети для каждого направления. (При выполнении ESP и AH появляются четыре сообщения).
В этих выходных данных показан пример выполнения команды debug crypto ipsec.
Checking IPSec proposal 1transform 1, ESP_DES attributes in transform: encaps is 1 SA life type in seconds SA life duration (basic) of 3600 SA life type in kilobytes SA life duration (VPI) of 0x0 0x46 0x50 0x0 HMAC algorithm is SHA atts are acceptable. Invalid attribute combinations between peers will show up as "atts not acceptable". IPSEC(validate_proposal_request): proposal part #2, (key eng. msg.) dest= 12.1.1.2, SRC= 12.1.1.1, dest_proxy= 10.1.1.0/0.0.0.0/0/0, src_proxy= 20.1.1.0/0.0.0.16/0/0, protocol= ESP, transform= esp-des esp-sha-hmac lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 IPSEC(key_engine): got a queue event... IPSEC(spi_response): getting spi 203563166 for SA from 12.1.1.2 to 12.1.1.1 for prot 2 IPSEC(spi_response): getting spi 194838793 for SA from 12.1.1.2 to 12.1.1.1 for prot 3 IPSEC(key_engine): got a queue event... IPSEC(initialize_sas): , (key eng. msg.) dest= 12.1.1.2, SRC= 12.1.1.1, dest_proxy= 10.1.1.0/255.255.255.0/0/0, src_proxy= 20.1.1.0/255.255.255.0/0/0, protocol= ESP, transform= esp-des esp-sha-hmac lifedur= 3600s and 4608000kb, spi= 0xC22209E(203563166), conn_id= 3, keysize=0, flags= 0x4 IPSEC(initialize_sas): , (key eng. msg.) SRC= 12.1.1.2, dest= 12.1.1.1, src_proxy= 10.1.1.0/255.255.255.0/0/0, dest_proxy= 20.1.1.0/255.255.255.0/0/0, protocol= ESP, transform= esp-des esp-sha-hmac lifedur= 3600s and 4608000kb, spi= 0xDED0AB4(233638580), conn_id= 6, keysize= 0, flags= 0x4 IPSEC(create_sa): sa created, (sa) sa_dest= 12.1.1.2, sa_prot= 50, sa_spi= 0xB9D0109(194838793), sa_trans= esp-des esp-sha-hmac , sa_conn_id= 5 IPSEC(create_sa): sa created, (sa) sa_dest= 12.1.1.2, sa_prot= 50, sa_spi= 0xDED0AB4(233638580), sa_trans= esp-des esp-sha-hmac , sa_conn_id= 6
Эти примеры сообщений об ошибках были сгенерированы из команд debug, перечисленных здесь:
debug crypto ipsec
debug crypto isakmp
debug crypto engine
Эти выходные данные показывают пример ошибки «Сбой проверки воспроизведения»:
%CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed connection id=#.
Эта ошибка возникает от реорганизации в среде передачи данных (особенно, при наличии параллельных путей) или путей обработки пакетов с неравной стоимостью внутри Cisco IOS для сравнения больших пакетов с малыми пакетами при нагрузке. Для того, чтобы получить представление, измените набор преобразований. Сообщение reply check возникает только тогда, когда включена функция transform-set esp-md5-hmac. Для того, чтобы отменить вывод этого сообщения, отключите esp-md5-hmac и выполняйте только шифрование. Обратитесь к дефекту Cisco номер CSCdp19680 (только для зарегистрированных пользователей).
VPN-туннель L2L IPsec не запускается на межсетевом экране PIX или устройстве ASA, и появляется сообщение об ошибке QM FSM.
Одной из возможных причин является несовпадение удостоверений прокси, таких как необходимый трафик, список контроля доступа (ACL) или ACL-список шифрования, на обоих концах туннеля. Проверьте конфигурацию на обоих устройства и убедитесь в соответствии ACL-списков шифрования.
Другой возможной причиной является несоответствие параметров набора преобразований. Удостоверьтесь, что на обоих концах туннеля шлюзы VPN используют один и тот же набор преобразований с одинаковыми параметрами.
В этих выходных данных показан пример сообщения об ошибке:
IPSEC(validate_proposal): invalid local address 12.2.6.2 ISAKMP (0:3): atts not acceptable. Next payload is 0 ISAKMP (0:3): SA not acceptable!
Это сообщение об ошибке относится к одной из следующих двух распространенных проблем:
Команда crypto map map-name local-address interface-id вынуждает маршрутизатор использовать неверный адрес в качестве идентификатора, поскольку она предполагает использование определенного адреса.
Криптографическая карта применяется к неправильному интерфейсу или не используется совсем. Чтобы убедиться, что криптокарта применяется к правильному интерфейсу, проверьте конфигурацию.
Эта ошибка debug появляется, если предварительные ключи на одноранговых узлах не совпадают. Чтобы устранить эту проблему, проверьте предварительные ключи на обеих сторонах.
1d00H:%CRPTO-4-IKMP_BAD_MESSAGE: IKE message from 150.150.150.1 failed its sanity check or is malformed
Это пример сообщения об ошибке основного режима. Сбой основного режима предполагает, что политики этапа 1 на концах туннеля не совпадают.
1d00h: ISAKMP (0:1): atts are not acceptable. Next payload is 0 1d00h: ISAKMP (0:1); no offers accepted! 1d00h: ISAKMP (0:1): SA not acceptable! 1d00h: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main Mode failed with peer at 150.150.150.1
Команда show crypto isakmp sa показывает, что ISAKMP SA находится в состоянии MM_NO_STATE. Это также означает, что основной режим неисправен.
dst src state conn-id slot 10.1.1.2 10.1.1.1 MM_NO_STATE 1 0
Убедитесь, что политика этапа 1 включена на обоих одноранговых узлах и что все атрибуты совпадают.
Encryption DES or 3DES Hash MD5 or SHA Diffie-Hellman Group 1 or 2 Authentication {rsa-sig | rsa-encr | pre-share
Это сообщение появляется в отладках, если списки контроля доступа для трафика IPSec не совпадают.
1d00h: IPSec(validate_transform_proposal): proxy identities not supported 1d00h: ISAKMP: IPSec policy invalidated proposal 1d00h: ISAKMP (0:2): SA not acceptable!
Списки доступа каждого узла должны быть зеркальным отражением друг друга (все записи должны быть зеркальным отражением друг друга). Этот вопрос представлен в следующем примере.
Peer A access-list 150 permit ip 172.21.113.0 0.0.0.255 172.21.114.0 0.0.0.255 access-list 150 permit ip host 15.15.15.1 host 172.21.114.123 Peer B access-list 150 permit ip 172.21.114.0 0.0.0.255 172.21.113.0 0.0.0.255 access-list 150 permit ip host 172.21.114.123 host 15.15.15.1
Это сообщение появляется, если этап 2 (IPsec) не совпадает с обеих сторон. Обычно это происходит, если существует несоответствие или несовместимость в наборе преобразований.
1d00h: IPSec (validate_proposal): transform proposal (port 3, trans 2, hmac_alg 2) not supported 1d00h: ISAKMP (0:2) : atts not acceptable. Next payload is 0 1d00h: ISAKMP (0:2) SA not acceptable
Проверьте, что наборы преобразования у обеих сторон совпадают:
crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]] ? ah-md5-hmac ? ah-sha-hmac ? esp-des ? esp-des and esp-md5-hmac ? esp-des and esp-sha-hmac ? esp-3des and esp-md5-hmac ? esp-3des and esp-sha-hmac ? comp-lzs
Это сообщение указывает, что адрес однорангового узла, настроенный на маршрутизаторе, является неправильным или изменился. Убедитесь, что адрес узла правилен и доступен.
1d00h: ISAKMP: No cert, and no keys (public or pre-shared) with remote peer 150.150.150.2
Это сообщение об ошибке обычно появляется вместе с соответствующим сообщением об ошибке VPN 3000 Concentrator Message: No proposal chosen(14). Это результат того, что соединения установлены между хостами. В конфигурации маршрутизатора предложения IPsec находятся в таком порядке, при котором предложение, выбранное для маршрутизатора соответствует списку доступа, а не узлу. В списке доступа представлена большая сеть, которая включает в себя узел, разделяющий трафик. Для того, чтобы исправить эту проблему, поставьте данное предложение маршрутизатора для соединения концентратор-маршрутизатор первым в списке. Таким образом предложение будет в первую очередь соответствовать выбранному узлу.
20:44:44: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 194.70.240.150, src= 198.174.236.6, dest_proxy= 10.0.0.76/255.255.255.255/0/0 (type=1), src_proxy= 198.174.238.203/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 20:44:44: IPSEC(validate_transform_proposal): peer address 198.174.236.6 not found
Эти выходные данные представляют собой пример сообщения об ошибке:
%PIX|ASA-4-402101: decaps: recd IPSEC packet has invalid spi for destaddr=dest_address, prot=protocol, spi=number
В полученном пакете IPsec указан индекс SPI, который отсутствует в базе данных SADB. Это может быть временным состоянием, вызванным следующими причинами:
Небольшие различия во времени устаревания сопоставлений безопасности (SA) между одноранговыми узлами IPsec
Очистка локальных сопоставлений SA
Неверные пакеты, отправленные узлом IPsec
Это также может быть связано с атакой.
Рекомендуемое действие: Узел может не предоставить подтверждение того, что локальные SA были очищены. Если на локальном маршрутизаторе устанавливается новое соединение, то в этом случае два узла могут успешно восстановить соединение. В противном случае, если проблема не устранена в течение длительного времени, каждый узел пытается установить новое соединение или связаться с администратором узла.
Ошибка 21:57:57: IPSEC(initialize_sas): invalid proxy IDs указывает, что полученный ИД прокси не совпадает с настроенным ИД прокси согласно списку контроля доступа. Чтобы убедиться, что эти два значения совпадают друг с другом, проверьте выходные данные команды debug.
В выходных данных команды debug предложенного запроса значения команды "corresponding access-list 103 permit ip 10.1.1.0 0.0.0.255 20.1.1.0 0.0.0.255" не совпадают. Список доступа относится к сети с одной стороны и к узлу с другой.
21:57:57: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 192.1.1.1, src= 192.1.1.2, dest_proxy= 10.1.1.1/255.255.255.0/0/0 (type=4), src_proxy= 20.1.1.1/255.255.255.0/0/0 (type=4)
Это означает, что ключи ISAKMP не совпадают. Чтобы гарантировать точность, смените ключ/перезагрузитесь.
Если настроенные политики ISAKMP не совпадают с политикой, предложенной удаленным узлом, маршрутизатор пытается использовать политику по умолчанию 65535. Если они также не совпадают, возникает сбой согласования ISAKMP. Пользователь получает на маршрутизаторах сообщения об ошибке Hash algorithm offered does not match policy! или Encryption algorithm offered does not match policy.
=RouterA= 3d01h: ISAKMP (0:1): processing SA payload. message ID = 0 3d01h: ISAKMP (0:1): found peer pre-shared key matching 209.165.200.227 ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy ISAKMP: encryption 3DES-CBC ISAKMP: hash MD5 ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP: life type in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 ISAKMP (0:1): Hash algorithm offered does not match policy! ISAKMP (0:1): atts are not acceptable. Next payload is 0 =RouterB= ISAKMP (0:1): Checking ISAKMP transform 1 against priority 65535 policy ISAKMP: encryption 3DES-CBC ISAKMP: hash MD5 ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP: life type in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 ISAKMP (0:1): Encryption algorithm offered does not match policy! ISAKMP (0:1): atts are not acceptable. Next payload is 0 ISAKMP (0:1): no offers accepted! ISAKMP (0:1): phase 1 SA not acceptable!
Это сообщение об ошибке возникает в случае сбоя проверки кода аутентификации сообщения хеша (HMAC) в пакете IPsec. Обычно это происходит, если пакет каким-либо образом поврежден.
Sep 22 11:02:39 131.203.252.166 2435: Sep 22 11:02:39: %MOTCR-1-ERROR:motcr_crypto_callback() motcr return failure Sep 22 11:02:39 131.203.252.166 2436: Sep 22 11:02:39: %MOTCR-1-PKTENGRET_ERROR: MOTCR PktEng Return Value = 0x20000, PktEngReturn_MACMiscompare
При появлении этого сообщения об ошибке его можно игнорировать. Однако если сообщение появляется периодически, необходимо найти повреждение пакета. Оно может быть вызвано ошибкой в средстве ускорения шифрования.
Это сообщение об ошибке появляется, если существует несоответствие набора преобразований. Убедитесь, что совпадающие наборы преобразования настроены на обоих узлах.
Это сообщение об ошибке появляется, когда параметры IPSec этапа 2 на локальном и удаленном узлах не совпадают. Для устранения этой неполадки задайте одинаковые параметры в наборе преобразований, чтобы успешно установилась VPN.
Эти выходные данные представляют собой пример сообщения об ошибке:
HW_VPN-1-HPRXERR: Virtual Private Network (VPN) Module0/2: Packet Encryption/Decryption error, status=4615
Это сообщение об ошибках могло появиться по одной из этих причин:
Фрагментация. Фрагментированные зашифрованные пакеты с помощью процессорной коммутации, что вынуждает передавать пакеты, обрабатываемые с помощью быстрой коммутации, на карту VPN до пакетов с процессорной коммутацией. Если достаточно много пакетов с быстрой коммутацией обрабатывается перед пакетами с процессорной коммутацией, порядковый номер ESP или AH для пакета с процессорной коммутацией устаревает и, когда пакет поступает на карту VPN, его порядковый номер оказывается за пределами окна повторной передачи. Это приводит к появлению ошибок порядкового номера AH или ESP (4615 и 4612 соответственно) в зависимости от используемой инкапсуляции.
Устаревшие записи кеша. Еще одна ситуация, в которой это может произойти, состоит в устаревании записи кеша быстрой коммутации, в случае чего первый пакет с промахом в кеш будет обработан с помощью процессорной коммутации.
Обходные решения
Выключите все типы аутентификации на наборе преобразований 3DES и используйте ESP-DES/3DES. Это эффективно отключает аутентификацию/защиту от анти-повтора, что (в свою очередь) предотвращает ошибки отбрасывания пакетов, связанные с неупорядоченным (смешанным) трафиком IPSec %HW_VPN-1-HPRXERR: Аппаратный VPN0/2: Ошибка шифрования/расшифровки пакетов, status=4615.
Одним из обходных решений, которое в действительности применяется в случае причины, упомянутой в пункте № 1 выше, состоит в настройке для максимального размера пакета (MTU) входящих потоков значения менее 1400 байт. Введите следующую команду для настройки максимального размера пакета (MTU) входящих потоков менее 1400 байт:
ip tcp adjust-mss 1300
Отключите карту AIM.
Выключите быструю коммутацию / коммутацию CEF на интерфейсах маршрутизатора. Для удаления быстрой коммутации можно использовать следующие команды в режиме интерфейсной настройки:
no ip route-cache
Вот пример сообщения об ошибке:
%C1700_EM-1-ERROR: packet-rx error: ESP sequence fail
Это сообщение об ошибке обычно указывает на одно из следующих возможных условий:
Зашифрованные пакеты IPsec отправляются маршрутизатором шифрования не по порядку из-за неправильной настройки механизма QoS.
Пакеты IPsec, полученные маршрутизатором дешифрования, расположены не по порядку из-за изменения их порядка на промежуточном устройстве.
Полученный пакет IPsec фрагментирован и требует дефрагментации перед аутентификацией и расшифровкой.
Обходной путь
Отключите QoS для трафика IPSec на маршрутизаторе шифрования или промежуточных маршрутизаторах.
Включите предварительную фрагментацию IPsec на маршрутизаторе шифрования.
Router(config-if)#crypto ipsec fragmentation before-encryption
Установите для размера MTU значение, которое не требует фрагментации.
Router(config)#interface type [slot_#/]port_#
Router(config-if)#ip mtu MTU_size_in_bytes
Обновите IOS до последнего доступного устойчивого образа в данной серии.
Примечание. Изменение размера MTU на любом интерфейсе маршрутизатора приведет к разъединению всех туннелей, которые завершаются на этом интерфейсе. Необходимо запланировать внедрение этого временного решения в ходе плановой остановки работы.
Эта ошибка появляется при попытке установить VPN-туннель на маршрутизаторах серии 7600:
crypto_engine_select_crypto_engine: can't handle any more
Эта ошибка связана с тем, что программное шифрование не поддерживается на маршрутизаторах серии 7600. Маршрутизаторы серии 7600 не поддерживают завершение туннеля IPSec без оборудования IPsec SPA. VPN поддерживается только при использовании карты IPSEC-SPA в маршрутизаторах серии 7600.
Эта команда отображает ISAKMP SA, установленное между равноправными пользователями.
dst src state conn-id slot 12.1.1.2 12.1.1.1 QM_IDLE 1 0
В выходных данных команды show crypto isakmp sa значение состояния всегда должно составлять QM_IDLE. Если значение состояния равно MM_KEY_EXCH, это означает, что настроенный предварительный ключ неправилен или IP-адреса узла отличаются.
PIX(config)#show crypto isakmp sa Total : 2 Embryonic : 1 dst src state pending created 192.168.254.250 10.177.243.187 MM_KEY_EXCH 0 0
Это можно исправить, настроив правильный IP-адрес или предварительный ключ.
Эта команда отображает ассоциации безопасности IPSec, установленные между одноранговыми сторонами. Между узлами 12.1.1.1 и 12.1.1.2 создается зашифрованный туннель, обеспечивающий передачу трафика между сетями 20.1.1.0 и 10.1.1.0. Можно увидеть две сборки ESP SA: входящую и исходящую. Заголовок проверки подлинности (AH) не используется, т. к. для него отсутствуют SA.
В следующих выходных данных показан пример команды show crypto ipsec sa.
interface: outside Crypto map tag: vpn, local addr. 12.1.1.1 local ident (addr/mask/prot/port): (20.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (12.1.1.2/255.255.255.255/0/0) current_peer: 10.2.1.1 dynamic allocated peer ip: 12.1.1.2 PERMIT, flags={} #pkts encaps: 345, #pkts encrypt: 345, #pkts digest 0 #pkts decaps: 366, #pkts decrypt: 366, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0, #send errors 0, #recv errors 0 local crypto endpt.: 12.1.1.1, remote crypto endpt.: 12.1.1.2 path mtu 1500, ipsec overhead 56, media mtu 1500 current outbound spi: 9a46ecae inbound esp sas: spi: 0x50b98b5(84646069) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): (460800/21) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x9a46ecae(2588339374) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: vpn sa timing: remaining key lifetime (k/sec): (460800/21) IV size: 8 bytes replay detection support: Y outbound ah sas:
Эта команда отображает данные отладки о соединениях IPsec и показывает первый набор атрибутов, которые запрещены из-за несовместимости на обоих концах. Вторая попытка согласования (3DES используется вместо DES и [SHA]) принимается и создается ISAKMP SA. Эта отладка также из клиента удаленного доступа, который принимает IP-адрес (10.32.8.1) за пределами локального пула. После создания ISAKMP SA атрибуты IPsec согласовываются и признаются допустимыми. Затем PIX настраивает сопоставления безопасности IPsec, как показано далее.
В этих выходных данных показан пример выполнения команды debug crypto isakmp.
crypto_isakmp_process_block: src 12.1.1.1, dest 12.1.1.2 OAK_AG exchange ISAKMP (0): processing SA payload. message ID = 0 ISAKMP (0): Checking ISAKMP transform 1 against priority 1 policy ISAKMP: encryption DES-CBC ISAKMP: hash MD5 ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP (0): atts are not acceptable. Next payload is 3 ISAKMP (0): Checking ISAKMP transform 3 against priority 1 policy ISAKMP: encryption 3DES-CBC ISAKMP: hash SHA ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP (0): atts are acceptable. Next payload is 3 ISAKMP (0): processing KE payload. message ID = 0 ISAKMP: Created a peer node for 12.1.1.2 OAK_QM exchange ISAKMP (0:0): Need config/address ISAKMP (0:0): initiating peer config to 12.1.1.2. ID = 2607270170 (0x9b67c91a) return status is IKMP_NO_ERROR crypto_isakmp_process_block: src 12.1.1.2, dest 12.1.1.1 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 12.1.1.2. message ID = 2156506360 ISAKMP: Config payload CFG_ACK ISAKMP (0:0): peer accepted the address! ISAKMP (0:0): processing saved QM. oakley_process_quick_mode: OAK_QM_IDLE ISAKMP (0): processing SA payload. message ID = 818324052 ISAKMP : Checking IPSec proposal 1 ISAKMP: transform 1, ESP_DES ISAKMP: attributes in transform: ISAKMP: authenticator is HMAC-MD5 ISAKMP: encaps is 1 IPSEC(validate_proposal): transform proposal (prot 3, trans 2, hmac_alg 1) not supported ISAKMP (0): atts not acceptable. Next payload is 0 ISAKMP : Checking IPSec proposal 2 ISAKMP: transform 1, ESP_3DES ISAKMP: attributes in transform: ISAKMP: authenticator is HMAC-MD5 ISAKMP: encaps is 1 ISAKMP (0): atts are acceptable. ISAKMP (0): processing NONCE payload. message ID = 818324052 ISAKMP (0): processing ID payload. message ID = 81 ISAKMP (0): ID_IPV4_ADDR src 10.32.8.1 prot 0 port 0 ISAKMP (0): processing ID payload. message ID = 81 ISAKMP (0): ID_IPV4_ADDR dst 12.1.1.1 prot 0 port 0 INITIAL_CONTACTIPSEC(key_engine): got a queue event...
Эта команда отображает данные отладки о соединениях IPsec.
IPSEC(key_engine): got a queue event... IPSEC(spi_response): getting spi 0xd532efbd(3576885181) for SA from 12.1.1.2 to 12.1.1.1 for prot 3 return status is IKMP_NO_ERROR crypto_isakmp_process_block: src 12.1.1.2, dest 12.1.1.1 OAK_QM exchange oakley_process_quick_mode: OAK_QM_AUTH_AWAIT ISAKMP (0): Creating IPSec SAs inbound SA from 12.1.1.2 to 12.1.1.1 (proxy 10.32.8.1 to 12.1.1.1.) has spi 3576885181 and conn_id 2 and flags 4 outbound SA from 12.1.1.1 to 12.1.1.2 (proxy 12.1.1.1 to 10.32.8.1) has spi 2749108168 and conn_id 1 and flags 4IPSEC(key_engine): got a queue event... IPSEC(initialize_sas): , (key eng. msg.) dest= 12.1.1.1, src= 12.1.1.2, dest_proxy= 12.1.1.1/0.0.0.0/0/0 (type=1), src_proxy= 10.32.8.1/0.0.0.0/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0xd532efbd(3576885181), conn_id= 2, keysize= 0, flags= 0x4 IPSEC(initialize_sas): , (key eng. msg.) src= 12.1.1.1, dest= 12.1.1.2, src_proxy= 12.1.1.1/0.0.0.0/0/0 (type=1), dest_proxy= 10.32.8.1/0.0.0.0/0/0 (type=1), protocol= ESP, transform= esp-3des esp-md5-hmac , lifedur= 0s and 0kb, spi= 0xa3dc0fc8(2749108168), conn_id= 1, keysize= 0, flags= 0x4 return status is IKMP_NO_ERROR
Этот пример выходных данных конфигурации маршрутизатора показывает, как включить разделенное туннелирование для VPN-соединений. Команда access list 150 связана с группой в соответствии с командой crypto isakmp client configuration group hw-client-groupname. Это позволяет клиенту Cisco VPN использовать маршрутизатор, чтобы получить доступ к дополнительной подсети, не входящей в туннель VPN. При этом безопасность соединения IPsec не ухудшается. Туннель сформирован в сети 172.168.0.128. Потоки трафика дешифруются в устройствах не содержащихся в команде access list 150, например, Интернет.
! crypto isakmp client configuration group hw-client-groupname key hw-client-password dns 172.168.0.250 172.168.0.251 wins 172.168.0.252 172.168.0.253 domain cisco.com pool dynpool acl 150 ! ! access-list 150 permit ip 172.168.0.128 0.0.0.127 any !
Темы в этом разделе относятся к типичным проблемам, с которыми сталкивается пользователь при настройке PIX для IPsec с помощью клиента VPN 3.x. Примеры конфигураций для PIX основаны на версии 6.x.
Эта проблема характерна для коммутации. Убедитесь, что в PIX есть маршрут для внутренних сетей, которые не связаны напрямую с одной и той же подсетью. Кроме того, для внутренних сетей должен присутствовать обратный маршрут к PIX для адресов в пуле клиентских адресов.
Пример выходных данных.
!--- Address of PIX inside interface. ip address inside 10.1.1.1 255.255.255.240 !--- Route to the networks that are on the inside segment. !--- The next hop is the router on the inside. route inside 172.16.0.0 255.255.0.0 10.1.1.2 1 !--- Pool of addresses defined on PIX from which it assigns !--- addresses to the VPN Client for the IPsec session. ip local pool mypool 10.1.2.1-10.1.2.254 !--- On the internal router, if the default gateway is not !--- the PIX inside interface, then the router needs to have route !--- for 10.1.2.0/24 network with next hop as the PIX inside interface !--- (as in Cisco IOS routers). ip route 10.1.2.0 255.255.255.0 10.1.1.1
Наиболее распространенная причина этой проблемы состоит в том, что при наличии туннеля IPSec от VPN-клиента к PIX весь трафик передается по туннелю на межсетевой экран PIX. Функции PIX не позволяют отсылать трафик обратно на интерфейс, с которого он был получен. Следовательно, трафик, отправляемый в Интернет, не пересылается. Чтобы устранить эту проблему, используйте команду split tunneling. Идея этого исправления состоит в том, что только определенный трафик передается через туннель, а остальной трафик отправляется непосредственно в Интернет, а не через туннель.
vpngroup vpn3000 split-tunnel 90 access-list 90 permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0 access-list 90 permit ip 172.16.0.0 255.255.0.0 10.1.2.0 255.255.255.0
Примечание.С помощью команды vpngroup vpn3000 split-tunnel 90 выполняется раздельное туннелирование с использованием списка доступа номер 90. Команда access-list 90 определяет, какой трафик должен проходить сквозь туннель, а остальной трафик отклоняется в конце списка доступа. Список доступа должен соответствовать списку для отклонения трансляции сетевых адресов на PIX.
Иногда после формирования туннеля может существовать возможность отправки эхозапросов на системы в сети позади межсетевого экрана PIX, но не удается использовать определенные приложения, такие как Microsoft Outlook. Распространенной проблемой является размер пакетов MTU. Заголовок IPSEC может иметь размер до 50-60 байт, которые добавляются к исходному пакету. Если размер пакета становится больше 1500 (значение по умолчанию для Интернета), то устройства должны его фрагментировать. После добавления заголовка IPSEC размер все еще менее 1496, что является максимальным значением для IPsec.
Команда show interface показывает MTU определенного интерфейса на доступных маршрутизаторах или на маршрутизаторах в помещении пользователя. Для определения MTU всего пути от источника до назначения передаются датаграммы различных размеров с установленным битом «Не фрагментировать» (DF). Если передаваемая датаграмма окажется больше MTU, это сообщение об ошибке передается обратно к источнику:
frag. needed and DF set
Эти выходные данные показывают пример того, как найти MTU для пути между хостами с IP-адресами 10.1.1.2 и 172.16.1.56.
Router#debug ip icmp ICMP packet debugging is on !--- Perform an extended ping. Router#ping Protocol [ip]: Target IP address: 172.16.1.56 Repeat count [5]: Datagram size [100]: 1550 Timeout in seconds [2]: !--- Make sure you enter y for extended commands. Extended commands [n]: y Source address or interface: 10.1.1.2 Type of service [0]: !--- Set the DF bit as shown. Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 1550-byte ICMP Echos to 172.16.1.56, timeout is 2 seconds: 2w5d: ICMP: dst (172.16.1.56): frag. needed and DF set. 2w5d: ICMP: dst (172.16.1.56): frag. needed and DF set. 2w5d: ICMP: dst (172.16.1.56): frag. needed and DF set. 2w5d: ICMP: dst (172.16.1.56): frag. needed and DF set. 2w5d: ICMP: dst (172.16.1.56): frag. needed and DF set. Success rate is 0 percent (0/5) !--- Reduce the datagram size further and perform extended ping again. Router#ping Protocol [ip]: Target IP address: 172.16.1.56 Repeat count [5]: Datagram size [100]: 1500 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.1.1.2 Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 1500-byte ICMP Echos to 172.16.1.56, timeout is 2 seconds: !!!!! 2w5d: ICMP: echo reply rcvd, src 172.16.1.56, dst 10.1.1.2 2w5d: ICMP: echo reply rcvd, src 172.16.1.56, dst 10.1.1.2 2w5d: ICMP: echo reply rcvd, src 172.16.1.56, dst 10.1.1.2 2w5d: ICMP: echo reply rcvd, src 172.16.1.56, dst 10.1.1.2 2w5d: ICMP: echo reply rcvd, src 172.16.1.56, dst 10.1.1.2 Success rate is 100 percent (5/5), round-trip min/avg/max = 380/383/384 ms
Примечание.Клиент VPN включает в себя служебную программу настройки MTU, которая позволяет пользователям настраивать MTU для клиента Cisco VPN. Если используется клиент PPPoE, настройте MTU для адаптера PPPoE.
Примечание.Для того чтобы настроить утилиту MTU для клиента VPN, выполните следующие действия.
Выберите Start (Пуск) > Programs (Программы) > Cisco System VPN Client (VPN-клиент Cisco) > Set MTU (Настроить MTU).
Выберите Local Area Connection (Локальное подключение) и нажмите переключатель 1400.
Нажмите кнопку ОК.
Повторите шаг 1 и выберите Dial-up Networking (Удаленный доступ к сети).
Нажмите переключатель 576, а затем OK.
Используйте команду sysopt connection permit-ipsec в конфигурациях IPSec на устройстве PIX, чтобы разрешить трафику IPSec проходить через межсетевой экран PIX без проверки операторов команды conduit или access-list. По умолчанию все входящие сеансы должны быть явно разрешены командным предложением conduit или access-list. При использовании защищенного трафика IPsec вторичная проверка списка доступа может быть избыточной. Для того, чтобы входящие сеансы аутентификации/шифрования IPsec были всегда разрешены, используйте команду sysopt connection permit-ipsec.
В стандартной конфигурации IPsec VPN используются два списка доступа. Один список используется для исключения трафика, направленного в туннель VPN, из процесса NAT. Другой список доступа определяет трафик для шифрования. Он включает в себя список шифрования ACL в настройке ЛВС-ЛВС или список раздельного туннелирования в конфигурации удаленного доступа. Если эти ACL-списки неправильно настроены или отсутствуют, трафик может передаваться через VPN-туннель только в одном направлении или вообще не передаваться через туннель.
Убедитесь, что все списки доступа, необходимые для конфигурации IPsec VPN, настроены и что эти списки определяют правильный трафик. Этот список содержит элементы, которые следует проверить, если ACL является вероятной причиной проблем с IPSec VPN.
Убедитесь, что в исключении NAT и списках доступа шифрования ACL указан правильный трафик.
Если имеется несколько туннелей VPN и списков шифрования ACL, убедитесь, что эти списки не пересекаются.
Не используйте ACL дважды. Даже если в ACL исключения NAT и в списке шифрования ACL указан одинаковый трафик, используйте два разных списка доступа.
Убедитесь, что конфигурация устройства позволяет использовать ACL исключения NAT. То есть используйте команду route-map на маршрутизаторе; используйте команду nat (0) на устройстве PIX или ASA. Список ACL исключения NAT необходимо для конфигураций ЛВС-ЛВС и удаленного доступа.
Чтобы узнать больше о проверке утверждений ACL, используйте раздел "Проверка правильности ACL" в документе "Наиболее распространенные решения проблем с L2L и IPsec VPN удаленного доступа".