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.

Poniższy rysunek przedstawia przykład modelu wdrożenia połączenia wirtualnego dla opcji 2-koncentratora 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ługi Połączenie wirtualne .

Na poniższym rysunku przedstawiono regiony równorzędne połączeń z chmurą 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ść.

Negocjowanie tunelu IPsec obejmuje dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjacja fazy IKEv2 nie zostanie zakończona, nie rozpocznie się druga faza IPsec. Najpierw wydaj polecenie "show crypto ikev2 sa" (na urządzeniach Cisco) lub podobne polecenie na urządzeniach innych firm, aby sprawdzić, czy sesja IKEv2 jest aktywna. Jeśli sesja IKEv2 nie jest aktywna, potencjalnymi przyczynami mogą być:

• Ciekawy ruch nie uruchamia tunelu IPsec.

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

• Nie ma połączenia między klientem a adresem IP punktu końcowego tunelu IPsec dedykowanego wystąpienia.

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

• Zapora blokuje pakiety UDP IKEv2.

Najpierw sprawdź dzienniki IPsec pod kątem komunikatów pokazujących postęp negocjacji tunelu IKEv2. Dzienniki mogą wskazywać, gdzie występuje problem z negocjacją protokołu IKEv2. Brak komunikatów dziennika może również oznaczać, że sesja IKEv2 nie jest aktywowana.

Najczęstszymi błędami podczas negocjacji IKEv2 są:

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

  • Sprawdź, czy wersja usługi IKE to wersja 2.

  • Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z oczekiwanymi wartościami szyfrowania po stronie dedykowanego wystąpienia.

    Gdy jest używany szyfr „GCM”, protokół GCM obsługuje uwierzytelnianie i ustawia parametr uwierzytelniania na wartość NULL.

  • Zweryfikuj ustawienie czasu wygaśnięcia.

  • Sprawdź grupę obliczania modułu Diffiego Hellmana.

  • Sprawdź ustawienia funkcji pseudolosowej.

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

  • Zezwolenie na 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 wykazują aktywności negocjacyjnej dla fazy IKEv2, może być potrzebne przechwytywanie pakietów.

Po prawidłowej konfiguracji następuje rozpoczęcie działania tunelu IPsec i pierwszej fazy negocjacji protokołu IKEv2:

• Funkcja GRE utrzymuje się z bocznego interfejsu tunelowego GRE protokołu CPE do bocznego interfejsu tunelowego GRE dedykowanego wystąpienia.

• Sesja TCP sąsiedniego protokołu BGP używanego od sąsiedniego protokołu BGP po stronie protokołu CPE do sąsiedniego protokołu BGP dedykowanego wystąpienia.

• Sygnał ping z adresu IP tunelu bocznego urządzenia CPE do adresu IP tunelu bocznego dedykowanego wystąpienia.

  Kod ping nie może być adresem IP transportu tunelowego do adresu IP transportu tunelowego, musi to być adres IP transportu tunelowego.

Jeśli dla ruchu protokołu IKEv2 konieczne jest śledzenie pakietów, ustaw filtr dla protokołu UDP oraz port 500 (gdy urządzenie NAT nie znajduje się na środku punktów końcowych protokołu IPsec) lub port 4500 (gdy urządzenie NAT jest wstawiane na środku punktów końcowych protokołu IPsec).

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

Przed rozwiązaniem problemów z drugą fazą protokołu IPsec sprawdź, czy pierwsza faza protokołu IPsec (tj. powiązanie zabezpieczeń protokołu IKEv2) jest aktywna. Wykonaj polecenie "show crypto ikev2 sa" lub równoważne, aby zweryfikować sesję IKEv2. Na wyjściu sprawdź, czy sesja IKEv2 trwa ponad kilka sekund i czy się nie odbija. Czas trwania sesji jest wyświetlany jako „Czas aktywności” lub jego odpowiednik na wyjściu.

Po zweryfikowaniu sesji IKEv2 jako up i aktywności Sprawdź sesję IPsec. Podobnie jak w przypadku sesji IKEv2, wykonaj polecenie "show crypto ipsec sa" lub równoważne, aby zweryfikować sesję IPsec. Przed utworzeniem tunelu GRE muszą być aktywne zarówno sesja IKEv2, jak i sesja IPsec. 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 negocjacji.

Niektóre z bardziej powszechnych problemów, które mogą napotkać podczas negocjacji IPsec to:

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

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

• Sprawdź ustawienia doskonałego tajnego przekazywania oraz czy są one zgodne z ustawieniami po stronie dedykowanego wystąpienia.

• Zweryfikuj ustawienia czasu wygaśnięcia.

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

• Sprawdź źródłowe i docelowe adresy IPsec.

Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako aktywne, pakiety tunelu GRE mogą przepływać między dedykowanym wystąpieniem a punktami końcowymi tunelu CPE. Jeśli interfejs tunelowy nie pokazuje stanu, oto kilka typowych problemów:

• Wartość VRF transportu interfejsu tunelowego nie jest zgodna z wartością VRF interfejsu pętli zwrotnej (jeśli na interfejsie tunelowym jest używana konfiguracja VRF).

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

• Utrzymywanie aktywności nie jest włączone w bocznym interfejsie tunelu CPE

  Jeśli na urządzeniu CPE nie jest obsługiwane utrzymywanie aktywności, należy powiadomić firmę Cisco, aby wyłączyć również domyślne utrzymywanie aktywności po stronie dedykowanego wystąpienia.

  Jeśli obsługiwane są utrzymywanie aktywności, sprawdź, czy utrzymywanie aktywności jest włączone.

• Maska lub adres IP interfejsu tunelowego są niepoprawne i nie odpowiadają oczekiwanym wartościom dedykowanego wystąpienia.

• Źródłowy lub docelowy adres transportu tunelowego jest nieprawidłowy i nie odpowiada oczekiwanym wartościom dedykowanego wystąpienia.

• Zapora blokuje pakiety GRE wysłane do tunelu IPsec lub odebrane z tunelu IPsec (tunel GRE jest transportowany przez tunel IPsec)

Test ping powinien sprawdzić, czy lokalny interfejs tunelowy działa prawidłowo, a łączność z interfejsem zdalnego tunelu jest dobra. Wykonaj sprawdzenie ping z adresu IP tunelu (a nie adresu IP transportu) do adresu IP zdalnego tunelu.

Sprawdzenie ping powoduje wygenerowanie pakietu GRE, który jest generowany z adresu IP transportu tunelowego źródłowego do adresu IP transportu tunelowego docelowego, podczas gdy ładunek pakietu GRE (wewnętrzny adres IP) będzie adresem IP tunelu źródłowego i docelowego.

Jeśli test ping nie powiedzie się i poprzednie elementy zostaną zweryfikowane, może być wymagane przechwytywanie pakietów, aby upewnić się, że wywołanie ping icmp spowoduje utworzenie pakietu GRE, który następnie zostanie zamknięty w pakiecie IPsec, a następnie wysłany z źródłowego adresu IPsec do docelowego adresu IPsec. W wyświetleniu mogą również pomóc liczniki na interfejsie tunelu GRE oraz sesjach protokołu IPsec.

Oprócz ruchu ping przechwytywanie powinno również pokazywać działające pakiety GRE nawet podczas ruchu bezczynności. Na koniec, jeśli skonfigurowano protokół BGP, pakiety protokołu BGP powinny być wysyłane jako pakiety GRE ujęte w pakietach IPSEC oraz za pośrednictwem sieci VPN.

Po stronie dedykowanego wystąpienia dostępne są dwie funkcje umożliwiające dynamiczne dostosowywanie mechanizmu MTU do dużych rozmiarów pakietów. Tunel GRE dodaje więcej nagłówków do pakietów IP przesyłanych przez sesję VPN. Tunel IPsec doda dodatkowe nagłówki na górze nagłówków GRE spowoduje dalsze zmniejszenie największej dozwolonej wartości MTU w tunelu.

Tunel GRE dostosowuje funkcję MSS, a ścieżka tunelu GRE w funkcji wykrywania MTU jest włączona po stronie dedykowanego wystąpienia. Skonfiguruj polecenie „ip tcp adjust-mss 1350” lub równoważne oraz „tunnel path\u0002mtu-discovery” lub równoważne po stronie klienta, aby pomóc w dynamicznym dostosowywaniu MTU ruchu przez tunel VPN.