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 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, aby zapewnić wybór najbardziej optymalnej ścieżki dla regionu świadczenia usług Virtual Connect.

Poniższy rysunek przedstawia regiony peeringu łączności w chmurze Dedicated Instance.

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 tunelu IPsec składają się z dwóch faz: fazy IKEv2 i fazy IPsec. Jeżeli negocjacja fazy IKEv2 nie zostanie zakończona, druga faza IPsec nie zostanie zainicjowana. Najpierw należy wydać polecenie „show crypto ikev2 sa” (w przypadku sprzętu Cisco) lub podobne polecenie w przypadku sprzętu innej firmy, aby sprawdzić, czy sesja IKEv2 jest aktywna. Jeżeli sesja IKEv2 nie jest aktywna, potencjalnymi przyczynami mogą być:

• Interesujący ruch nie uruchamia tunelu IPsec.

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

• Nie ma połączenia między klientem a punktem końcowym tunelu IPsec dedykowanej instancji.

• Parametry sesji IKEv2 nie są zgodne między stroną dedykowanej instancji a stroną klienta.

• Zapora sieciowa blokuje pakiety IKEv2 UDP.

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

Oto niektóre typowe błędy w negocjacjach IKEv2:

• Ustawienia protokołu IKEv2 po stronie CPE nie są zgodne z ustawieniami Cisco. Sprawdź ponownie podane ustawienia:

  • Sprawdź, czy wersja IKE to wersja 2.

  • Sprawdź, czy parametry szyfrowania i uwierzytelniania odpowiadają oczekiwanemu szyfrowaniu po stronie dedykowanej instancji.

    Gdy używany jest szyfr „GCM”, uwierzytelnianiem zajmuje się protokół GCM, który ustawia parametr uwierzytelniania na wartość NULL.

  • Sprawdź ustawienia czasu życia.

  • Sprawdź grupę modułów Diffiego-Helmana.

  • Sprawdź ustawienia funkcji pseudolosowej.

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

  • Zezwól 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 wskazują na żadną aktywność negocjacyjną dla fazy IKEv2, może być konieczne przechwycenie pakietu.

Po prawidłowej konfiguracji rozpoczyna się tunel IPsec i pierwsza faza negocjacji IKEv2:

• Komunikacja GRE odbywa się z interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie dedykowanej instancji.

• Sesja TCP sąsiada BGP od sąsiada BGP strony CPE do sąsiada BGP strony dedykowanej instancji.

• Wykonaj polecenie ping z adresu IP tunelu bocznego CPE na adres IP tunelu bocznego instancji dedykowanej.

  Polecenie ping nie może być protokołem IP transportu tunelowego do IP transportu tunelowego, musi być protokołem IP tunelu do IP tunelu.

Jeśli dla ruchu IKEv2 potrzebny jest ślad pakietów, należy ustawić filtr dla protokołu UDP i portu 500 (gdy pomiędzy punktami końcowymi IPsec nie znajduje się żadne urządzenie NAT) lub portu 4500 (gdy pomiędzy punktami końcowymi IPsec znajduje się urządzenie NAT).

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

Przed przystąpieniem do rozwiązywania problemów z drugą fazą protokołu IPsec należy sprawdzić, czy pierwsza faza protokołu IPsec (czyli skojarzenie zabezpieczeń IKEv2) jest aktywna. Wykonaj polecenie „show crypto ikev2 sa” lub podobne, aby zweryfikować sesję IKEv2. W wynikach sprawdź, czy sesja IKEv2 trwa dłużej niż kilka sekund i nie jest przerywana. Czas aktywności sesji jest wyświetlany w wynikach jako „Czas aktywności” sesji lub jego odpowiednik.

Gdy sesja IKEv2 zostanie zweryfikowana i uznana za aktywną, należy zbadać sesję IPsec. Podobnie jak w przypadku sesji IKEv2, należy wykonać polecenie „show crypto ipsec sa” lub podobne, aby zweryfikować sesję IPsec. Przed zestawieniem tunelu GRE muszą być aktywne sesje IKEv2 i 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.

Podczas negocjacji IPsec można napotkać następujące problemy:

Ustawienia po stronie CPE nie odpowiadają ustawieniom po stronie instancji dedykowanej. Sprawdź ponownie ustawienia:

• Sprawdź, czy parametry szyfrowania i uwierzytelniania odpowiadają ustawieniom po stronie instancji dedykowanej.

• Sprawdź ustawienia Perfect Forward Secrecy i upewnij się, że odpowiadają one ustawieniom po stronie dedykowanej instancji.

• Sprawdź ustawienia czasu życia.

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

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

Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako działające i aktywne, pakiety podtrzymujące aktywność tunelu GRE będą mogły przepływać między punktami końcowymi tunelu dedykowanej instancji i CPE. Jeśli interfejs tunelu nie wyświetla swojego statusu, oto kilka typowych problemów:

• Transmisja VRF interfejsu tunelowego nie jest zgodna z transmisją VRF interfejsu pętli zwrotnej (jeśli w interfejsie tunelowym używana jest konfiguracja VRF).

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

• Keepalive nie są włączone na interfejsie tunelu bocznego CPE

  Jeśli urządzenia CPE nie obsługują funkcji keepalive, należy powiadomić firmę Cisco, aby wyłączyła domyślne funkcje keepalive również po stronie instancji dedykowanej.

  Jeśli funkcja keepalives jest obsługiwana, sprawdź, czy funkcja keepalives jest włączona.

• Maska lub adres IP interfejsu tunelu są niepoprawne i nie odpowiadają oczekiwanym wartościom instancji dedykowanej.

• Adres transportowy tunelu źródłowego lub docelowego jest niepoprawny i nie odpowiada oczekiwanym wartościom instancji dedykowanej.

• Zapora sieciowa blokuje pakiety GRE, uniemożliwiając ich wysyłanie do tunelu IPsec lub odbieranie z tunelu IPsec (tunel GRE jest przesyłany przez tunel IPsec).

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

Sprawdzenie pingiem skutkuje wygenerowaniem pakietu GRE z adresu IP transportu tunelu źródłowego do adresu IP transportu tunelu docelowego, podczas gdy treść pakietu GRE (wewnętrzny adres IP) będzie adresem IP tunelu źródłowego i docelowego.

Jeśli test pingowania zakończy się niepowodzeniem, a poprzednie elementy zostaną zweryfikowane, konieczne może okazać się przechwycenie pakietu w celu upewnienia się, że pingowanie protokołu ICMP skutkuje pakietem GRE, który następnie jest kapsułkowany w pakiecie IPsec i wysyłany ze źródłowego adresu IPsec na docelowy adres IPsec. Liczniki na interfejsie tunelu GRE i liczniki sesji IPsec mogą również pomóc w ustaleniu, czy liczba wysyłanych i odbieranych pakietów wzrasta.

Oprócz ruchu ping, przechwytywanie powinno także pokazywać pakiety GRE podtrzymujące aktywność, nawet podczas bezczynności. Na koniec, jeśli skonfigurowano protokół BGP, pakiety BGP keepalive powinny być również wysyłane przez sieć VPN jako pakiety GRE kapsułkowane w pakietach IPSEC.

Po stronie instancji dedykowanych włączone są dwie funkcje umożliwiające dynamiczne dostosowywanie MTU w przypadku 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 dodaje dodatkowe nagłówki na szczycie nagłówków GRE, co jeszcze bardziej zmniejszy największą dopuszczalną wartość MTU w tunelu.

Tunel GRE dostosowuje funkcję MSS, a ścieżka tunelu GRE w funkcji wykrywania MTU jest włączona po stronie instancji dedykowanej. Skonfiguruj polecenie „ip tcp adjust-mss 1350” lub podobne, a także „tunnel” path\u0002mtu-discovery" lub równoważne polecenie po stronie klienta, które pomoże w dynamicznym dostosowywaniu MTU ruchu przez tunel VPN.