Wprowadzenie

Virtual Connect korzysta z dwuwarstwowej architektury stacji czołowej, w której płaszczyzny sterowania routingiem i GRE są dostarczane przez jedno urządzenie, a płaszczyzna sterowania IPSec jest zapewniana przez inne.

Po zakończeniu Połączenie wirtualne Pomiędzy siecią korporacyjną klienta a dedykowanymi centrami danych Cisco zostaną utworzone dwa tunele GRE over IPSec . Po jednym na każde nadmiarowe centrum danych w odpowiednim regionie. Dodatkowe elementy sieciowe wymagane do komunikacji równorzędnej są wymieniane przez partnera lub klienta z Cisco za pośrednictwem formularza aktywacji usługi Control Hub Virtual Connect.

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

Połączenie wirtualne — VPN to projekt koncentratora, w którym lokalizacje koncentratora klienta są połączone z centrami danych DC1 i DC2 dedykowanego wystąpienia w określonym regionie.

Dla lepszej nadmiarowości zalecane są dwie lokacje centralne, ale jedna lokacja centralna z dwoma tunelami jest również obsługiwanym modelem wdrażania.

Przepustowość na tunel jest ograniczona do 250 Mb/s.

Zdalne lokalizacje Klienta w tym samym regionie musiałyby ponownie połączyć się z lokalizacjami centralnymi za pośrednictwem sieci WAN Klienta, a firma Cisco nie ponosi odpowiedzialności za tę łączność.

Od partnerów oczekuje się ścisłej współpracy z klientami, aby zapewnić wybór najbardziej optymalnej ścieżki dla regionu usługi „Virtual Connect”.

Rysunek 2 przedstawia regiony komunikacji równorzędnej usługi Dedicated Instance Cloud Connectivity.

Dodatek Routing dla Virtual Connect jest implementowany przy użyciu zewnętrznego protokołu BGP (eBGP) między dedykowanym wystąpieniem a urządzeniem klienta (CPE). Cisco ogłosi odpowiednią sieć dla każdego nadmiarowego kontrolera domeny w regionie na urządzeniu CPE klienta, a urządzenie CPE musi zaanonsować trasę domyślną do Cisco.

• Cisco utrzymuje i przypisuje

  • Adresowanie IP interfejsu tunelu (przejściowe łącze do routingu) przypisywane przez firmę Cisco z wyznaczonej współużytkowanej przestrzeni adresowej (niedostępnej publicznie)

  • Adres docelowy transportu tunelowego (po stronie Cisco)

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

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

• Protokół eBGP używany do wymiany tras między wystąpieniem dedykowanym a urządzeniem CPE

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

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

  • Urządzenie CPE musi być skonfigurowane z odpowiednimi sąsiadami eBGP. W przypadku korzystania z jednego urządzenia CPE zostanie użytych dwóch sąsiadów eBGP, z których jeden wskazuje każdy zdalny tunel. Jeśli używane są dwa urządzenia CPE, każdy CPE będzie miał jednego sąsiada eBGP kierującego do pojedynczego zdalnego tunelu dla urządzenia CPE.

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

  • Urządzenie CPE jest wymagane do anonsowania trasy domyślnej przez każdy z tuneli

  • CPE jest odpowiedzialne za redystrybucję, zgodnie z wymaganiami, poznanych tras w sieci korporacyjnej klienta.

• W warunkach bezawaryjnej awarii łącza pojedynczy sprzęt 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 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 nie działa, sieć /24 jest używana jako trasa zapasowa. Cisco będzie przesyłać ruch klientów przez wewnętrzną sieć WAN do kontrolera domeny, który utracił łączność.

Negocjacja tunelu IPsec obejmuje dwie fazy: fazę IKEv2 i fazę IPsec. Jeśli negocjowanie fazy protokołu IKEv2 nie zostanie ukończone, oznacza to, że nie ma inicjacji drugiej fazy protokołu 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, możliwe przyczyny mogą być następujące:

• Zainteresowany ruch nie wyzwala tunelu IPsec.

• Lista dostępu tuneli 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 po stronie wystąpienia dedykowanego i po stronie klienta.

• Zapora blokuje pakiety UDP IKEv2.

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

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

Dedykowana strona wystąpienia może nie zawsze rozpoczynać wymianę IKEv2 i czasami może oczekiwać, że inicjatorem będzie strona CPE klienta. Sprawdź konfigurację po stronie CPE pod kątem następujących wymagań wstępnych dotyczących inicjowania sesji IKEv2: Sprawdź listę dostępu kryptograficznego IPsec dla ruchu GRE (protokół 50) z adresu IP transportu tunelu CPE do IP IP transportu tunelu dedykowanego wystąpienia . Upewnij się, że interfejs tunelu GRE jest włączony dla funkcji utrzymywania aktywności GRE. Jeśli sprzęt nie obsługuje utrzymywania aktywności GRE, zostanie powiadomiony o tym Cisco , ponieważ utrzymywanie aktywności GRE będzie domyślnie włączone po stronie wystąpienia dedykowanego. Upewnij się, że protokół BGP jest włączony i skonfigurowany z adresem sąsiada adresu IP tunelu wystąpienia dedykowanego .

Po prawidłowym skonfigurowaniu tunel IPsec i negocjacja protokołu IKEv2 w pierwszej fazie rozpoczynają się od następujących czynności:

• Utrzymywanie aktywności GRE z interfejsu tunelu GRE po stronie CPE do interfejsu tunelu GRE po stronie wystąpienia dedykowanego.

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

• Wykonaj polecenie ping z adresu IP tunelu po stronie urządzenia CPE do adresu IP tunelu po stronie dedykowanego wystąpienia.

  Polecenie Ping nie może być adresem IP transportu tunelu do adresu IP transportu tunelu. Musi to być IP tunelu do IP tunelu.

Jeśli śledzenie pakietów jest wymagane dla ruchu IKEv2, ustaw filtr dla UDP i portu 500 (gdy żadne urządzenie NAT nie znajduje się w środku punktów końcowych protokołu IPsec) lub portu 4500 (gdy urządzenie NAT jest włożone w środku protokołu IPsec punkty końcowe).

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

Centrum danych wystąpienia dedykowanego może nie zawsze rozpoczynać pierwszy pakiet IKEv2. Wymagane jest, aby urządzenie CPE było w stanie zainicjować pierwszy pakiet IKEv2 w kierunku wystąpienia dedykowanego. Jeśli zezwala na to lokalna zapora, spróbuj również wysłać polecenie ping do zdalnego adresu IPsec. Jeśli polecenie ping z lokalnego do zdalnego adresu IPsec nie powiedzie się, wykonaj trasę śledzenia, aby pomóc i określić, gdzie pakiet został porzucony. Niektóre zapory i urządzenia internetowe mogą nie zezwalać na śledzenie trasy.

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

Gdy sesja IKEv2 zostanie zweryfikowana jako aktywna i aktywna, zbadaj sesję IPsec. Podobnie jak w przypadku sesji IKEv2, wykonaj polecenie „show crypto ipsec sa” lub równoważne, aby zweryfikować sesję IPsec. Zarówno sesja IKEv2, jak i sesja IPsec muszą być aktywne przed ustanowieniem 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 protokołu IPsec, to:

Ustawienia po stronie urządzenia CPE nie są zgodne po stronie wystąpienia dedykowanego, sprawdź ponownie ustawienia:

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

• Sprawdź, czy ustawienia Perfect Forward Secrecy są zgodne z ustawieniami po stronie Dedicated Instance.

• Sprawdź ustawienia okresu istnienia.

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

• Sprawdź źródłowy i docelowy adres IPsec.

Gdy sesje IPsec i IKEv2 zostaną zweryfikowane jako włączone i aktywne, pakiety utrzymywania aktywności tunelu GRE mogą przepływać między punktami końcowymi tunelu wystąpienia dedykowanego i CPE. Jeśli interfejs tunelu nie wyświetla stanu, niektóre typowe problemy to:

• VRF transportu interfejsu tunelu nie jest zgodny z VRF interfejsu pętli zwrotnej (jeśli konfiguracja VRF jest używana na interfejsie tunelu).

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

• Podtrzymywanie aktywności nie jest włączone w interfejsie tunelu bocznego CPE

  Jeśli urządzenia CPE nie obsługują funkcji utrzymywania aktywności, należy o tym powiadomić firmę Cisco , aby wyłączyć również domyślne podtrzymywanie aktywności po stronie wystąpienia dedykowanego. Jeśli utrzymywanie aktywności jest obsługiwane, sprawdź, czy utrzymywanie aktywności jest włączone.

• Maska lub adres IP interfejsu tunelu jest niepoprawny i nie jest zgodny z oczekiwanymi wartościami wystąpienia dedykowanego.

• Źródłowy lub docelowy adres transportowy tunelu jest niepoprawny i nie jest zgodny z oczekiwanymi wartościami wystąpienia dedykowanego.

• Zapora blokuje wysyłanie pakietów GRE do tunelu IPsec lub odbieranie z tunelu IPsec (tunel GRE jest przesyłany przez tunel IPsec)

Test ping powinien sprawdzić, czy interfejs lokalnego tunelu działa, a łączność ze zdalnym interfejsem tunelu jest dobra. Wykonaj test ping z IP tunelu (nie IP transportu ) do IP zdalnego tunelu .

Lista dostępu kryptograficznego dla tunelu IPsec, który przenosi ruch w tunelu GRE, zezwala na przechodzenie tylko pakietów GRE. W rezultacie pakiety ping nie będą działać z adresu IP transportu tunelowego do IP IP transportu zdalnego tunelu .

Test ping powoduje wygenerowanie pakietu GRE ze źródłowego IP transportu tunelu do docelowego IP transportu tunelu, podczas gdy ładunek pakietu GRE (wewnętrzny IP) będzie źródłowym i docelowym adresem IP tunelu.

Jeśli test ping nie powiedzie się, a powyższe elementy zostaną zweryfikowane, może być wymagane przechwycenie pakietu, aby upewnić się, że polecenie icmp ping spowoduje powstanie pakietu GRE, który jest następnie hermetyzowany w pakiet IPsec, a następnie wysyłany ze źródłowego adresu IPsec do docelowy adres IPsec. Pomocne w wyświetlaniu mogą być również liczniki w interfejsie tunelu GRE i liczniki sesji IPsec. jeśli pakiety wysyłania i odbierania są zwiększane.

Oprócz ruchu ping w przechwytywaniu powinny być również widoczne pakiety GRE z utrzymywaniem aktywności nawet podczas bezczynności ruchu. Na koniec, jeśli skonfigurowano protokół BGP, pakiety utrzymywania aktywności BGP powinny być również wysyłane jako pakiety GRE hermetyzowane w pakietach IPSEC, a także przez VPN.

Po stronie wystąpienia dedykowanego dostępne są dwie funkcje dynamicznego dostosowywania jednostki MTU do pakietów o dużych rozmiarach. Tunel GRE dodaje więcej nagłówków do pakietów IP przepływających przez sesję VPN . Tunel IPsec dodaje dodatkowe nagłówki nad nagłówkami GRE, co jeszcze bardziej zmniejszy największą jednostkę MTU dozwoloną w tunelu.

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