Virtual Connect wykorzystuje dwupoziomową architekturę headend, w której płaszczyzny sterowania routingu i GRE są dostarczane przez jedno urządzenie, a płaszczyzna sterująca IPsec jest zapewniana przez inne.

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

Poniższy rysunek przedstawia przykład modelu wdrażania połączenia wirtualnego dla opcji 2-koncentratora po stronie klienta.

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

Dla lepszej nadmiarowości zalecane są dwie witryny Hub, ale obsługiwanym modelem wdrażania jest również witryna One Hub z dwoma tunelami.

Od partnerów oczekuje się ścisłej współpracy z Klientami, zapewniając wybr anie najbardziej optymalnej ścieżki dla regionu usług Virtual Connect.

Poniższy rysunek przedstawia regiony równorzędne łączności w chmurze dedykowanej instancji.

Dodatek Routing for Virtual Connect jest realizowany przy użyciu zewnętrznego BGP (eBGP) między instancją dedykowaną a urządzeniem klienta (CPE). Cisco będzie reklamować swoją sieć dla każdego nadmiarowego prądu stałego w regionie do CPE Klienta, a CPE jest zobowiązany do reklamowania domyślnej trasy do Cisco.

• Cisco utrzymuje i przypisuje

  • Adresowanie IP interfejsu tunelowego (łącze przejściowe do routingu) Cisco przypisuje z wyznaczonej przestrzeni adresowej współdzielonej (niepodlega routingu publicznemu)

  • Adres oczekiwania transportu tunelowego (strona Cisco)

  • Prywatne numery autonomicznych systemów (ASN) do konfiguracji routingu BGP klienta

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

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

  • Cisco podzieli przypisaną sieć /24 na 2 /25 dla każdego DC w odpowiednim regionie

  • W programie Virtual Connect każda sieć /25 jest reklamowana z powrotem do CPE przez Cisco za pośrednictwem odpowiednich tuneli VPN typu punkt-punkt (łącze przejściowe)

  • CPE musi być skonfigurowany z odpowiednimi sąsiadami eBGP. Jeśli używasz jednego CPE, zostaną użyte dwóch sąsiadów eBGP, jeden wskazuje na każdy zdalny tunel. Jeśli używasz dwóch CPE, każdy CPE będzie miał jednego sąsiada eBGP prowadzącego do pojedynczego zdalnego tunelu dla CPE.

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

  • CPE jest wymagany do reklamowania domyślnej trasy nad każdym z tuneli

  • CPE można odpowiedzieć na redystrybucję, w razie potrzeby, wyuczonych tras w sieci korporacyjnej sprzedawcy.

• W warunkach awarii połączenia 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 przepuszczać ruch. W scenariuszu braku awarii ruch musi być podzielony na dwa tunele prowadzące do właściwych /25 miejsc docelowych, jeśli jeden z tuneli spadnie, 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 kopii zapasowej. Cisco będzie wysyłać ruch klientów za pośrednictwem wewnętrznej sieci WAN do DC, który utracił łączność.

Negocjacje dotyczące tunelu IPsec obejmują dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjacje fazy IKEv2 nie zostaną zakończone, nie ma inicjacji drugiej fazy IPsec. Najpierw wydaj polecenie „show crypto ikev2 sa” (na sprzęcie Cisco) lub podobne polecenie na sprzęcie innej firmy, 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 błędnie skonfigurowana.

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

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

• Zapora sieciowa blokuje pakiety UDP IKEv2.

Najpierw sprawdź dzienniki IPsec pod kątem wszelkich komunikatów, które pokazują postęp negocjacji tunelu IKEv2. Dzienniki mogą wskazywać, gdzie wystąpił problem z negocjacjami IKEv2. Brak wiadomości rejestrujących może również wskazywać, że sesja IKEv2 nie jest aktywowana.

Niektóre typowe błędy w negocjacjach IKEv2 to:

• Ustawienia IKEv2 po stronie CPE nie pasują do strony Cisco, ponownie sprawdź wymienione ustawienia:

  • Sprawdź, czy wersja IKE jest wersją 2.

  • Sprawdź, czy parametry szyfrowania i uwierzytelniania odpowiadają oczekiwanemu szyfrowaniu po stronie wystąpienia dedykowanego.

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

  • Sprawdź ustawienie żywotności.

  • Sprawdź grupę modułów Diffie Hellmana.

  • Sprawdź ustawienia funkcji pseudo-losowej.

• 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" (lub równoważne polecenie)

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

Jeśli komunikaty dziennika nie pokazują żadnych działań negocjacyjnych dla fazy IKEv2, może być konieczne przechwytywanie pakietów.

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

• GRE przechodzi od interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie dedykowanej instancji.

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

• Ping z adresu IP tunelu bocznego CPE na adres IP tunelu bocznego dedykowanej instancji.

  Ping nie może być IP transportu tunelu do adresu IP transportu tunelu, musi to być adres IP tunelu do tunelu IP.

Jeśli dla ruchu IKEv2 potrzebne jest śledzenie pakietów, należy ustawić filtr dla UDP i port 500 (gdy żadne urządzenie NAT nie znajduje się w środku punktów końcowych IPsec) lub port 4500 (gdy urządzenie NAT jest wstawione w środku punktów końcowych IPsec).

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

Sprawdź, czy pierwsza faza IPsec (tj. skojarzenie zabezpieczeń IKEv2) jest aktywna przed rozwiązywaniem problemów z drugą fazą IPsec. Wykonaj polecenie „show crypto ikev2 sa” lub równoważne polecenie, aby zweryfikować sesję IKEv2. Na wyjściu sprawdź, czy sesja IKEv2 trwała dłużej niż kilka sekund i czy nie odbija się. Czas działania sesji jest wyświetlany jako sesja „Aktywny czas” lub odpowiednik na wyjściu.

Gdy sesja IKEv2 zostanie zweryfikowana i aktywna, zbadaj sesję IPsec. Podobnie jak w przypadku sesji IKEv2, wykonaj polecenie „show crypto ipsec sa” lub równoważne polecenie, 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 negocjacji.

Niektóre z najczęstszych problemów, które mogą wystąpić podczas negocjacji IPsec, to:

Ustawienia po stronie CPE nie pasują do strony dedykowanej instancji, ponownie sprawdź ustawienia:

• Sprawdź, czy parametry szyfrowania i uwierzytelniania są zgodne z ustawieniami po stronie Dedykowana instancja.

• Sprawdź ustawienia Perfect Forward Secret i czy ustawienia pasują po stronie Dedykowanej instancji.

• Sprawdź ustawienia trwałości.

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

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

Gdy sesje IPsec i IKEv2 są weryfikowane jako aktywne i aktywne, tunel GRE zachowuje żywotność pakietów, które mogą przepływać między dedykowaną instancją a punktami końcowymi tunelu CPE. Jeśli interfejs tunelu nie wyświetla się statusu, niektóre typowe problemy to:

• VRF transportu interfejsu tunelu nie pasuje do VRF interfejsu pętli zwrotnej (jeśli konfiguracja VRF jest używana w interfejsie tunelu).

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

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

  Jeśli urządzenia CPE nie są obsługiwane przez urządzenie CPE, należy powiadomić Cisco, aby domyślne pamiątki po stronie dedykowanej instancji były również wyłączone.

  Jeśli obsługiwane są pamiątki pamięci, sprawdź, czy zapisy są włączone.

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

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

• Zapora sieciowa blokuje przesyłanie pakietów GRE do tunelu IPsec lub odbiór z tunelu IPsec (tunel GRE jest transportowany przez tunel IPsec)

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

Sprawdzenie ping powoduje powstanie pakietu GRE, który jest generowany z adresu IP transportu tunelu źródłowego do adresu IP transportu tunelu 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 zakończy się powodzeniem, a poprzednie elementy zostaną zweryfikowane, może być wymagane przechwytywanie pakietów, aby upewnić się, że ping icmp powoduje powstanie pakietu GRE, który jest następnie hermetyzowany w pakiet IPsec, a następnie wysyłany z źródłowego adresu IPsec na docelowy adres IPsec. Liczniki na interfejsie tunelu GRE i liczniki sesji IPsec mogą również pomóc w pokazanie. jeśli pakiety wysyłania i odbierania rosną.

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

Po stronie wystąpienia dedykowanego włączone są dwie funkcje umożliwiające dynamiczne dostosowywanie 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 dodanie dodatkowych nagłówków na górze nagłówków GRE jeszcze bardziej zmniejszy największy dozwolony MTU nad tunelem.

Tunel GRE dostosowuje funkcję MSS, a ścieżka tunelu GRE w funkcji wykrywania MTU jest włączona po stronie dedykowanej instancji. Skonfiguruj polecenie „ip tcp ajust-mss 1350" lub równoważne polecenie, a także „tunnel path\ u0002mtu-Discovery” lub równoważne polecenie po stronie klienta, aby pomóc w dynamicznej regulacji ruchu MTU przez tunel VPN.