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.
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 bezpośrednio osiągalny adres IP peera, z którym nawiązywana jest sesja BGP.
Network to lokalny prefiks, który zapora ma ogłaszać stronie zdalnej.

BGP nie zezwala na ruch użytkowy ani go nie szyfruje. Sama sesja BGP jest zestawiana przez TCP 179 i udostępniana do zapory przez Device Access albo Local Service ACL. Ruch użytkowy przez poznaną trasę nadal wymaga odpowiednich reguł firewall, działającej ścieżki powrotnej i, 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ą.
Ogłaszane sieci istnieją już jako odpowiednie trasy w lokalnej tablicy routingu.
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 wąskiej sieci tranzytowej jest bezpieczniejsza niż szerokie zezwolenie dla całej strefy. W Administration > Device access > Local service ACL exception rule > Add tworzy się w tym celu regułę Accept dla strefy peera, konkretnego adresu IP peera lub wąskiej sieci tranzytowej, wymaganego adresu zapory i usługi Dynamic Routing. Następnie należy przetestować dostęp z dozwolonego adresu IP peera oraz z niedozwolonego źródła.

Device Access steruje tylko połączeniem BGP do zapory. Produktywne połączenia między oboma LAN-ami nadal wymagają zwykłych reguł firewall. To rozdzielenie wyjaśnia artykuł Zabezpieczanie Device Access na Sophos Firewall.

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).

Network nie tworzy trasy. Prefiks musi już występować dokładnie w lokalnej tablicy routingu, na przykład jako sieć bezpośrednio połączona albo trasa statyczna. Jeśli go brakuje lub maska się nie zgadza, sesja BGP może mieć stan Established, ale Network nie zostanie ogłoszony.

Należy wprowadzać wyłącznie rzeczywiście potrzebne prefiksy. Ogólna redystrybucja tras bezpośrednio połączonych lub statycznych może objąć także sieci WAN, zarządzające lub Blackhole i nadaje się do produkcji tylko z przetestowanym filtrowaniem.

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 BGP. Poniższych poleceń nie wykonuje się dodatkowo w już w pełni skonfigurowanym środowisku przykładowym. Ścieżka menu brzmi:

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

Pełny przykład na Firewall A wygląda następująco:

enable
configure terminal
router bgp 65010
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
show running-config
write
end

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.

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.

Route Precedence i wybór ścieżki BGP

system route_precedence nie decyduje między BGP a trasą statyczną. Ustawienie globalne porządkuje jedynie kategorie static, sdwan_policyroute i vpn; BGP i inne trasy dynamiczne należą przy tym do kategorii static.

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.

Aktualną kolejność globalną można wyświetlić w 4. Device Console:

system route_precedence show

Należy ją zmieniać tylko wtedy, gdy rzeczywiście konkurują różne kategorie routingu. Zależności i bezpieczne przykłady wyjaśnia artykuł Zmiana priorytetu routingu na Sophos Firewall.

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 albo akceptowany. Na zaporze wysyłającej Network z dokładnie tą samą maską musi istnieć w lokalnej tablicy routingu. Następnie należy sprawdzić Networks, filtry i show running-config. Brakującą trasę lokalną trzeba naprawić, a nie ukrywać przez wyłączenie BGP Network Import Check.

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. Należy porównać zapisany stan, przywrócić wartości przez CLI i zapisać je poleceniem write.

Kontrola logów BGP i routingu

W 5. Device Management > 3. Advanced Shell dwa pliki logów pokazują różne poziomy:

tail -f /log/bgpd.log

bgpd.log rejestruje zdarzenia BGP i BGPv6. Bieżące wyjście zatrzymuje się kombinacją Ctrl+C. Jeśli BGP zna trasę, ale nie pojawia się ona w systemie, należy sprawdzić:

tail -f /log/zebra.log

Do odczytu bez śledzenia na żywo można użyć na przykład:

less /log/bgpd.log

Przy route-based IPsec plik /log/xfrmi.log może dodatkowo wyjaśnić stan interfejsu XFRM. Przypisanie pozostałych plików znajduje się w artykule Usługi i pliki logów Sophos Firewall.

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.

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ą.