Безопасность : Многофункциональные устройства защиты Cisco ASA серии 5500

Когда клиенты VPN разъединяют, межсетевой экран ASA имеет высокую загрузку CPU вследствие петли трафика

15 августа 2013 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (9 августа 2013) | Отзыв

Введение

Этот документ описывает общую проблему, которая происходит, когда клиенты VPN разъединяют от устройства адаптивной защиты Cisco (ASA), который выполняется как головная станция VPN удаленного доступа. Этот документ также описывает ситуацию, где петля трафика происходит, когда пользователи VPN разъединяют от межсетевого экрана ASA. Этот документ не покрывает, как настроить или установить удаленный доступ к VPN, только особая ситуация, которая является результатом определенных, некоторый общих настроек маршрутизации.

Внесенный Магнусом Мортенсеном, специалистом службы технической поддержки Cisco.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Конфигурация VPN Удаленного доступа на Устройстве адаптивной защиты
  • Базовый уровень 3 понятия маршрутизации

Используемые компоненты

Сведения в этом документе основываются на модели 5520 Устройства адаптивной защиты, которая выполняет версию кода 9.1 (1) ASA.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Родственные продукты

Этот документ может использоваться с этими версиями программного и аппаратного обеспечения:

  • Любая модель Устройства адаптивной защиты
  • Любая версия кода ASA

Общие сведения

Когда пользователь соединяется с ASA как концентратор VPN удаленного доступа, ASA устанавливает основанный на хосте маршрут в таблице маршрутизации ASA, которая направляет трафик тому клиенту VPN внешний интерфейс (к Интернету). Когда тот пользователь разъединяет, маршрут удален из таблицы, и пакеты на внутренней сети (предназначенный тому разъединенному пользователю VPN) могли бы быть циклично выполнены между ASA и внутренним устройством маршрутизации.

Другая проблема состоит в том, что направленный (сеть) транслируемые пакеты (генерируемый удалением клиентов VPN) мог бы быть отправлен ASA как одноадресный фрейм к внутренней сети. Это могло бы отправить его назад ASA, который заставляет пакет быть циклично выполненным, пока не истекает Время жизни (TTL).

Этот документ объясняет эти проблемы и показы, какие методы настройки могут использоваться для предотвращения проблемы.

Проблема: Пакеты, предназначенные для разъединенной петли клиента VPN во внутренней сети

Когда пользователь VPN удаленного доступа разъединяет от межсетевого экрана ASA, пакеты все еще представляют на внутренней сети (предназначенный для тех разъединенных пользователей), и адрес VPN назначенного IP - адреса мог бы стать циклично выполненным во внутренней сети. Эти зацикливания пакетов могли бы заставить ЦПУ на ASA увеличиваться, пока петля не останавливается или вследствие значения IP TTL в пакетном заголовке IP, постепенно уменьшающемся к 0, или пользователь повторно соединяется, и IP повторно назначен на клиент VPN.

Чтобы понять этот сценарий лучше, рассмотрите эту топологию:

В данном примере клиенту удаленного доступа назначили IP-адрес 10.255.0.100. ASA в данном примере связан с тем же сегментом внутренней сети вместе с маршрутизатором. Маршрутизатор имеет два дополнительных уровня три сегмента сети, связанные с ним. Соответствующий интерфейс (маршрутизация) и конфигурации VPN ASA и маршрутизатора:

Выделение конфигурации ASA показывают в данном примере:

interface GigabitEthernet0/0
nameif outside
security-level 0
ip address 198.51.100.100 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.1.0.1 255.255.255.0
!
same-security-traffic permit intra-interface
!
ip local pool VPNpool 10.255.0.1-10.255.0.255
!
route outside 0.0.0.0 0.0.0.0 198.51.100.1
route inside 10.0.0.0 255.0.0.0 10.1.0.2

Выделение конфигурации маршрутизатора показывают в данном примере:

interface FastEthernet0
description connected to the inside interface of the ASA G0/1
ip address 10.1.0.2 255.255.255.0
!
interface FastEthernet1
 description connected to network segment
 ip address 10.2.0.1 255.255.255.0
!
interface FastEthernet2
 description connected to other network segment
 ip address 10.3.0.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 10.1.0.1

Таблице маршрутизации маршрутизатора, связанного с внутренней частью ASA просто, указали на маршрут по умолчанию внутренний интерфейс ASA 10.1.0.1.

В то время как пользователь связан через VPN с ASA показы таблицы маршрутизации ASA следующим образом:

ASA# show route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 198.51.100.1 to network 0.0.0.0
S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

Когда пользователь VPN удаленного доступа разъединяет от VPN, проблема происходит. На этом этапе основанный на хосте маршрут удален из таблицы маршрутизации ASA. Если хост в сети пытается передать трафик клиенту VPN, тот трафик маршрутизируется к внутреннему интерфейсу ASA маршрутизатором. Эта серия шагов происходит:

  1. Пакет, предназначенный к 10.255.0.100, поступает во внутренний интерфейс ASA.
  2. Выполнены стандартные проверки ACL.
  3. Таблица маршрутизации ASA проверена, чтобы определить исходящий интерфейс для этого трафика.
  4. Назначение пакета совпадает с широким маршрутом 10.0.0.0/8, который точки отступают внутренний интерфейс к маршрутизатору.
  5. ASA проверяет для наблюдения, позволен ли трафик прикрепления - это ищет внутриинтерфейс разрешения той-же-безопасности и находит, что позволено.
  6. Соединение создано к и из внутреннего интерфейса, и пакет отсылают назад к маршрутизатору как следующий переход.
  7. Маршрутизатор получает пакет, предназначенный к 10.255.0.100 на интерфейсе, который обращенным к ASA. Маршрутизатор проверяет свою таблицу маршрутизации для подходящего следующего перехода. Маршрутизатор находит, что следующий переход был бы внутренним интерфейсом ASA, и пакет передается ASA.
  8. Возврат к шагу 1.

Пример выходных данных команды приводится ниже.

Эта петля происходит до TTL этого пакета декременты к 0. Обратите внимание на то, что Межсетевой экран ASA не постепенно уменьшает значение TTL по умолчанию, когда это обрабатывает пакет. Маршрутизатор постепенно уменьшает TTL, поскольку это направляет пакет. Это предотвращает возникновение этой петли неопределенно, но эта петля действительно увеличивает трафик на ASA и заставляет ЦПУ пронзать.

Проблема: Направленный (сеть) Транслируемые пакеты, Генерируемые Клиентами VPN, Циклично выполнены на Внутренней сети

Эта проблема подобна первой проблеме.. Если клиент VPN генерирует пакет адресной трансляции к его подсети назначенного IP - адреса (10.255.0.255 в предыдущем примере) тогда, что пакет мог бы быть передан как одноадресный фрейм ASA к внутреннему маршрутизатору. Внутренний маршрутизатор мог бы тогда отправить его назад ASA, который заставляет пакет циклично выполняться, пока не истекает TTL.

Эта серия событий происходит:

  1. Машина клиента VPN генерирует пакет, предназначенный к адресу сетевой широковещательной рассылки 10.255.0.255, и пакет достигает ASA.
  2. ASA обрабатывает этот пакет как одноадресный фрейм (вследствие таблицы маршрутизации) и вперед это к внутреннему маршрутизатору.
  3. Внутренний маршрутизатор, который также обрабатывает пакет как одноадресный фрейм, постепенно уменьшает TTL пакета и вперед его назад к ASA.
  4. Повторения процесса до TTL пакета сокращены к 0.

Решения проблемы

Существует несколько возможных решений к этой проблеме. В зависимости от топологии сети и особой ситуации, одно решение могло бы быть проще внедрить, чем другой.

Решение 1 Используйте другой пул IP для клиентов VPN 

Это решение состоит в том, чтобы назначить удаленных пользователей VPN IP-адрес, который не накладывается на любую подсеть внутренней сети. Это было бы препятствовать тому, чтобы ASA передал пакеты, предназначенные к той подсети VPN назад к внутреннему маршрутизатору, если не был связан пользователь VPN.

Решение 2 Сделайте таблицу маршрутизации ASA более определенной для внутренних маршрутов

Это решение состоит в том, чтобы гарантировать, что таблица маршрутизации ASA не имеет любых очень широких маршрутов, которые накладываются на пул IP VPN. Для этого определенного примера сети удалите маршрут 10.0.0.0/8 из ASA и настройте более определенные статические маршруты для подсетей, которые находятся от внутреннего интерфейса. Зависящий от количества подсетей и топологии сети, это могло бы быть большим числом статических маршрутов, и это не могло бы быть возможно. 

Решение 3 Добавьте, что более определенный маршрут для подсети VPN отступает внешний интерфейс

Это решение немного более усложнено, чем другие перечисленные здесь и не рекомендуется выше других вследствие ситуации, описанной в примечании у основания этого раздела. Это решение состоит в том, чтобы препятствовать тому, чтобы ASA отправил пакеты из источника IP от IP-подсети VPN назад к встроенному маршрутизатору путем добавления более определенного маршрута для подсети VPN внешний интерфейс. Так как эта IP-подсеть зарезервирована для внешних пользователей VPN, пакеты с IP - адресом источника от этой IP-подсети VPN никогда не должны поступать входящие во внутренний интерфейс ASA. Самый простой способ достигнуть этого состоит в том, чтобы добавить маршрут для Пула IP VPN удаленного доступа внешний интерфейс с IP-адресом следующего перехода восходящего маршрутизатора ISP.

В этом примере топологии сети тот маршрут был бы похож:

route outside 10.255.0.0 255.255.255.0 198.51.100.1

В дополнение к этому маршруту добавьте, что ip проверяет обратный путь в команде, чтобы к заставить ASA отбрасывать любые пакеты получил входящий на внутреннем интерфейсе, исходящем от IP-подсети VPN, вследствие большего количества предпочитаемого маршрута, который существует на внешнем интерфейсе:

ip verify reverse-path inside

После того, как эти команды являются implemeted, таблица маршрутизации ASA выглядит подобной придерживающемуся, когда связан пользователь:

ASA# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

S 10.255.0.100 255.255.255.255 [1/0] via 198.51.100.1, outside
S 10.0.0.0 255.0.0.0 [1/0] via 10.1.0.2, inside
S 10.255.0.0 255.255.255.0 [1/0] via 198.51.100.1, outside
C 198.51.100.0 255.255.255.0 is directly connected, outside
C 10.1.0.0 255.255.255.0 is directly connected, inside
S* 0.0.0.0 0.0.0.0 [1/0] via 198.51.100.1, outside

Когда клиент VPN связан, основанный на хосте маршрут к тому IP-адресу VPN присутствует в таблице и предпочтен. То, когда клиент VPN разъединяет, трафик, исходящий от того IP-адреса клиента, который поступает в, внутренний интерфейс, проверено против таблицы маршрутизации, и отброшено вследствие ip, проверяют обратный путь в команде.

Если клиент VPN генерирует широковещание сети санкционируемой связи к IP-подсети VPN, тот пакет передан к внутреннему маршрутизатору, и отправлен маршрутизатором назад к ASA, где это будет отброшено вследствие ip, проверяют обратный путь в команде.

Примечание. После того, как это решение внедрено, если команда внутриинтерфейса разрешения той-же-безопасности присутствует в конфигурации, и политика доступа разрешает его, трафик, исходящий от пользователя VPN, предназначенного к IP-адресу в пуле IP VPN для пользователя, который не связан, мог бы быть поднят с постели назад внешний интерфейс в открытом тексте. Это - нераспространенная ситуация и может быть смягчено с использованием фильтров vpn в политике VPN. Если команда внутриинтерфейса разрешения той-же-безопасности присутствует в конфигурации ASA, эта ситуация только происходит.
Аналогично, если внутренние хосты генерируют трафик, предназначенный к IP-адресу в пуле VPN, и что IP-адрес не назначен на удаленного пользователя VPN, что трафик мог бы выход за пределами ASA в открытом тексте.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 116170