Konfiguracja i diagnostyka BGP na Sophos Firewall

BGP wymienia wybrane trasy między routerami. Na Sophos Firewall jest to szczególnie przydatne przy wielu lokalizacjach, połączeniach redundantnych oraz VPN-ach do AWS lub Azure. Dla pojedynczej sieci docelowej ze stałym Next Hopem zwykle prostsza pozostaje trasa statyczna.

W poniższym przykładzie dwie zapory Sophos tworzą sesję eBGP przez sieć tranzytową. Na końcu Neighbor ma stan Established, Firewall A zna LAN za Firewall B i odwrotnie.

⚠️ Dynamic Routing powinien być dostępny tylko dla przewidzianej strony zdalnej. Zmiana Router ID przerywa wszystkie sesje BGP, a zmiana Local AS dodatkowo usuwa wszystkie skonfigurowane Neighbors i Networks. Obie zmiany należy więc wykonywać w zaplanowanym oknie serwisowym z aktualnym backupem.

BGP w siedmiu krokach

Do prostej konfiguracji IPv4 potrzebne są następujące kroki:

Ustalić adresy tranzytowe, lokalne i zdalne ASN oraz sieci, które mają być ogłaszane.
Sprawdzić bezpośrednią osiągalność IP między oboma peerami BGP.
W Administration > Device access zezwolić na Dynamic Routing tylko dla strefy peera albo przez wąską regułę Local Service ACL Exception; osobno sprawdzić reguły firewall wymagane przez projekt.
W Routing > BGP ustawić Router ID i Local AS.
Dodać adres IP peera jako Neighbor z jego Remote AS.
W Networks wprowadzić tylko wymagane lokalne prefiksy.
W Routing > Information > BGP-IPv4 sprawdzić State Established, poznaną trasę, a następnie rzeczywisty ruch.

O czym decyduje BGP na zaporze

BGP odpowiada na pytanie, które sieci są osiągalne przez dany router. Każdy uczestnik potrzebuje do tego kilku wyraźnie rozdzielonych wartości:

Local AS oznacza własny system autonomiczny. Dwa różne ASN tworzą połączenie eBGP; ten sam ASN po obu stronach oznaczałby iBGP.
Remote AS to ASN strony zdalnej.
Router ID identyfikuje router BGP w topologii BGP. Wygląda jak adres IPv4, ale nie musi być adresem interfejsu i powinien pozostać unikalny oraz stabilny.
Neighbor to adres IPv4 lub IPv6 strony zdalnej, z którym nawiązywana jest sesja BGP. W przykładzie jest to adres tranzytowy.
Network to lokalny prefiks, który zapora ma ogłaszać stronie zdalnej.

BGP nie zezwala na ruch użytkowy ani go nie szyfruje. Dynamic Routing w Device Access albo Local Service ACL steruje lokalną usługą BGP. Ruch przekazywany przez zaporę za pośrednictwem poznanych tras wymaga ponadto odpowiednich reguł firewall, działającej ścieżki powrotnej oraz, zależnie od projektu, świadomej konfiguracji NAT.

Dla routingu dynamicznego wewnątrz jednej spójnej domeny routingu wewnętrznego często bardziej naturalny jest OSPF. BGP lepiej pasuje między różnymi systemami autonomicznymi, do dostawców chmurowych albo tam, gdzie trasy muszą być celowo kształtowane przez polityki.

Planowanie przykładowej topologii

Przykład wykorzystuje dwie lokalizacje:

Firewall A: Local AS 65010, Router ID 192.0.2.10, adres tranzytowy 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, adres tranzytowy 198.51.100.2/30, LAN 10.20.20.0/24
Sieć tranzytowa: 198.51.100.0/30

Zakresy 192.0.2.0/24 i 198.51.100.0/24 są sieciami dokumentacyjnymi. Należy je zastąpić rzeczywistymi wartościami danego środowiska. Oba prywatne ASN nadają się do przykładu wewnętrznego; przy połączeniu z AWS, Azure lub dostawcą używa się wartości ASN i peera określonych przez stronę zdalną.

Router ID należy wybrać świadomie; musi być unikalny i stabilny. Przy ustawieniu Automatic SFOS używa najwyższego adresu IP interfejsu. Jeśli ten adres później się zmieni, może nieoczekiwanie zmienić się również tożsamość routera. Wartość ręczna usuwa tę zależność.

Bezpieczne przygotowanie BGP

Przed konfiguracją powinny być spełnione następujące warunki:

Zapora działa w Gateway Mode. BGP nie jest dostępny w Transparent Mode.
Oba adresy tranzytowe mogą się bezpośrednio osiągnąć. W przypadku tunelu XFRM również interfejs tunelowy musi być up.
Local AS, Remote AS, adresy peerów i dozwolone prefiksy są uzgodnione ze stroną zdalną.
Lokalna tablica routingu i planowane Networks są udokumentowane, aby po konfiguracji można było dokładnie sprawdzić każde ogłoszenie.
Dostępne są aktualny backup konfiguracji i niezależna ścieżka zarządzania.
Zaplanowano reguły firewall i ścieżki powrotne dla późniejszego ruchu użytkowego.

Podstawy interfejsu tranzytowego i strefy wyjaśnia artykuł Konfiguracja stref i interfejsów Sophos Firewall. Przed zmianą w produkcyjnym środowisku routingu poza appliance powinien być również dostępny aktualny backup zapory.

Selektywne zezwolenie na Dynamic Routing

W Administration > Device access opcja Dynamic Routing jest domyślnie wyłączona dla wszystkich stref. Dla osobnej sieci używanej wyłącznie jako tranzyt można aktywować tę usługę w jej strefie.

Jeśli interfejs peera współdzieli strefę LAN lub WAN z innymi sieciami, reguła Local Service ACL Exception dla konkretnego adresu IP peera lub sieci tranzytowej jest bardziej restrykcyjna niż szerokie zezwolenie dla całej strefy. W Administration > Device access > Local service ACL exception rule > Add tworzy się w tym celu regułę Accept, określając pola IP version, Source zone, Source networks and hosts, Destination hosts, usługę Dynamic Routing oraz odpowiednią Rule position. Następnie należy przetestować dostęp z dozwolonego adresu IP peera oraz z niedozwolonego źródła.

Pomoc Sophos dotycząca BGP wymaga dodatkowo reguł firewall dla przychodzącego i wychodzącego ruchu BGP. Jednocześnie pomoc dotycząca Device Access stwierdza, że lokalne usługi nie są kontrolowane przez reguły firewall. Te sformułowania nie są w pełni jednoznaczne. Dlatego należy osobno traktować Local Service ACL dla lokalnej usługi BGP, reguły wymagane przez projekt tunelu lub dostawcy oraz zwykłe reguły dla routowanego ruchu użytkowego. Nie wynika z tego potrzeba tworzenia ogólnej reguły „każdy do każdego” dla TCP 179. Zabezpieczanie dostępu do urządzenia na Sophos Firewall bardziej szczegółowo wyjaśnia lokalną warstwę dostępu.

Konfiguracja BGP w WebAdmin

Poniższe kroki wykonuje się na obu zaporach. Zamieniają się jedynie wartości lokalne i zdalne.

1. Ustawienie Router ID i Local AS

W Routing > BGP, w sekcji Global configuration, na Firewall A należy wprowadzić:

Jeśli konfiguracja BGP już istnieje, przed zastosowaniem zmiany trzeba udokumentować aktualny stan: zmieniony Router ID resetuje wszystkie sesje BGP, a zmieniona Local AS usuwa wszystkie Neighbors i Networks. Takie zmiany wykonuje się wyłącznie w zaplanowanym oknie serwisowym.

Router ID assignment: Manual
Router ID: 192.0.2.10
Local AS: 65010

Na Firewall B również używa się Manual, 192.0.2.20 i 65020. Następnie należy zastosować konfigurację globalną.

Local AS przyjmuje wartości od 1 do 4294967295. Dla środowisk wewnętrznych bez publicznego ASN Sophos wskazuje prywatny zakres od 64512 do 65535.

2. Dodanie strony zdalnej jako Neighbor

W Routing > BGP > Neighbors należy wybrać Add i na Firewall A wprowadzić:

IP version: IPv4
IP address: 198.51.100.2
Remote AS: 65020

Firewall B używa 198.51.100.1 jako Neighbor oraz 65010 jako Remote AS. Następnie na obu zaporach należy zapisać konfigurację przyciskiem Save.

Adres Neighbor nie jest zdalnym LAN-em ani Router ID, lecz bezpośrednio osiągalnym adresem tranzytowym strony zdalnej. Jeśli ten adres nie jest osiągalny albo ASN-y są zamienione, sesja nie osiągnie stanu Established.

3. Ogłoszenie lokalnego LAN-u

W Routing > BGP > Networks należy wybrać Add. Firewall A ogłasza:

IP version: IPv4
IP address: 10.10.10.0
Subnet mask: 255.255.255.0 (/24)

Na Firewall B wprowadza się zamiast tego 10.20.20.0 i 255.255.255.0 (/24).

Wpis Network określa ogłaszany prefiks; nie zastępuje lokalnej trasy ani reguły firewall. Po zapisaniu należy sprawdzić zarówno sesję, jak i prefiks ogłoszony oraz odebrany przez peera. Lista powinna zawierać tylko potrzebne prefiksy.

Zrozumienie sąsiadów i sieci IPv6

SFOS obsługuje IPv6 także w sekcjach Neighbors i Networks. Poprzedni przykład celowo pozostaje przy IPv4; dla IPv6 należy osobno wprowadzić wersję IP, bezpośrednio osiągalny adres IPv6 peera i prefiks IPv6.

WebAdmin automatycznie dodaje wymagane rozdzielenie. W konfiguracji wyłącznie CLI ustawienia domyślne są asymetryczne: Networks IPv4 są początkowo aktywne dla wszystkich Neighbors, również IPv6. Networks IPv6 nie są aktywne dla żadnego Neighbor. Dla Neighbor IPv6 jawnie ustawić:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Aby odwzorować defaulty WebAdmin w CLI, Sophos podaje także no bgp ebgp-requires-policy i bgp log-neighbor-changes. show running-config pokazuje tylko wartości różne od domyślnych; automatyczny Router ID i na przykład maximum-paths ibgp 16 mogą się nie pojawić. IPv4 i IPv6 trzeba sprawdzić oddzielnie w Routing > Information > BGP-IPv4 i BGP-IPv6, z osobnymi regułami IPv6 i ścieżkami powrotnymi.

Kontrola i odbiór BGP

Samo zestawienie sesji nie potwierdza jeszcze działającego przepływu pakietów. Odbiór odbywa się więc na kilku poziomach:

W Routing > Information > BGP-IPv4 > Neighbors strona zdalna musi mieć State Established.
W Routes Firewall A powinien widzieć prefiks 10.20.20.0/24, a Firewall B prefiks 10.10.10.0/24.
W Summary sprawdza się sesję i liczbę odebranych prefiksów.
W Diagnostics > Tools > Route lookup na Firewall A sprawdza się na przykład cel 10.20.20.10.
Następnie wykonuje się test rzeczywistej usługi między hostem z każdego LAN-u. Log Viewer i Packet Capture muszą pokazać oczekiwaną regułę, właściwy interfejs tranzytowy i ruch powrotny.

Neighbor ze stanem Established potwierdza tylko działającą wymianę BGP. Dopiero poznana trasa, prawidłowy Route Lookup i rzeczywiste połączenie potwierdzają cały projekt. W kontroli przepływu pakietów pomaga artykuł Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Ten sam przykład przez CLI

Jako alternatywę dla WebAdmin tę samą konfigurację podstawową można po zalogowaniu przez SSH wprowadzić w CLI routingu. Nie wykonywać poniższych poleceń w już skonfigurowanym środowisku przykładowym. Przed zmianami zapisać aktualny stan; zmiana ASN usuwa Neighbors i Networks oraz wymaga backupu i okna serwisowego. Sposób wejścia zależy od wersji SFOS.

SFOS 22: poniższa ścieżka menu otwiera bgp>. Tylko ten sposób wejścia zaczyna się od enable:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

Na Firewall A bez wcześniej przypisanego ASN:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing otwiera bezpośrednio router#; trzecia opcja menu i enable nie należą do tej ścieżki. Aby przypisać ASN po raz pierwszy na Firewall A:

configure terminal
router bgp 65010

Jeśli ASN jest już przypisany w SFOS 23, po configure terminal użyć zamiast tego router bgp bez ASN, aby wybrać istniejącą konfigurację. router bgp 65010 służy do pierwszego przypisania lub świadomie zaplanowanej zmiany ASN, a nie do niekontrolowanego ponownego przypisania.

Po dokładnie jednej z tych sekwencji wejścia kontynuować w trybie konfiguracji BGP:

no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
end
show running-config
write

Na Firewall B wartości Local AS, Router ID, Neighbor, Remote AS i Network zastępuje się odpowiednio wartościami 65020, 192.0.2.20, 198.51.100.1, 65010 i 10.20.20.0/24.

show running-config służy do kontroli. write zapisuje konfigurację CLI na stałe, pokazuje wpisy w WebAdmin i zachowuje je po restarcie. Bez write zmiana nie jest w pełni zakończona.

end opuszcza tryb konfiguracji przed tymi dwoma poleceniami. Dla SFOS 23 Sophos dokumentuje oczekiwane potwierdzenie zapisu Integrated configuration saved to /conf/routing/frr.conf; nie jest to wynik zaobserwowany tutaj na urządzeniu. Następnie porównać konfigurację i wpisy WebAdmin z zamierzonymi wartościami.

Oficjalnie udokumentowana dodatkowa kontrola to:

show ip bgp

Polecenie pokazuje znane prefiksy BGP oraz informacje o ich ścieżkach. Stan Neighbor i Summary najlepiej sprawdzać w Routing > Information > BGP-IPv4.

⚠️ Nie należy bez kontroli mieszać zaawansowanej konfiguracji CLI i WebAdmin. Edycja Neighbor w WebAdmin może usunąć dodatkowe wartości CLI, takie jak hasło Neighbor lub Route Map. Gdy używane są takie ustawienia, najpierw należy zapisać show running-config, a następnie dalej zarządzać konfiguracją BGP przez CLI.

SFOS 23.0: eksperymentalne BFD dla BGP

Bidirectional Forwarding Detection (BFD) monitoruje osiągalność sąsiada BGP za pomocą własnych pakietów kontrolnych. Dzięki temu zapora może wykryć awarię wcześniej niż przy użyciu samych timerów BGP. Ta opcjonalna procedura nie jest częścią opisanej wcześniej podstawowej konfiguracji BGP i nie dotyczy starszych wersji SFOS.

⚠️ W SFOS 23.0 BFD jest funkcją eksperymentalną. Udokumentowane zastosowanie dotyczy BGP we wdrożeniach Standalone; nie oznacza to dopuszczenia do użycia w klastrach HA ani z innymi protokołami routingu. W przypadku innych protokołów należy zaangażować Sophos Support. Avanet zaleca rozpoczęcie od odizolowanego środowiska testowego. Bez potwierdzonego dla zainstalowanej kompilacji sposobu wycofania zmiany nie należy włączać BFD w środowisku produkcyjnym.

Zakres zastosowania i przygotowanie

Sophos wymienia sąsiadów BGP-IPv4 i BGP-IPv6 oraz eBGP, iBGP, eBGP multihop i sąsiadów Route Reflector jako przypadki zastosowania BFD. Poniższy przykład pozostaje przy już skonfigurowanym sąsiedzie IPv4 198.51.100.2 na Firewall A. Nie stanowi dodatkowego zapewnienia obsługi konkretnej usługi Cloud VPN ani określonej topologii multihop.

Przed rozpoczęciem sesja BGP, oczekiwane prefiksy i ruch aplikacyjny muszą działać bez BFD. Strona zdalna musi być przygotowana do użycia BFD; adresy peerów, osiągalność i timery należy uzgodnić z jej administratorem. Należy zapisać informacje o aktualnej kompilacji SFOS, wynik show running-config, stan Neighbor i wynik Route Lookup oraz przygotować backup, okno serwisowe i niezależny dostęp administracyjny. Sposób usunięcia powiązania BFD z sąsiadem, dodatkowego profilu peera i wycofania konfiguracji usługi trzeba wcześniej uzgodnić z Sophos Support dla tej kompilacji. Instrukcja BFD nie dokumentuje kompletnych poleceń usuwania ani zatrzymywania.

Gdy monitorowany Neighbor stanie się nieosiągalny, zapora natychmiast usuwa z tablicy routingu wszystkie poznane od niego trasy. Ruch może przełączyć się na alternatywną ścieżkę tylko wtedy, gdy taka ścieżka istnieje; bez niej sieci, których dotyczy awaria, tracą trasę. Po powrocie sąsiada Sophos opisuje przywrócenie tras i ponowne przełączenie na pierwotną ścieżkę. Dlatego należy sprawdzić zarówno awarię, jak i powrót sąsiada, w tym rzeczywiście wybraną trasę.

Uruchomienie usługi i monitorowanie sąsiada

Usługa BFD jest domyślnie wyłączona. Poniższe polecenia zmieniają działanie routingu; przed ich wykonaniem trzeba dysponować zapisanym stanem wyjściowym i potwierdzonym sposobem wycofania zmiany. W CLI należy przejść do 5. Device Management > 3. Advanced shell i tam uruchomić usługę:

service -ds nosync bfdd:start

Następnie w tej samej Advanced Shell należy przejść do CLI routingu za pomocą vtysh:

vtysh

W CLI routingu należy dodać powiązanie BFD dla już istniejącego Neighbor na Firewall A. Router ID, Local AS, Remote AS i Networks pozostają bez zmian:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

198.51.100.2 należy zastąpić rzeczywistym adresem Neighbor, a nie jego LAN-em ani Router ID. Na Firewall B odpowiednim adresem w tym przykładzie jest 198.51.100.1. Stronę zdalną konfiguruje się zgodnie z instrukcją jej produktu. Jeśli sąsiad BGP jeszcze nie istnieje, najpierw należy ukończyć podstawową konfigurację BGP opisaną w tym artykule; BFD jej nie zastępuje. write zapisuje konfigurację routingu, ale nie potwierdza udanego zestawienia sesji BFD ani automatycznego uruchomienia usługi po restarcie.

Zmiana timerów tylko w uzasadnionych przypadkach

Do pierwszego testu Avanet zaleca udokumentowane wartości domyślne: Detect multiplier 3, Transmit interval 300 ms i Receive interval 300 ms. Bardzo krótkie interwały lub mnożnik powodujący zbyt czułe wykrywanie awarii mogą zwiększyć obciążenie przetwarzania. Nie gwarantuje to określonego czasu przełączenia.

Timery ustawia się w konfiguracji BFD, a nie w poleceniu konfigurującym sąsiada BGP. Jeśli potrzebny jest jawnie zdefiniowany profil peera, poniższy blok w CLI routingu pokazuje udokumentowane wartości domyślne dla tego samego przykładowego peera:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer uruchamia monitorowanie peera z domyślnymi timerami; ten dodatkowy blok nie jest potrzebny do skonfigurowania samego powiązania z BGP. Dla detect-multiplier Sophos dokumentuje zakres 1–155, a dla obu interwałów 10–4294967 ms. Wartość Transmit oznacza minimalny interwał wysyłania bez jittera, a wartość Receive — oczekiwany minimalny interwał odbierania. Strona zdalna oblicza swój czas wykrywania na podstawie lokalnego mnożnika oraz większej z dwóch wartości: lokalnego interwału wysyłania i zdalnego interwału odbierania. Dlatego należy uzgodnić ustawienia obu stron, zamiast wybierać jedynie możliwie najmniejszą wartość lokalną. Dodatkowe timery bezpośrednio po neighbor … bfd nie są prawidłową składnią.

Wspólna weryfikacja BFD, tras i aplikacji

W CLI routingu poniższe dwa polecenia służą wyłącznie do odczytu:

show bfd peers
show bfd peers brief

Dla przewidzianego peera oczekiwany jest Status: up. Szczegółowy wynik musi pokazywać odpowiednie timery lokalne i zdalne oraz Diagnostics: ok i Remote diagnostics: ok; widok skrócony przyporządkowuje status do adresu peera. Następnie należy ponownie sprawdzić sesję BGP w Routing > Information > BGP-IPv4 lub BGP-IPv6, oczekiwane prefiksy, Route Lookup i rzeczywisty ruch aplikacyjny. Sam stan BFD up nie potwierdza ani prawidłowej trasy BGP, ani ścieżki przepływu danych.

Test awarii należy przeprowadzać wyłącznie w zatwierdzonym środowisku testowym lub zaplanowanym oknie serwisowym, bez narażania niezależnego dostępu administracyjnego. Wcześniej trzeba udokumentować prefiksy poznane od monitorowanego Neighbor i planowaną ścieżkę zastępczą. Podczas kontrolowanej awarii peera odpowiednie trasy muszą zniknąć, a jeśli istnieje trasa zastępcza, musi ona działać i zapewniać przepływ ruchu aplikacyjnego. Po przywróceniu peera należy ponownie sprawdzić BFD up, BGP, przywrócone prefiksy, wybraną ścieżkę i aplikację. Nie przedstawiono tutaj żadnego wyniku z urządzenia ani udanego przełączenia jako już przetestowanych.

Diagnostyka błędów i wycofanie zmiany

Peer nie jest widoczny lub pozostaje down: należy sprawdzić uruchomienie usługi i powiązanie BFD w show running-config, a następnie porównać rzeczywisty adres peera, osiągalność i konfigurację BFD strony zdalnej. Za pomocą show bfd peers należy zebrać lokalną i zdalną diagnostykę oraz timery. Nie należy dodawać szerokiego zezwolenia Any-to-Any jako uniwersalnego rozwiązania; jeśli wymagania dotyczące dostępu są niejasne, trzeba zaangażować Sophos Support.
BFD przestaje działać po zmianie: zmiany powiązanych ustawień, takich jak adres docelowy lub Remote Gateway, mogą usunąć ustawienia BFD. Należy porównać konfigurację z zapisanym stanem, ponownie skonfigurować BFD dla danego Neighbor i przeprowadzić pełną weryfikację.
Niestabilna sesja lub większe obciążenie po zmianie timerów: w tym samym kontekście peera BFD należy przywrócić wcześniej udokumentowane wartości i zapisać je poleceniem write. Jeśli stanem wyjściowym był profil domyślny, powyższy blok pokazuje wartości 3 i 300 ms. Następnie trzeba sprawdzić diagnostykę obu peerów, trasy BGP i ruch, zanim zostaną zmienione kolejne wartości.
Całkowite wycofanie zmiany: należy zastosować wyłącznie plan wycofania potwierdzony wcześniej dla tej kompilacji, a następnie porównać konfigurację BGP bez BFD z zapisanym stanem wyjściowym. Ani wymyślone polecenie no, ani ogólne zatrzymanie usługi nie zastępuje tego planu. Usunięcie całego sąsiada BGP nie byłoby równoważne wycofaniu BFD, ponieważ spowodowałoby również usunięcie jego tras. Wycofanie można zakończyć dopiero wtedy, gdy sesja BGP, wymagane prefiksy, dostęp administracyjny i aplikacja ponownie działają w przewidziany sposób.

Weight, MED i globalna Route Precedence

Globalna Route Precedence porządkuje kategorie static, sdwan_policyroute i vpn. Należy ją odróżnić od atrybutów, których BGP używa do wyboru własnych ścieżek. system route_precedence show wyświetla bieżącą wartość globalną; należy ją zmieniać tylko wtedy, gdy te trzy kategorie rzeczywiście konkurują. Dostosowanie priorytetu routingu na Sophos Firewall wyjaśnia pełną procedurę weryfikacji i wycofania zmiany.

Między różnymi protokołami routingu decyduje między innymi Administrative Distance. W samym BGP oceniane są atrybuty BGP. Sophos wskazuje na przykład, że preferowana jest wyższa wartość Weight, a przy porównywalnych ścieżkach niższa wartość MED.

Jest to szczególnie ważne, gdy ten sam prefiks jest uzyskiwany przez redistribute ospf, a dodatkowo poznawany od BGP Neighbor. Lokalnie wygenerowana, redystrybuowana trasa ma domyślnie Weight 32768, natomiast trasa poznana od Neighbor ma Weight 0. Bez świadomej korekty wygrywa więc trasa redystrybuowana. Jeśli preferowana ma być ścieżka przez peera, trzeba ustawić dla niej wyższą wartość Weight, a następnie sprawdzić wynikową trasę.

Użycie MED dla wielu ścieżek wejściowych

SFOS 23: wcześniejsza kontrola nazw. Przed utworzeniem lub ponownym użyciem Access Lists, Prefix Lists lub Route Maps zinwentaryzować ich nazwy we wszystkich protokołach routingu dynamicznego. Są przechowywane w jednym pliku konfiguracji, a nazwy muszą być unikalne między protokołami. Unikać kolizji nazw i sprawdzić zamierzone powiązania Neighbor/polityk względem aktualnej i zapisanej konfiguracji. Ten wymóg nie zastępuje opisanego poniżej planu wycofania MED potwierdzonego dla zainstalowanej kompilacji; wykonywalna konfiguracja MED pozostaje wstrzymana do czasu potwierdzenia planu.

Aktualizacja do SFOS 23.0: Od tej wersji wszystkie protokoły routingu dynamicznego korzystają z jednej zintegrowanej konfiguracji. Podczas aktualizacji z wcześniejszej wersji zapora automatycznie dodaje prefiksy protokołów do nazw Route Maps, Prefix Lists i Access Lists, ale tylko w przypadku konfliktu nazw. Automatycznie aktualizuje również wszystkie odwołania do konfiguracji, których nazwy zostały zmienione. Nie oznacza to zmiany nazw wszystkich obiektów.

Po aktualizacji porównać zapisane wcześniej nazwy obiektów i odwołania z aktualnym show running-config oraz udokumentować powiązanie dawnych nazw z obecnymi. Sprawdzić, czy zamierzone powiązania Neighbor/Route Map nadal wskazują właściwe polityki, w tym istniejące powiązania MED. Nie przywracać bezrefleksyjnie dawnych nazw. W Routing > Information > BGP-IPv4 > Routes oraz za pomocą show ip bgp na peerze sprawdzić, czy oczekiwane prefiksy sieciowe są obecne, niedozwolone prefiksy są nieobecne i wybrana jest zamierzona ścieżka; za pomocą Route Lookup sprawdzić również ścieżkę rzeczywiście używaną. Ta kontrola nie zastępuje wymaganego poniżej planu wycofania MED dla zainstalowanej kompilacji ani nie znosi wstrzymania konfiguracji MED.

Multi-Exit Discriminator (MED) informuje bezpośrednio sąsiadujący AS, którą z wielu ścieżek wejścia do lokalnego AS powinien preferować. Niższy MED jest lepszy, a wartość domyślna wynosi 0. Na mniej pożądanej ścieżce ogłasza się więc wyższą wartość. Domyślnie MED porównuje się tylko, gdy ten sam prefiks jest poznawany wieloma linkami z tego samego sąsiedniego AS.

MED jest nietranzytywny. Gdy odbierający AS przekazuje trasę do innego AS, wartość wraca do 0. BGP wcześniej ocenia Weight, Local Preference, lokalne pochodzenie, długość AS Path i Origin Type. MED decyduje tylko, gdy te atrybuty są równe. Ustawiona wartość nie dowodzi więc wygranej wybranej ścieżki.

Sophos ustawia MED za pomocą wychodzącej Route Map ze stałym numerem sekwencji i wiąże ją z konkretnym Neighbor w IPv4 Address Family. out zmienia ogłoszenie wysyłane do tego peera; nie wymusza bezpośrednio wychodzącej ścieżki ruchu na Sophos Firewall. Oficjalna strona SFOS 22 dokumentuje konfigurację, ale nie pełne wycofanie. Dlatego zmianę należy wdrożyć dopiero po osobnym potwierdzeniu dokładnych poleceń usuwających dla zainstalowanej kompilacji i zapisaniu ich jako planu odtworzenia wraz z zabezpieczonym wcześniej wynikiem show running-config.

Po zatwierdzonej zmianie show ip bgp na routerze odbiorczym musi pokazywać oczekiwaną wartość MED i preferowaną ścieżkę. Na peerze Sophos trasa jest dodatkowo widoczna w Routing > Information > BGP-IPv4 > Routes. Bez takiego porównania stanu przed zmianą i po niej ten fragment pozostaje pomocą decyzyjną, a nie gotową do wykonania zmianą produkcyjną.

BGP przez route-based IPsec i Cloud VPN

BGP może działać przez zaadresowany interfejs XFRM tunelu Site-to-Site IPsec route-based. Oba interfejsy XFRM otrzymują w tym celu odpowiednie adresy tranzytowe. Dynamic Routing udostępnia się selektywnie dla strefy VPN; reguły dla ruchu użytkowego nadal są wymagane.

W połączeniach chmurowych wartości nie wybiera się dowolnie:

Dla AWS Site-to-Site VPN adresy Inside Tunnel, Remote AS i pozostałe wartości tunelu pochodzą z konfiguracji AWS. Oba tunele AWS sprawdza się osobno.
Przy Azure VPN Gateway lokalny adres XFRM musi odpowiadać przewidzianemu adresowi peera BGP; lokalny ASN i ASN Azure muszą być różne.

Zielony tunel IPsec i BGP Neighbor ze stanem Established to dwa oddzielne punkty kontroli. Następnie muszą działać oczekiwane prefiksy i rzeczywisty ruch aplikacyjny.

Systematyczna diagnostyka błędów

Neighbor pozostaje w Active albo nie jest wyświetlany

Active nie oznacza, że sesja aktywnie działa. Zapora nadal próbuje nawiązać połączenie BGP. Najpierw należy sprawdzić bezpośrednią osiągalność adresu peera, stan interfejsu i tunelu, Local AS, Remote AS oraz adres Neighbor. Następnie trzeba zweryfikować, czy Dynamic Routing jest dozwolony we właściwej strefie lub przez odpowiednią regułę Local Service ACL Exception.

W przypadku XFRM należy również upewnić się, że oba adresy tunelu są prawidłowe, a tunel IPsec jest up. W projektach cloud i XFRM sprawdza się także reguły przewidziane w danym projekcie VPN. Jeśli ich Services są ograniczone, muszą obejmować TCP 179 między oboma adresami IP peerów. Device Access albo Local Service ACL dla lokalnej usługi BGP pozostaje od tego oddzielony.

Neighbor ma stan Established, ale brakuje zdalnej sieci

Sesja działa, ale prefiks nie jest ogłaszany lub akceptowany. Na wysyłającej zaporze należy sprawdzić wpis Network, jego wersję IP i maskę prefiksu oraz show running-config. Następnie na peerze, w sekcjach Routes i Summary, trzeba sprawdzić, czy prefiks dociera, czy jest odrzucany przez politykę lub filtr.

Jeżeli po aktualizacji do SFOS 22 brakuje sieci za tunelem policy-based IPsec, przyczyną może być wcześniejsza zależność od redistribute kernel. Sesja BGP może mimo to pozostać w stanie Established; artykuł SFOS 22: trasy IPsec i redistribute kernel wyjaśnia zmianę wersji i docelowy projekt route-based XFRM.

Trasa BGP jest widoczna, ale nie jest używana

Najpierw za pomocą Route Lookup należy sprawdzić, która trasa wygrywa dla konkretnego docelowego adresu IP. Trasa bardziej szczegółowa ma pierwszeństwo przed szerszym prefiksem. Jeśli konkurują różne źródła, osobno ocenia się Administrative Distance, atrybuty BGP, a dopiero potem globalną kategorię Route Precedence.

Trasa jest prawidłowa, ale ruch nie działa

BGP wykonał swoje zadanie, gdy poprawna trasa została zainstalowana. Późniejsze błędy zwykle dotyczą reguły firewall, NAT, ścieżki powrotnej lub systemu docelowego. W normalnie routowanych sieciach między lokalizacjami często nie jest potrzebny SNAT, ponieważ obie strony powinny znać rzeczywiste prefiksy LAN.

Ustawienia zaawansowane zniknęły po edycji w WebAdmin

WebAdmin pokazuje tylko wartości podstawowe. Jeśli Neighbor został tam zapisany po zaawansowanej konfiguracji CLI, mogły zostać usunięte hasło, Route Map lub zmienione wartości domyślne. Zastosowanie Global configuration usuwa również zmiany w bgp log-neighbor-changes i no bgp ebgp-requires-policy. Należy porównać zapisany stan, przywrócić wartości przez CLI i zapisać je poleceniem write.

Przyporządkowanie logów BGP i routingu

Dokumentacja logów SFOS 22 przypisuje BGP i BGPv6 do pliku bgpd.log. Plik zebra.log dotyczy instalowania dynamicznych tras IPv4 i IPv6 w jądrze, a w przypadku route-based IPsec plik xfrmi.log dotyczy interfejsu tunelowego XFRM. Pozwala to rozdzielić klasy błędów: najpierw należy sprawdzić sesję BGP i ogłoszenie, następnie wprowadzenie trasy do systemowej tablicy routingu, a w razie potrzeby także stan tunelu. Usługi i pliki logów Sophos Firewall wyjaśniają sposób dostępu i opisują dodatkowe pliki. Do tej weryfikacji nie są potrzebne nieudokumentowane polecenia live shell.

Bezpieczne wycofanie zmiany

Przed usunięciem BGP dla każdej poznanej sieci docelowej musi istnieć alternatywna ścieżka albo okno serwisowe. Najpierw usuwa się odpowiednie Networks i Neighbors, a konfigurację globalną BGP zmienia tylko wtedy, gdy nie zależą od niej inne peery. Dynamic Routing można wyłączyć dopiero wtedy, gdy strefa nie potrzebuje już żadnej innej usługi routingu dynamicznego.

W WebAdmin należy najpierw usunąć zbędne ogłoszenia w Routing > BGP > Networks, a następnie odpowiednich peerów w Neighbors. Po każdym kroku trzeba sprawdzić, czy oczekiwane trasy zastępcze są aktywne. Router ID i Local AS powinny pozostać bez zmian, dopóki zależą od nich inne połączenia BGP; zmiana Local AS usunęłaby wszystkie pozostałe Neighbors i Networks.

Przeglądane strony ogólne BGP dla SFOS 22 i 23 pokazują składnię wyłączania konfiguracji routingu BGP. Nie potwierdza to jednak pełnego kontekstu wykonania ani bezpiecznego wycofania dla zainstalowanej kompilacji. Nietypowa składnia źródłowa nie jest publikowana jako wykonywalne polecenie ani po cichu poprawiana; nie wyprowadza się z niej potwierdzonego zatrzymania demona lub usunięcia procesu. Nie zaleca się destrukcyjnego polecenia CLI. Przed wycofaniem zaawansowanych polityk CLI potrzebne są polecenia usuwające potwierdzone dla zainstalowanej kompilacji oraz zapisany blok wcześniejszej konfiguracji.

Następnie ponownie sprawdza się Routing Information, Route Lookup, dostęp administracyjny i rzeczywisty ruch. Rollback jest zakończony dopiero wtedy, gdy nie tylko zniknęła sesja BGP, ale wszystkie potrzebne sieci docelowe nadal są osiągalne przez przewidzianą ścieżkę zastępczą.