Cisco IPSec VPN typu lokacja-lokacja. Zezwól na ruch, jeśli VPN nie działa

Trochę planowania konfiguracji „pasa i aparatów ortodontycznych”.

Tło:

Mamy udane łącze VPN typu site-to-site do naszego zdalnego centrum danych.

Zdalna „chroniona” sieć to także zakres sieci IP otwierany przez zaporę ogniową jako punkty końcowe skierowane do Internetu.

Zatem : Używamy VPN, aby uzyskać dostęp do niepublicznych punktów końcowych.

Opis problemu :

Jeśli łącze VPN nie działa, ASA zmniejsza ruch, mimo że internetowe punkty końcowe powinny być nadal dostępne za pośrednictwem zdalnej zapory.

Pytanie :

Jak mogę skonfigurować VPN, aby „przekazywał” ruch jako zwykły ruch wychodzący, gdy VPN jest wyłączony.

Oto odpowiednie segmenty konfiguracji.

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

Lista ACL do dopasowywania ruchu jest bardzo prymitywna: określa dwie sieci, prywatną i zdalną, wyrażone jako obiekty sieciowe.

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

I prymitywny schemat.

                                     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

Dzięki

Obrabować

Zaktualizuj 01

Bardziej precyzyjne ACL zostało omówione w komentarzach poniżej (z podziękowaniami)

Mogę przewidzieć dwa ACLS. (A), który zezwala na ALL na zdalną sieć, a następnie zaprzecza punktom końcowym, które są już dostępne przez Internet. oraz (B), który otwiera tylko zarządzanie / oprzyrządowanie zgodnie z wymaganiami.

Problem z (B) polega na tym, że wyrażanie punktów końcowych, takich jak WMI i Windows RPC, jest niepraktyczne bez konieczności modyfikowania standardowej konfiguracji serwera)

Więc może (A) jest najlepszym podejściem, które staje się odwrotnością konfiguracji zdalnego firewalla .

Aktualizacja 02

Mike poprosił o więcej informacji na temat konfiguracji iOS ASA.

Poniżej znajduje się ASQ HQ, który znajduje się w centrali. Zdalny DC jest pod kontrolą dostawcy centrum danych, więc nie mogę komentować dokładnie, jak można to skonfigurować.

Cóż, nie ma wiele do pokazania: istnieje jedna domyślna trasa do bramy internetowej i nie ma innych określonych tras.

route outside 0.0.0.0 0.0.0.0 HQInetGateway 1

Interfejsy są bardzo proste. Tylko podstawowa konfiguracja IPv4 i vlany do podziału grupy na 1 interfejs zewnętrzny i 1 interfejs wewnętrzny.

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
!

Pozdrawiam, Rob

Jestem teraz zdania, że ​​to nie jest praktyczne; przynajmniej w naszym konkretnym scenariuszu.

Schemat jest dodatkowo skomplikowany przez fakt, że ruch „do tunelu” jest wybierany przez ACL między HQ a RemoteDC (i dzięki temu możemy uczynić go tak skomplikowanym, jak chcemy), ale na odwrotnej „ścieżce” (że tak powiem) Koncentrator VPN na zdalnym końcu wybiera całą sieć centrali jako sieć chronioną.

Rezultatem jest to, że się nie równoważą i wydaje się, że xlate do przodu i do tyłu nie pasują. Podobnie jak w przypadku tras do przodu i do tyłu, które powodują awarie ruchu, ponieważ w pewnym momencie gra NAT.

Zasadniczo - jest to odrzucane jako „zbyt wysokie ryzyko techniczne” i wymaga znacznie większej oceny i być może większej kontroli nad odległym końcem, zanim stanie się rozwiązaniem.

Dziękuję wszystkim, którzy to obejrzeli.

Jeśli masz lub możesz zainstalować router wewnątrz każdej ASA, możesz utworzyć zaszyfrowany tunel GRE i albo użyć routingu, albo pływającego statycznego urządzenia, aby zawieść w Internecie.