Мы используем Cisco ASA для наших сетей IPSEC VPN, используя метод EZVPN. Время от времени мы сталкиваемся с проблемами, когда интернет-провайдер вносит изменения в свою сеть, и наша VPN перестает работать. В девяти случаях из десяти интернет-провайдер отрицает, что их изменение могло остановить эту работу - я подозреваю, потому что они точно не понимают, что могло вызвать проблему. Вместо того, чтобы просто бить их по головам, я хочу попытаться указать им в направлении, которое могло бы получить более быстрое разрешение.
В моем текущем инциденте я могу подключиться по ssh к внешнему интерфейсу ASA и немного покопаться:
sh crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: {Public IP address of London ASA}
Type : user Role : initiator
Rekey : no State : AM_TM_INIT_XAUTH_V6C
На другом конце ссылки я вижу следующее:
Active SA: 26
<snip>
25 IKE Peer: {public IP address of Port-Au-Prince-ASA}
Type : user Role : responder
Rekey : no State : AM_TM_INIT_MODECFG_V6H
Я не могу найти документации для чего AM_TM_INIT_XAUTH_V6C или AM_TM_INIT_MODECFG_V6H, но я почти уверен, что это означает, что рукопожатие IKE не удалось по какой-то причине.
Может ли кто-нибудь предложить какие-либо вероятные вещи, которые могут препятствовать успеху IKE, или конкретные детали того, что AM_TM_INIT_XAUTH_V6C средства?
Обновить: Мы подключили ASA на сайте клиента другого провайдера. Сразу подключилось VPN-соединение. Это подтверждает, что проблема не связана с конфигурацией. Теперь провайдер берет на себя ответственность и проводит дальнейшее расследование.
Обновить: На прошлой неделе соединение внезапно восстановилось. Я уведомил интернет-провайдера, чтобы узнать, изменили ли они что-нибудь, но ответа пока не получил. К сожалению, сейчас я вижу аналогичную проблему на другом сайте. Я нашел Документ Cisco о влиянии фрагментации на VPN. Я начинаю думать, что это может быть причиной проблем, которые я вижу.
С небольшой помощью Cisco я провел более глубокий анализ происходящего и выяснил, что мне нужно было проверить. Полезные вещи, которые мне рассказала Cisco:
debug crypto isakmp 5 дает достаточно подробностей, чтобы увидеть, возникают ли проблемы с трафиком ISAKMPclear crypto isakmp sa очищает все устаревшие ассоциации безопасности.clear crypto isakmp {client_ip_address} может использоваться в штаб-квартире для очистки определенной ассоциации безопасности (не обязательно очищать все свои ассоциации безопасности, если проблема возникает только с одним устройством!Немного почитав пакет IPSEC и ISAKMP, в частности, показал, что через любые межсетевые экраны на пути необходимо разрешить следующее:
Кажется, многие люди не понимают важной разницы между протоколами IP и портами TCP / UDP.
Следующие захваты пакетов ориентированы на указанные выше типы трафика. Они были настроены как на удаленном, так и на HQ ASA:
object service isakmp-nat-t
service udp destination eq 4500
description 4500
object-group service ISAKMP-Services
description Traffic required for ISAKMP
service-object esp
service-object ah
service-object object isakmp-nat-t
service-object udp destination eq isakmp
access-list ISAKMP extended permit object-group ISAKMP-Services host {hq_ip_address} host {remote_ip_address}
access-list ISAKMP extended permit object-group ISAKMP-Services host {remote_ip_address} host {hq_ip_address}
capture ISAKMP access-list ISAKMP interface outside
Затем вы можете загрузить снимки с каждого устройства по адресу https://{device_ip_address}/capture/ISAKMP/pcap и проанализировать это в Wireshark.
Мои захваты пакетов показали, что описанный выше трафик ISAKMP становится фрагментированным - поскольку эти пакеты зашифрованы, после фрагментации их трудно собрать вместе, и все ломается.
Предоставление этой информации интернет-провайдеру означало, что они могли провести собственную целенаправленную проверку, и привело к тому, что они внесли некоторые изменения в брандмауэр. Оказывается, провайдер блокировал все Трафик ICMP на их граничном маршрутизаторе, что означало, что обнаружение MTU пути было нарушено, что привело к фрагментированным пакетам ISAKMP. Как только они перестали полностью блокировать ICMP, появился VPN (и я ожидаю, что все их клиенты в целом стали получать более качественное обслуживание).
Ошибка AM_TM_INIT_XAUTH, вероятно, означает, что ваши предварительные общие ключи не совпадают. (источник www.cisco.com/warp/public/471/easyvpn-nem.pdf)
Все, что необходимо для установления сеанса IPSec, - это разрешить трафик udp, предназначенный для порта 500 (для IKE), и трафик ESP (или udp 4500 для NAT-T). Это похоже на проблему с конфигурацией, а не на проблему, вызванную интернет-провайдером. Не стесняйтесь размещать свою соответствующую конфигурацию, если вам нужна помощь в проверке.
Вполне возможно, что ваш интернет-провайдер неверно интерпретирует ваш трафик как обмен файлами P2P или что-то гнусное. Взгляни на М-Лаб чтобы узнать, может ли это происходить.