Dlaczego BGP przez VPN nie kontroluje ścieżki warstwy bazowej

Dwie lokalizacje łączą BGP przez tunel IPsec, uczą się swoich prefiksów, a diagram zostaje przemianowany na kontrolę ścieżki. To właśnie ta etykieta jest początkiem zamieszania. Sesja rzeczywiście wymienia osiągalność i rzeczywiście stosuje politykę, ale nie ma nic do powiedzenia w kwestii tego, który dostawca, kabel czy router przenosi zaszyfrowane pakiety. Widziałem zespół odbudowujący działający tunel, bo oczekiwał, że zmiana trasy BGP przeniesie ruch na inną ścieżkę światłowodową, na którą sesja nigdy nie mogła wpłynąć.

Co ludzie zakładają, że kupuje sesja

Większość oczekiwań bierze się z tego, jak zmiana trasy wygląda w laboratorium. Ogłaszasz prefiks przez tunel, druga strona go instaluje i ruch się przemieszcza. Ta sama sekwencja dzieje się na routerze, który naprawdę ma pokrętła inżynierii ruchu, więc oba zjawiska się mylą. W laboratorium obie lokalizacje zwykle dzielą jedno łącze dostępowe i właśnie dlatego różnica nigdy się tam nie ujawnia.

BGP jest protokołem osiągalności. Mówi peerowi, że możesz dostarczyć pakiety dla prefiksu, i pozwala każdej stronie uszeregować otrzymane oferty. To jest naprawdę przydatne przez tunel: prefiksy pojawiają się i znikają, gdy lokalizacje przychodzą i odchodzą, a możesz odrzucić zakres bez zapisywania trasy statycznej na każdym urządzeniu brzegowym. Czego nie robi, to nie oddaje routerów dostawcy pod twoją kontrolę.

Warstwa bazowa przenosi zewnętrzny nagłówek. Twój punkt końcowy tunelu wysyła zaszyfrowane pakiety na adres peera, a sieć między tymi dwoma adresami przekazuje je trasami, które zainstalowali jej operatorzy. Nic w sesji BGP nie zmienia tej decyzji, chyba że ten sam dostawca udostępnia wspieraną usługę, która to robi.

Co sesja naprawdę przenosi

Mówca BGP otwiera połączenie TCP do portu 179 swojego peera, używając formatów komunikatów i atrybutów ścieżki zdefiniowanych w RFC 4271. Gdy adres peera znajduje się wewnątrz tunelu, tunel musi być podniesiony, a adres osiągalny, zanim sesja w ogóle zacznie się. Zakończona wymiana IKE nie jest sąsiadem BGP. Implementacje IPsec oparte na trasach przepuszczają ruch dopiero wtedy, gdy istnieje pasująca trasa tunelu, a ta oparta na polityce potrzebuje adresu peera wewnątrz chronionego selektora. Odwrócenie tego daje klasyczny stan, w którym tunel jest zielony, a sesja stoi bezczynnie.

Gdy sesja jest podniesiona, polityka decyduje, co ją przecina. Listy prefiksów, filtry AS-path, górny limit liczby prefiksów i wyraźna decyzja o trasach domyślnych to minimum, i obowiązują w obu kierunkach. Peer, który akceptuje wszystko, co otrzyma, może dać ci trasę domyślną, która po cichu zastępuje lokalny dostęp do internetu. Oba kierunki potrzebują osobnych list, bo to, co akceptujesz od peera, i to, co mu ogłaszasz, to dwie różne decyzje.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Dalej gryzie MTU. Enkapsulacja zmniejsza użyteczny ładunek, więc duża aktualizacja może zablokować sesję, która wygląda na doskonale ustanowioną: peer zostaje podniesiony, prefiksy nigdy nie docierają, a nic oczywistego nie trafia do dziennika. Ogranicz TCP MSS na interfejsie tunelu albo ustaw MTU tunelu z miejscem na narzut, zanim obwinisz filtry.

Dokąd nadal trafiają zewnętrzne pakiety

Zaszyfrowane pakiety z jednej lokalizacji do drugiej wychodzą tym, co lokalny router wybierze dla publicznego adresu peera. Jeśli obie lokalizacje kupują tranzyt u tego samego dostawcy, przechodzą przez ten sam obiekt metropolitalny albo jedna strona siedzi za NAT klasy operatorskiej, tunel przetrwa awarię dostawcy tylko przypadkiem. Liczenie ikon tuneli w narzędziu do monitorowania nic ci o tym nie mówi.

Wybór trasy i instalacja przekazywania to także osobne zdarzenia. Prefiks może siedzieć w tabeli BGP jako najlepszy i mimo to brakować w tabeli przekazywania, bo następny skok jest nierozwiązywalny albo wygrywa bardziej szczegółowa trasa. Gdy ktoś zgłasza, że BGP nauczył się prefiksu, ale ruch nie płynie, użyteczne pytanie brzmi, czy jest zainstalowany i na który następny skok wskazuje.

Uczciwa odpowiedź na przegląd projektu to lista wspólnych zależności: obwód dostępowy, dostawca nadrzędny, obiekt i każde urządzenie stanowe na ścieżce powrotnej. Sesja przez tunel nie może usunąć zależności, nad którą nie siedzi.

Trzy decyzje, które warto rozdzielić

Gdy projekt to miesza, każda rozmowa o awarii kręci się w kółko. Najpierw rozdziel je na papierze, potem przypisz każdą do urządzenia, które naprawdę ją egzekwuje.

Każdy wiersz ma innego właściciela. Pierwszy to negocjacja, drugi to konfiguracja na twoich urządzeniach, trzeci to w większości sieć kogoś innego. Wniosek o zmianę, który nazywa wiersz, którego dotyczy, jest znacznie łatwiejszy do zatwierdzenia niż ten, który mówi problem BGP.

Tryby awarii, na które warto się przygotować

Akceptowanie trasy zbiorczej peera to najczęstsza samodzielnie zadana rana. Ktoś ogłasza krótki agregat, by uprościć wymianę, druga strona go akceptuje, a ruch dla zakresów, które nie są za tunelem, podąża za tunelem i ginie. Filtruj po dokładnie oczekiwanych prefiksach albo użyj listy prefiksów z właściwymi granicami, i nigdy nie akceptuj nagiego agregatu, bo przez to sesja wygląda schludnie.

Czas wycofania jest drugi. Wykrywanie zależy od timerów podtrzymania, od BFD, jeśli je włączyłeś, od wykrywania martwego peera tunelu i od tego, jak szybko druga strona przestaje ogłaszać. Istniejące sesje to osobny problem: nowa trasa może przywrócić nowe połączenia, podczas gdy ustanowione sesje TCP nadal używają nieaktualnych adresów, a firewalle stanowe lub NAT na ścieżce mogą trzymać wpisy, które już nie pasują. Umieść odzyskiwanie aplikacji w kryteriach akceptacji, zamiast zakładać, że zmiana trasy wszystko załatwia.

Trzecia to asymetria ścieżki powrotnej. Ruch może przychodzić przez tunel i wracać łączem dostawcy, które nigdy nie było przeznaczone do jego przenoszenia, co objawia się jednokierunkowym dźwiękiem, nieudanymi uściskami dłoni lub zaporą ogniową, która wyrzuca odpowiedzi. Sprawdź oba kierunki osobno.

Co zapisać w umowie i jak to zweryfikować

Poproś o dozwolone prefiksy na piśmie: kto jest uprawniony do tworzenia każdego zakresu, czy trasa domyślna jest dozwolona i które rodziny adresów obsługuje usługa tunelu. RFC 8212 uczyniła jawną politykę importu i eksportu oczekiwaniem dla eBGP w implementacjach, które jej przestrzegają, więc peer, który nadal opiera się na niejawnej akceptacji wszystkiego, jest wart pytania.

Następnie weryfikuj z urządzenia, a nie z diagramu. Przydatne polecenia na routerach w stylu FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Dodaj dwie obserwacje, których tabela tras nie może ci dać. Przechwyć na interfejsie zewnętrznym, by potwierdzić, na który adres enkapsulowane pakiety naprawdę celują, na przykład tcpdump -ni eth0 udp port 51820 dla tunelu WireGuard albo filtr ESP dla IPsec. Potem prześledź w stronę publicznego adresu peera i porównaj skoki ze śladem wewnątrz tunelu; jeśli oba podążają tym samym łańcuchem dostawcy, twoja nadmiarowość żyje w polityce tras, a nie w sieci.

Na koniec celowo przetestuj wycofanie. Wyłącz tunel w oknie serwisowym, zanotuj, jak długo prefiks pozostaje zainstalowany, co dzieje się z istniejącymi sesjami i czy druga strona wraca do trasy, którą naprawdę byś zaakceptował. To ćwiczenie mówi o projekcie więcej niż jakikolwiek diagram.

Trasa to nie autoryzacja. Prefiksy, które uzgadniasz do wymiany, nie mówią nic o tym, którzy użytkownicy mogą dotrzeć do której usługi za tunelem, więc utrzymuj uwierzytelnianie, dozwolone usługi i zapory hostów dokładnie tam, gdzie były. Osiągalny peer to także nie pozwolenie na nieograniczony tranzyt ani na tworzenie dowolnych adresów, a tego rodzaju uprawnienie należy do umowy jako kwestia handlowa, a nie do wiersza polityki BGP.

• Nazwij prefiksy, które każda strona może tworzyć, i te, których nigdy nie wolno jej zaakceptować.
• Ogranicz MSS na tunelu i potwierdź, że duże aktualizacje naprawdę docierają.
• Wymień wspólne zależności warstwy bazowej, a nie liczbę tuneli.
• Zmierz prawdziwe wycofanie i zanotuj, co robi aplikacja.