Cisco IPSec Site-to-site VPN. Разрешить трафик, если VPN не работает

Немного о планировании конфигурации ремня и брекетов.

Фон:

У нас есть успешная связь VPN между сайтами с нашим удаленным центром обработки данных.

Удаленная «защищенная» сеть - это также диапазон IP-сети, который открывается через брандмауэр как конечные точки, обращенные к Интернету.

Таким образом : мы используем VPN, чтобы получить доступ к закрытым конечным точкам.

Постановка проблемы :

Если канал VPN не работает, ASA отбрасывает трафик, даже если конечные точки Интернета все еще должны быть доступны через удаленный межсетевой экран.

Вопрос :

Как я могу настроить VPN для «пропускания» трафика как обычного исходящего трафика, когда VPN не работает.

Вот соответствующие сегменты конфига.

crypto map vpn-crypto-map 20 match address remdc-vpn-acl
crypto map vpn-crypto-map 20 set peer a.b.c.d 
crypto map vpn-crypto-map 20 set transform-set remdc-ipsec-proposal-set
crypto map vpn-crypto-map interface outside

ACL для сопоставления трафика очень примитивен: он определяет две сети, частную и удаленную, выраженные в виде сетевых объектов.

access-list remdc-vpn-acl extended permit ip object <private> object <remote> log 

И примитивная диаграмма.

                                     INTERNET
                                                x
                                                x
REM DC 203.000.113.000/24                      xx                       HQ 192.168.001.000/24
                                               x
           +---------------+                  x               +-----------+
           | REMOTE DC     |                 xx               |           |
           | ASA           e               xxx                | ASA 5505  |
+----------+               |              xx                  |           +-----------------+
   ^       |               e<-------------------------------------+       |
   |       |               |              xxxx                |           |
   |       |               e                 xxxx             |     ~     |
   |       |               |                    xx            |     |     |
   |       |               |                     xx           +----vpn----+
   |       |               |                      x                 |
   \-------vpn-------------vpn--------------------------------------/
           |               |                   xxx
           +---------------+                  xx
                                           xxx
                                          xx
                                       xxxx
    e = public Internet                x
        server endpoint

Спасибо

обкрадывать

Обновление 01

Более точный ACL обсуждался в комментариях ниже (с благодарностью)

Я могу предусмотреть два ACLS. (A) который разрешает ВСЕ для удаленной сети, а затем запрещает конечные точки, которые уже доступны через Интернет. и (B) который открывает только управление / контрольно-измерительные приборы по мере необходимости.

Проблема с (B) заключается в том, что выражение конечных точек, таких как WMI и Windows RPC, нецелесообразно без настройки стандартного сервера conf)

Таким образом, возможно (A) - лучший подход, который становится обратным конфигурации удаленного брандмауэра .

Обновление 02

Майк попросил увидеть больше конфигурации ios ASA.

Что следует для HQ ASA, который находится на сайте HQ. Удаленный DC находится под контролем поставщика центра обработки данных, и поэтому я не могу прокомментировать, как именно это может быть настроено.

Ну, не так много, чтобы показать: есть один маршрут по умолчанию к интернет-шлюзу, и никаких других конкретных маршрутов.

route outside 0.0.0.0 0.0.0.0 HQInetGateway 1

Интерфейсы очень простые. Только базовая конфигурация IPv4 и vlans для разделения группы на 1 внешний интерфейс и 1 внутренний интерфейс.

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.30.2.5 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 194.28.139.162 255.255.255.0
!

Ура, Роб

Я сейчас считаю, что это не практично; по крайней мере, в нашем конкретном сценарии.

Схема дополнительно усложняется тем фактом, что трафик «в туннель» выбирается ACL между HQ и RemoteDC (и поэтому мы можем сделать его настолько сложным, насколько мы хотим), но на обратном «пути» (так сказать) Концентратор VPN на удаленном конце выбирает всю сеть HQ в качестве защищенной сети.

В результате они не сбалансированы, и кажется, что прямой и обратный xlates не совпадают. Подобно наличию прямого и обратного маршрутов, которые приводят к сбою трафика, потому что NAT находится в игре в какой-то момент.

По сути - это отбрасывается как «слишком высокий технический риск» и требует гораздо большей оценки и, возможно, большего контроля над удаленным концом, прежде чем он станет решением.

Спасибо всем, кто посмотрел на это.

Если у вас есть или вы можете установить маршрутизатор внутри каждой ASA, вы можете создать зашифрованный туннель GRE и использовать маршрутизацию или плавающую статическую систему для выхода из строя в Интернет.