VPN w chmurze potrzebuje BGP: dlaczego inne protokoły routingu zawodzą

Asocjacja bezpieczeństwa IPsec działa, liczniki tunelu się zmieniają, a ruch do prefiksu w chmurze znika. Operator próbuje wtedy włączyć OSPF na routerze klienta, oczekując utworzenia sąsiada, i nic się nie dzieje. Tunel nigdy nie był brakującym elementem: zarządzany VPN w chmurze udostępnia zdefiniowany kontrakt routingu, a na dużych platformach tym kontraktem jest BGP. Dopóki nie istnieje sesja i nie zostanie zaakceptowany prefiks, tunel jest tylko szyfrowaną ścieżką bez celów za sobą.

Tunel działa, a trasy brakuje

Ukończenie fazy 1 i fazy 2 dowodzi, że strony zgadzają się co do ochrony, a nie że któraś strona wie, gdzie wysłać ruch. To osobne maszyny stanów z osobnymi trybami awarii.

Zadaj trzy pytania po kolei: czy prefiks został ogłoszony, czy sąsiad go zaakceptował i czy został zainstalowany do przekazywania? Prefiks ogłoszony i odfiltrowany to problem polityki. Prefiks, który nigdy nie został ogłoszony, to problem sesji lub konfiguracji. Prefiks zaakceptowany, ale niezainstalowany, to problem wyboru trasy, a każda odpowiedź wskazuje inny fragment konfiguracji.

Co dostawca faktycznie daje

Zarządzana brama VPN nie jest routerem bez ograniczeń. Dostawca daje bramę z obsługiwanymi adresami sąsiadów, ustawieniem systemu autonomicznego, limitami prefiksów i zdefiniowanym zachowaniem przy awarii. Ta powierzchnia jest produktem.

Google Cloud dokumentuje dynamiczny routing BGP dla HA VPN, w którym Cloud Router uczy się tras sąsiadów i dostarcza kwalifikowane niestandardowe trasy dynamiczne do VPC. AWS Site-to-Site VPN dokumentuje wybór między routingiem statycznym a dynamicznym i opisuje kontrole żywotności BGP jako przydatne przy przełączaniu tunelu, a jednocześnie obsługuje kontrole kondycji dla urządzeń bez BGP. Zachowania jednej platformy nie należy wnioskować z nazwy produktu drugiej.

Praktyczna konsekwencja jest taka, że najpierw wybiera się tryb zarządzany, a potem czyta obsługiwane parametry. Projekt, który zakłada typ sąsiedztwa nieoferowany przez usługę, nie jest problemem konfiguracji do rozwiązania na routerze klienta.

Ochrona tunelu i osiągalność to odrębne zadania

IPsec chroni ruch wybrany dla tunelu. BGP dostarcza informacje o osiągalności, które czynią prefiks kwalifikowanym. Działający tunel nie dowodzi, że oczekiwany prefiks został ogłoszony, zaakceptowany lub zainstalowany.

Wyobraź sobie oddział, który ogłasza 10.42.0.0/16 przez dwie kwalifikowane ścieżki tunelu. Usuń jedną użyteczną ścieżkę, a wybór trasy może się zmienić, mimo że nikt nie edytuje trasy każdego obciążenia. Wykrycie, wybór trasy i odzyskanie aplikacji nie są natychmiastowe i nie są identyczne między wdrożeniami, więc test przełączania musi obserwować całą sekwencję, a nie pierwszy pakiet, który przejdzie.

Gdy prefiks w chmurze jest nieosiągalny, sprawdź stan sesji i nauczone trasy, zanim dotkniesz kryptografii. Działająca SA bez trasy za sobą to najczęstsza postać tego objawu.

Gdzie załamują się założenia o OSPF

OSPF, IS-IS lub inny protokół wewnątrz tunelu IPsec jest całkowicie możliwy na urządzeniu zarządzanym samodzielnie, gdzie posiadasz oba końce i projekt przekazywania. Ten fakt nic nie mówi o usłudze zarządzanej, która oferuje tylko BGP jako tryb routingu dynamicznego.

Jeśli proponowany projekt wymaga sąsiedztwa, którego usługa nie obsługuje, zmień architekturę świadomie. Opcje obejmują urządzenie zarządzane samodzielnie w VPC, routing statyczny tam, gdzie usługa go obsługuje, lub inny produkt łączności. Konfiguracja protokołu tylko na routerze klienta nie może dodać sąsiada po stronie chmury, który nie istnieje, i nie sprawi, że prefiks się pojawi.

Nie przenoś odpowiedzi jednego dostawcy na bramę innego. Te same słowa, jak routing dynamiczny czy przełączanie tunelu, mogą opisywać różne mechanizmy i różne ograniczenia.

Przeczytaj wymaganie usługi, a potem projektuj

Przed pierwszą linią konfiguracji zapisz adresy sąsiadów, numery systemów autonomicznych, prefiksy, które będziesz ogłaszać i akceptować, limity tras oraz oczekiwane zachowanie przy awarii tunelu. Tych pięć punktów to kontrakt, wobec którego projektujesz.

Następnie zweryfikuj w tej samej kolejności: sesja nawiązana, prefiks odebrany, trasa obecna w tablicy tras VPC i rzeczywisty przepływ do adresu usługi. Powtórz po wymuszonym przełączeniu, ponieważ sesja, która się odtworzy, może wrócić z innym zestawem tras. Jeśli projekt zależy od zbieżności poniżej sekundy, zmierz ją, zamiast zakładać.

Przechowuj kontrakt usługi razem z rejestrem zmian. Gdy ktoś później zapyta, dlaczego tunel nie może uruchomić OSPF, odpowiedzią jest granica produktu, a nie ograniczenie protokołu, i rejestr powinien to stwierdzać.