Virtual Connect wykorzystuje dwuwarstwową architekturę stacji czołowej, w której płaszczyzny routingu i sterowania GRE są dostarczane przez jedno urządzenie, a płaszczyzna sterowania IPSec jest dostarczana przez inne.

Po zakończeniu łączności Virtual Connect zostaną utworzone dwa tunele GRE przez IPSec między siecią korporacyjną Klienta a centrami danych Cisco Dedicated Instance. Po jednym do każdego nadmiarowego centrum danych w danym regionie. Dodatkowe elementy sieciowe wymagane do peeringu są wymieniane przez Partnera lub Klienta na Cisco za pośrednictwem formularza aktywacji Control Hub Virtual Connect.

Rysunek 1 przedstawia przykład modelu wdrażania połączenia wirtualnego dla opcji 2 koncentratorów po stronie klienta.

Virtual Connect - VPN to projekt Hub, w którym Centra Klienta są połączone z DC1 i DC2 centrów danych Dedykowanej Instancji w określonym regionie.

Dwie lokacje centrum są zalecane w celu zapewnienia lepszej nadmiarowości, ale jedna lokalizacja centrum z dwoma tunelami jest również obsługiwanym modelem wdrażania.

Oczekuje się, że partnerzy będą ściśle współpracować z Klientami, zapewniając wybór najbardziej optymalnej ścieżki dla regionu usług "Virtual Connect".

Rysunek 2 przedstawia regiony równorzędne łączności w chmurze dedykowanego wystąpienia.

Dodatek Routing for Virtual Connect jest implementowany przy użyciu zewnętrznego protokołu BGP (eBGP) między dedykowaną instancją a urządzeniem cpE (Customer Premise Equipment). Firma Cisco będzie reklamować swoją odpowiednią sieć dla każdego nadmiarowego kontrolera domeny w danym regionie do CPE Klienta, a CPE jest wymagany do anonsowania domyślnej trasy do Cisco.

• Cisco utrzymuje i przypisuje

  • Adresowanie IP interfejsu tunelu (łącze przejściowe do routingu) Cisco przypisuje z wyznaczonej współużytkowanej przestrzeni adresowej (niepublicznie rutowalnej)

  • Adres do wyznaczania transportu tunelowego (strona Cisco)

  • Numery prywatnych systemów autonomicznych (ASN) do konfiguracji routingu BGP klienta

    • Cisco przypisuje z wyznaczonego zakresu użytku prywatnego: Od 64512 do 65534

• eBGP używany do wymiany tras między dedykowaną instancją a CPE

  • Cisco podzieli przypisaną sieć /24 na 2 /25 po jednej dla każdego kontrolera domeny w danym regionie

  • W Virtual Connect każda sieć /25 jest anonsowana z powrotem do CPE przez Cisco przez odpowiednie tunele VPN typu punkt-punkt (łącze przejściowe)

  • CPE musi być skonfigurowany z odpowiednimi sąsiadami eBGP. W przypadku korzystania z jednego CPE zostaną użyte dwa sąsiady eBGP, po jednym wskazującym na każdy zdalny tunel. Jeśli używasz dwóch CPE, każdy CPE będzie miał jednego sąsiada eBGP łączącego się z pojedynczym zdalnym tunelem dla CPE.

  • Strona Cisco każdego tunelu GRE (adres IP interfejsu tunelu) jest skonfigurowana jako sąsiad BGP na CPE

  • CPE jest wymagane do anonsowania trasy domyślnej nad każdym z tuneli

  • CPE jest odpowiedzialny za redystrybucję, w razie potrzeby, wyuczonych tras w sieci korporacyjnej cutomera.

• W warunkach awarii łącza bez awarii pojedynczy CPE będzie miał dwa aktywne/aktywne tunele. W przypadku dwóch węzłów CPE każdy CPE będzie miał jeden aktywny tunel, a oba węzły CPE powinny być aktywne i przekazywać ruch. W scenariuszu bez awarii ruch musi zostać podzielony na dwa tunele prowadzące do właściwych miejsc docelowych /25, jeśli jeden z tuneli ulegnie awarii, pozostały tunel może przenosić ruch dla obu. W takim scenariuszu awarii, gdy sieć /25 jest wyłączona, sieć /24 jest używana jako trasa zapasowa. Cisco będzie wysyłać ruch klientów za pośrednictwem wewnętrznej sieci WAN do kontrolera domeny, który utracił łączność.

Negocjacje w tunelu IPsec obejmują dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjacje fazy IKEv2 nie zakończą się, nie zostanie rozpoczęta druga faza IPsec. Najpierw wydaj polecenie „Pokaż krypto ikev2 sa” (na urządzeniach Cisco) lub podobne polecenie na urządzeniach innych firm w celu sprawdzenia, czy sesja IKEv2 jest aktywna. Jeśli sesja IKEv2 nie jest aktywna, potencjalne przyczyny mogą być następujące:

• Ciekawy ruch nie uruchamia tunelu IPsec.

• Lista dostępu do tunelu IPsec jest nieprawidłowo skonfigurowana.

• Nie ma połączenia między klientem a interfejsem IP tunelu IPsec dedykowanego wystąpienia.

• Parametry sesji IKEv2 nie są zgodne między stroną dedykowanego wystąpienia a stroną klienta.

• Zapora blokuje pakiety IKEv2 UDP.

Najpierw sprawdź dzienniki IPsec dla wszelkich komunikatów pokazujących postęp negocjacji tunelu IKEv2. Dzienniki mogą wskazywać, gdzie występuje problem z negocjacjami IKEv2. Brak wiadomości logowania może również wskazywać, że sesja IKEv2 nie jest aktywowana.

Niektóre typowe błędy podczas negocjacji IKEv2 to:

• Ustawienia IKEv2 po stronie CPE nie są zgodne z ustawieniami Cisco. Sprawdź ponownie wymienione ustawienia:

  • Sprawdź, czy wersja IKE to wersja 2.

  • Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z oczekiwanym szyfrowaniem po stronie dedykowanego wystąpienia.

    Gdy jest używany szyfr "GCM", protokół GCM obsługuje uwierzytelnianie i ustawia parametr uwierzytelniania na NULL.

  • Sprawdź ustawienie żywotności.

  • Zweryfikuj grupę modułową Diffie Hellman.

  • Sprawdź ustawienia funkcji losowej Pseudo.

• Lista dostępu do mapy kryptograficznej nie jest ustawiona na:

  • Zezwolenie GRE (local_tunnel_transport_ip) 255.255.255.255 remote_tunnel_transport_ip() 255.255.255.255" (lub równoważne polecenie)

    Lista dostępu musi być przeznaczona specjalnie dla protokołu „GRE”, a protokół „IP” nie będzie działać.

Jeśli komunikaty dziennika nie pokazują żadnej aktywności negocjacyjnej dla fazy IKEv2, może być konieczne przechwytywanie pakietów.

Po prawidłowym skonfigurowaniu rozpoczyna się tunel IPsec i pierwsza faza negocjacji IKEv2:

• Keepalives GRE z interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie dedykowanego wystąpienia.

• Sąsiad BGP Sesja TCP od sąsiada BGP po stronie CPE do sąsiada BGP po stronie dedykowanego wystąpienia.

• Ping z adresu IP tunelu bocznego CPE do adresu IP tunelu bocznego dedykowanego wystąpienia.

  Ping nie może być transport tunelu IP do transportu tunelu IP, musi być tunel IP do tunelu IP.

Jeśli dla ruchu IKEv2 potrzebny jest ślad pakietów, ustaw filtr UDP i albo port 500 (gdy żadne urządzenie NAT nie znajduje się w środku punktów końcowych IPsec), albo port 4500 (gdy urządzenie NAT jest umieszczone w środku punktów końcowych IPsec).

Sprawdź, czy pakiety UDP IKEv2 z portem 500 lub 4500 są wysyłane i odbierane z adresu IP protokołu DI IPsec.

Sprawdź, czy pierwsza faza protokołu IPsec (czyli stowarzyszenie zabezpieczeń IKEv2) jest aktywna przed rozwiązaniem problemu z drugą fazą protokołu IPsec. Wykonaj polecenie „Pokaż krypto ikev2 sa” lub równoważne, aby zweryfikować sesję IKEv2. Na wyjściu sprawdź, czy sesja IKEv2 trwa dłużej niż kilka sekund i że nie odbija się. Czas trwania sesji jest wyświetlany jako sesja „Aktywny czas” lub równoważny w wyjściu.

Po zweryfikowaniu i uaktywnieniu sesji IKEv2 należy Zbadać sesję IPsec. Podobnie jak w przypadku sesji IKEv2 wykonaj polecenie „Pokaż krypto ipsec sa” lub równoważne, aby zweryfikować sesję IPsec. Zarówno sesja IKEv2, jak i sesja IPsec muszą być aktywne przed utworzeniem tunelu GRE. Jeśli sesja IPsec nie jest wyświetlana jako aktywna, sprawdź dzienniki IPsec pod kątem komunikatów o błędach lub błędów negocjacyjnych.

Niektóre z bardziej powszechnych problemów, z którymi można się spotkać podczas negocjacji protokołu IPsec, to:

Ustawienia po stronie CPE nie są zgodne ze stroną dedykowanego wystąpienia. Sprawdź ponownie ustawienia:

• Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z ustawieniami po stronie dedykowanego wystąpienia.

• Zweryfikuj ustawienia Perfect Forward Secrecy i dopasuj ustawienia po stronie Dedykowane wystąpienie.

• Sprawdź ustawienia żywotności.

• Sprawdź, czy protokół IPsec został skonfigurowany w trybie tunelu.

• Sprawdź adresy IPsec źródła i miejsca docelowego.

Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako aktywne, pakiety GRE keepalive tunelu mogą przepływać między dedykowanym wystąpieniem a punktami końcowymi tunelu CPE. Jeśli interfejs tunelu nie jest wyświetlany stan, do niektórych typowych problemów należą:

• Transport interfejsu tunelu VRF nie odpowiada VRF interfejsu loopback (jeśli konfiguracja VRF jest używana w interfejsie tunelu).

  Jeśli konfiguracja VRF nie jest używana w interfejsie tunelu, sprawdzenie to można zignorować.

• Keepalives nie są włączone w interfejsie tunelu bocznego CPE

  Jeśli w sprzęcie CPE nie są obsługiwane keepalify, należy powiadomić o tym firmę Cisco, aby również wyłączone były domyślne keepalify po stronie dedykowanego wystąpienia.

  Jeśli obsługiwane są keepalives, sprawdź, czy są włączone keepalives.

• Maska lub adres IP interfejsu tunelu jest nieprawidłowy i nie odpowiada oczekiwanym wartościom dedykowanego wystąpienia.

• Adres transportu tunelu źródłowego lub docelowego jest nieprawidłowy i nie odpowiada oczekiwanym wartościom Dedykowanego wystąpienia.

• Zapora blokuje pakiety GRE przed wysłaniem do tunelu IPsec lub odebraniem z tunelu IPsec (tunel GRE jest transportowany przez tunel IPsec)

Test ping powinien sprawdzić, czy lokalny interfejs tunelu jest w górze, a łączność jest dobra w zdalnym interfejsie tunelu. Przeprowadź kontrolę ping z IP tunelu (nie IP transportu) do zdalnego IP tunelu.

Kontrola ping powoduje, że pakiet GRE jest generowany z transportu tunelu źródłowego IP do transportu tunelu docelowego IP, podczas gdy ładunek pakietu GRE (wewnętrznego IP) będzie źródłem i docelowym IP tunelu.

Jeśli test ping nie powiódł się, a poprzednie elementy zostaną zweryfikowane, może być wymagane przechwytywanie pakietów, aby upewnić się, że w wyniku odrywania pakietów GRE zostanie wbudowany pakiet IPsec, a następnie wysłany ze źródłowego adresu IPsec do docelowego adresu IPsec. Liczniki na interfejsie tunelu GRE i liczniki sesji IPsec mogą również pomóc w wyświetleniu. jeśli pakiety wysyłania i odbierania są przyrostowe.

Oprócz ruchu ping, przechwytywanie powinno również pokazać keepalive pakiety GRE nawet podczas ruchu bezczynnego. Wreszcie, jeśli skonfigurowano BGP, pakiety keepalive BGP powinny być również wysyłane jako pakiety GRE zamknięte w pakietach IPSEC, a także przez VPN.

Po stronie dedykowanego wystąpienia dwie funkcje umożliwiają dynamiczną regulację MTU dla dużych rozmiarów pakietów. Tunel GRE dodaje więcej nagłówków do pakietów IP przepływających przez sesję VPN. Tunel IPsec dodaje dodatkowe nagłówki na górze nagłówków GRE jeszcze bardziej zmniejszy największy MTU dozwolony przez tunel.

Tunel GRE dostosowuje funkcję MSS i ścieżka tunelu GRE w funkcji wykrywania MTU jest włączona po stronie dedykowanego wystąpienia. Skonfiguruj "ip tcp adjust-mss 1350" lub równoważne polecenie, a także "ścieżka tunelu\u0002mtu-discovery" lub równoważne polecenie po stronie klienta, aby pomóc w dynamicznej regulacji ruchu MTU przez tunel VPN.