Google HA VPN do routera Cisco: najpierw zaplanuj zasób peera
Nazwij oba interfejsy Google, zasób peera, umowę IKEv2 i każdą sesję BGP, zanim skonfigurujesz router Cisco, a następnie wybierz jednego peera lub dwa.
Pierwsza decyzja w HA VPN z Cisco do Google nie dotyczy tego, którego profilu kryptograficznego użyć, lecz tego, czy tunele zakończy jedno urządzenie lokalne, czy dwa. Brama HA VPN Google ma dwa interfejsy, a każdy z nich oczekuje odpowiedniego tunelu peera. To daje dwa tunele niezależnie od tego, czy masz dwa routery, a różnica polega na tym, czy jeden zasilacz lub aktualizacja oprogramowania może przewrócić cały projekt.
Decyzja to jedno urządzenie peera albo dwa
Wybierz układ na podstawie trzech warunków: czy możesz zaakceptować lokalny punkt awarii, czy oba interfejsy chmury muszą być używane i jaką rekonwergencję tolerują Twoje obciążenia. Jeśli którykolwiek z trzech jest twardym wymaganiem, dwa urządzenia peera to uczciwa odpowiedź.
Zdecyduj o tym, zanim otworzysz konsolę, ponieważ odpowiedź zmienia, ile tuneli i sesji BGP musi opisać arkusz roboczy.
Napisz arkusz roboczy przed jakimkolwiek poleceniem
Arkusz roboczy ma pięć wierszy, a każdy z nich potrzebuje właściciela:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Zewnętrzny zasób peera opisuje Twoje interfejsy wewnątrz Google Cloud, a jego utworzenie nie konfiguruje routera Cisco. Ta asymetria zaskakuje osoby, które oczekują, że konsola chmury będzie źródłem prawdy dla obu końców. To deklaracja tego, czego Google powinien oczekiwać, a router nadal musi się z nią zgadzać. przewodnik po bramie peera Google odwzorowuje tę deklarację na pracę z tunelem, BGP, zaporą i IKE, którą nadal jesteś winien.
Jeśli wiersz nie ma właściciela, uzupełni go osoba będąca na dyżurze podczas przełączenia.
Trzymaj trzy role adresów osobno
Publiczne adresy peera przenoszą zewnętrzną wymianę IPsec. Wewnętrzna para BGP należy do chronionego połączenia logicznego, które przez nią przebiega. Ogłaszane prefiksy LAN i VPC opisują obciążenia za tym połączeniem. Skopiowanie wewnętrznego adresu VM do zewnętrznego pola peera miesza dwie pierwsze role, a awaria wygląda jak problem negocjacji, a nie błąd wprowadzania danych.
Zaplanuj dwa odpowiednie tunele peera, po jednym dla każdego interfejsu HA VPN. Używanie obu interfejsów chmury samo w sobie nie usuwa lokalnego punktu awarii, ponieważ oba tunele nadal mogą wylądować na tej samej obudowie.
Zapisz rolę adresu obok każdej wartości w arkuszu roboczym. Ten jeden nawyk zapobiega większości mieszania.
Przetłumacz arkusz roboczy na wydanie Cisco
Zacznij od obsługiwanej dokumentacji peera lub odpowiedniego szablonu konfiguracji Google dla Twojej platformy, a następnie uzgodnij każdy symbol zastępczy z arkuszem roboczym. Sprawdź razem uwierzytelnianie IKEv2, propozycje ESP, PFS oraz model tunelu i routingu, ponieważ niezgodność w jednym z nich zwykle objawia się jako niezgodność w innym. Użyj rzeczywistej platformy i wydania oprogramowania, aby wybrać to, co jest obsługiwane, ponieważ receptura Classic VPN jest innym punktem wyjścia.
Trzymaj wspólny sekret poza zrzutami ekranu, załącznikami zgłoszeń i notatkami wsparcia. Wklejony w komentarz sprawy klucz wstępnie współdzielony to ujawnienie poświadczeń, a nie artefakt rozwiązywania problemów.
Jeśli szablon i arkusz roboczy się nie zgadzają, zatrzymaj się i rozwiąż to na papierze. Urządzenie nie będzie arbitrem za Ciebie.
Akceptuj każdy tunel na podstawie jego własnych dowodów
HA VPN potrzebuje sesji BGP, a udana negocjacja IKE ustanawia tylko pierwszy etap. Sesja wewnętrzna musi się podnieść, zamierzone prefiksy muszą zostać ogłoszone i zaakceptowane, a użyteczne trasy oraz uprawnienia zapory muszą istnieć, zanim ruch obciążeń się poruszy. Zapisanie tego jako jednego zielonego światła ukrywa, który etap faktycznie zawiódł.
Zapisuj dowody akceptacji dla każdego tunelu: wynegocjowane asocjacje bezpieczeństwa, stan sąsiada BGP, oczekiwane nauczone prefiksy i zamierzoną ścieżkę obciążenia. Następnie przeprowadź kontrolowany test awarii i odzyskiwania, ponieważ tunel, który nigdy nie zawiódł, jest tunelem, którego ścieżka odzyskiwania nie została przetestowana.
Ten zapis można ponownie wykorzystać przy następnej zmianie projektu, i to jest różnica między interoperacyjnością a fragmentem polecenia, którego założenia przepadły.