Połączenie Sophos Firewall z AWS Site-to-Site VPN

AWS Site-to-Site VPN łączy lokalną sieć za Sophos Firewall z AWS VPC albo Transit Gateway. Technicznie jest to VPN IPsec, ale operacyjnie różni się od zwykłego tunelu Sophos-to-Sophos: AWS tworzy dwa tunele dla jednego połączenia VPN, używa obiektów Customer Gateway i bramy docelowej, a routing mocno zależy od wyboru tras statycznych albo BGP.

Ten artykuł opisuje praktyczną konfigurację Sophos Firewall z AWS. Uzupełnia ogólną instrukcję Konfiguracja Sophos Firewall Site-to-Site IPsec VPN o elementy specyficzne dla AWS: dwa tunele, sąsiadów BGP, route tables, security groups, NACLs oraz kontrolę statusu w AWS i Sophos. Jeżeli tunel jest już zestawiony, ale ruch nie przechodzi, lepszym kolejnym krokiem jest Troubleshooting Sophos Firewall IPsec VPN.

Kiedy ten artykuł pasuje

Artykuł pasuje, gdy oddział, centrum danych albo lokalna sieć ma zostać połączona z AWS przez Sophos Firewall. Obejmuje AWS Site-to-Site VPN do VPC, Virtual Private Gateway albo Transit Gateway. Nie opisuje Sophos Firewall jako appliance wirtualnego uruchomionego bezpośrednio w AWS.

Typowe scenariusze:

lokalna sieć serwerowa do instancji EC2 w VPC
ruch backupu, monitoringu albo zarządzania do AWS
hybrydowy DNS, AD, jump hosty albo sieci administracyjne
migracja ze statycznego VPN do dynamicznego routingu BGP
redundantna praca z dwoma tunelami AWS

AWS i Sophos używają różnych pojęć. W AWS pracuje się z Customer Gateway, Virtual Private Gateway albo Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups i Network ACLs. Na Sophos Firewall istotne są połączenia Amazon VPC, profile IPsec, interfejsy XFRM, BGP, trasy i reguły firewall.

Planowanie przed konfiguracją

AWS Site-to-Site VPN nie powinno być traktowane jako samo zaimportowanie pobranego przykładowego pliku. Plik AWS jest pomocny, ale produkcyjna akceptacja zależy od routingu, security groups, NACLs, reguł firewall oraz testów z rzeczywistym ruchem.

Ustalić sieci i bramę docelową

Najpierw trzeba zdecydować, która strona AWS będzie używana:

Virtual Private Gateway dla klasycznej pojedynczej VPC.
Transit Gateway dla wielu VPC, wielu lokalizacji albo większego projektu routingu.
Cloud WAN albo inne warianty tylko wtedy, gdy architektura AWS świadomie tego wymaga.

Wcześniej udokumentować:

AWS VPC CIDR, na przykład 10.60.0.0/16
istotne AWS subnets i route tables
lokalne sieci za Sophos Firewall, na przykład 172.16.20.0/24
publiczny adres IP Sophos Firewall albo routera upstream
tryb routingu: static albo dynamic BGP
lokalny i AWS ASN, jeżeli używany jest BGP
oczekiwane cele testowe po obu stronach
planowane tunnel options, wersję IKE, preshared keys i lifetimes

Nakładające się sieci należy uporządkować przed projektem VPN. NAT over IPsec może działać, ale utrudnia route tables, security groups, logi i późniejsze troubleshooting.

Traktować oba tunele poważnie

AWS tworzy dwa tunele dla każdej Site-to-Site VPN connection, każdy z innym endpointem AWS. Oba tunele powinny być skonfigurowane i sprawdzone na Sophos Firewall. Jeden tunel jest wygodny w laboratorium, ale w produkcji rezygnuje się wtedy z redundancji AWS.

Ważne jest właściwe oczekiwanie: ścieżka zwrotna z AWS preferuje jeden tunel zależnie od routingu i strony AWS, a w razie awarii może przełączyć się na drugi. Nie oznacza to, że oba tunele zawsze są wykorzystywane równomiernie. Liczy się to, aby oba tunele się zestawiały, BGP albo trasy statyczne były poprawne, a failover został przetestowany.

Routing statyczny albo BGP

AWS Site-to-Site VPN obsługuje trasy statyczne i dynamiczny routing z BGP. BGP jest zwykle lepszy przy wielu prefiksach, przyszłej rozbudowie albo Transit Gateway. Trasy statyczne są prostsze, ale każda zmiana sieci wymaga ręcznej aktualizacji.

W praktyce:

BGP wymaga zgodnych wartości ASN po obu stronach.
Sophos Firewall musi ogłaszać właściwe lokalne prefiksy.
AWS route tables muszą faktycznie używać tras propagowanych albo statycznych.
Security groups i NACLs również muszą zezwalać na ruch.
Identyczne trasy statyczne i BGP mogą powodować nieoczekiwane priorytety.

Przygotowanie AWS

Poniższe kroki opisują typowy przebieg. Szczegóły różnią się między Virtual Private Gateway i Transit Gateway, ale zasada pozostaje taka sama.

Utworzyć Customer Gateway

Customer Gateway opisuje lokalną stronę Sophos w AWS.

Wprowadzić:

Ustawić Name tag, na przykład cgw-sophos-hq.
Wybrać routing: statyczny albo dynamiczny.
Wprowadzić publiczny adres IP strony Sophos.
Dla BGP wprowadzić lokalny ASN Sophos.
Utworzyć zasób i zachować spójne tagowanie.

Jeżeli Sophos Firewall znajduje się za routerem albo urządzeniem operatora, musi być jasne, jaki publiczny IP widzi AWS i czy NAT-T działa poprawnie. IP wpisany w AWS musi odpowiadać rzeczywistej negocjacji tunelu.

Utworzyć albo wybrać bramę docelową

Dla jednej VPC zwykle tworzy się Virtual Private Gateway i dołącza go do VPC. Większe środowiska AWS często używają Transit Gateway.

Sprawdzić:

Brama jest dołączona do właściwej VPC albo Transit Gateway.
ASN po stronie AWS nie koliduje z ASN Sophos.
Route tables VPC albo Transit Gateway są zaplanowane.
Subnety używane do testów korzystają z właściwej route table.

Utworzyć Site-to-Site VPN connection

Następnie w AWS tworzy się Site-to-Site VPN connection.

Ważne punkty:

Wybrać właściwy target gateway type.
Wybrać Customer Gateway.
Ustawić Routing Options na static albo dynamic.
Przy routingu statycznym wprowadzić lokalne prefiksy.
Świadomie sprawdzić Tunnel Options, szczególnie IKE version, encryption, integrity, DH/PFS i DPD.
Udokumentować preshared keys dla każdego tunelu albo świadomie pozwolić AWS je wygenerować.

Po utworzeniu należy pobrać plik konfiguracyjny. Jako Vendor można wybrać Sophos, Platform Sophos Firewall i odpowiednią wersję software. Plik jest dobrym punktem startowym, ale nie zastępuje technicznego przeglądu opcji tunelu.

Sprawdzić route tables, security groups i NACLs

Zielony tunel VPN w AWS nie oznacza jeszcze, że instancja EC2 jest osiągalna.

Do walidacji sprawdzić:

VPC route table zawiera trasę do lokalnej sieci przez Virtual Private Gateway albo Transit Gateway.
Przy Virtual Private Gateway route propagation jest włączone albo trasa jest ustawiona statycznie.
Transit Gateway route tables zawierają właściwe attachments i propagations.
Security group instancji docelowej zezwala na wymagany ruch z lokalnej sieci.
Network ACLs zezwalają na ruch w obie strony.
Firewall systemu operacyjnego instancji nie blokuje testu.

Ten etap jest często pomijany, ponieważ Sophos i AWS mogą pokazywać połączony tunel, mimo że instancja nie odpowiada z powodu security group albo trasy zwrotnej.

Konfiguracja Sophos Firewall

Sophos oferuje dla AWS dwie praktyczne ścieżki: import przez Site-to-site VPN > Amazon VPC albo ręczną konfigurację jako route-based IPsec. W wielu wdrożeniach AWS import jest najczystszym początkiem, ale automatycznie utworzone obiekty nadal trzeba sprawdzić.

Zaimportować konfigurację AWS

Sophos Firewall może zaimportować połączenie Amazon VPC z pobranego pliku konfiguracyjnego AWS.

Kroki:

Otworzyć Sophos Firewall.
Przejść do Site-to-site VPN > Amazon VPC.
Wybrać Use VPC configuration file.
Wgrać plik konfiguracyjny AWS.
Uruchomić import.
Sprawdzić utworzone połączenia, profile IPsec, interfejsy XFRM i ustawienia BGP.

Jeżeli firewall znajduje się za urządzeniem NAT, plik konfiguracyjny albo wynikową konfigurację Sophos trzeba sprawdzić szczególnie dokładnie. Sophos wskazuje, że plik zawiera wartości per tunel i oba tunele muszą zostać uwzględnione.

Sprawdzić profil IPsec i tunele

Po imporcie albo przy konfiguracji ręcznej nie należy ślepo ufać samemu statusowi.

Sprawdzić:

Istnieją oba tunele AWS.
Wersja IKE pasuje do konfiguracji AWS.
Encryption, authentication, DH group, PFS i lifetimes pasują dla każdego tunelu.
Preshared key jest poprawny dla każdego tunelu.
Gateway type i remote gateway wskazują odpowiednie endpointy tuneli AWS.
Interfejsy XFRM istnieją i mają czytelne nazwy.

Jeżeli opcje tunelu AWS zostaną później zmienione, strona Sophos musi zostać dopasowana. Jednostronne zmiany często powodują błędy phase 1 albo phase 2.

Skonfigurować BGP albo trasy statyczne

Przy BGP w Routing > BGP sprawdza się lokalny ASN, neighbor, remote ASN i ogłaszane sieci. W Routing > Information > BGP Neighbors, Summary i Routes powinny pokazywać oczekiwane wartości.

Przy routingu statycznym trasy do sieci AWS muszą wskazywać właściwy interfejs XFRM. AWS również musi znać lokalne prefiksy, przez statyczne trasy VPN albo właściwą route table.

W obu wariantach routing musi działać w obie strony. Tunel może być połączony, mimo że ścieżka zwrotna wychodzi przez internet, NAT Gateway albo złą route table.

Utworzyć reguły firewall

Route-based IPsec nie tworzy automatycznie reguł firewall wystarczająco dobrych dla produkcji. Reguły należy tworzyć i logować świadomie.

Zalecane:

Utworzyć regułę z lokalnej sieci do celów AWS.
Kierunek przeciwny zezwolić tylko wtedy, gdy AWS musi aktywnie osiągać lokalne systemy.
Ściśle ograniczyć source, destination i services.
Włączyć logging do walidacji.
Sprawdzić pozycję reguły przed ogólnymi regułami drop albo catch-all.

Jeżeli oczekiwana reguła nie pasuje, pomaga Reguła Sophos Firewall nie pasuje: jak znaleźć przyczynę.

Sprawdzenie połączenia

Walidacja powinna zawsze obejmować obie platformy i rzeczywisty ruch aplikacyjny. Sam zielony status tunelu nie wystarczy.

Sprawdzić AWS

W AWS sprawdzić:

VPC > Site-to-Site VPN Connections > Tunnel Details pokazuje oba tunele.
Status tunelu to UP.
Przy BGP trasy są widoczne.
VPC albo Transit Gateway route table zawiera oczekiwane trasy.
Security groups i NACLs zezwalają na test.
CloudWatch metrics albo VPN logs nie pokazują powtarzających się problemów IKE lub DPD.

Sprawdzić Sophos Firewall

Na Sophos Firewall sprawdzić:

Site-to-site VPN > Amazon VPC albo Site-to-site VPN > IPsec pokazuje aktywne tunele.
Routing > Information > BGP pokazuje sąsiadów i nauczone trasy, jeśli używany jest BGP.
Network > Interfaces pokazuje interfejsy XFRM.
Log Viewer pokazuje oczekiwaną regułę firewall.
Packet Capture potwierdza interfejs wejściowy i wyjściowy, jeśli logi nie wystarczają.

Dobrze wybrać ruch testowy

Test powinien używać konkretnego hosta źródłowego, hosta docelowego i usługi, na przykład ICMP, RDP, SSH, HTTPS albo DNS. Jeżeli ICMP jest blokowany, ping nie jest miarodajny. Lepszy jest test usługi, która będzie faktycznie używana.

Typowe błędy

Błędy AWS VPN często wyglądają jak problemy IPsec, choć przyczyną jest routing albo kontrolki bezpieczeństwa AWS. Poniższe przypadki są szczególnie częste.

Aktywny jest tylko jeden tunel

Jeden tunel wystarczy do pierwszego testu, ale nie do poprawnej pracy produkcyjnej. Oba tunele AWS mają własne endpointy i parametry. Dla każdego tunelu sprawdzić preshared key, parametry IKE/IPsec, interfejs XFRM, sąsiada BGP i status AWS.

BGP nie zestawia się

Jeśli tunel jest połączony, ale BGP nie tworzy peeringu, najpierw sprawdzić ASN, IP sąsiada, lokalne ogłoszenia i adresy inside tunnel. Sophos dokumentuje także przypadki, gdy peering BGP nie powstaje automatycznie, mimo że tunel AWS VPC jest połączony.

Tunel zielony, instancja nieosiągalna

Przyczyna często leży poza IPsec: zła AWS route table, brak route propagation, security group, NACL, firewall systemu operacyjnego, zła sieć źródłowa albo brakująca reguła Sophos.

Ścieżka zwrotna idzie źle

AWS musi znać ścieżkę zwrotną do lokalnej sieci przez VPN. Lokalnie powrót do AWS VPC musi iść przez XFRM albo BGP. Routing asymetryczny może wyglądać normalnie w statusie tunelu, ale zrywać realne sesje.

MTU albo fragmentacja psują aplikacje

AWS Site-to-Site VPN i narzut IPsec mogą ujawnić problemy MTU. Jeżeli małe testy działają, ale większe transfery albo konkretne aplikacje wiszą, należy sprawdzić MSS/MTU, fragmentację i packet captures.

Operacje i przegląd

Po uruchomieniu tunel powinien trafić do normalnego procesu operacyjnego. Obejmuje to właściciela, udokumentowany proces preshared-key, okno zmian dla parametrów IPsec, monitoring tuneli, regularne testy failover i jasny proces dla zmian AWS albo ISP.

Przy każdej zmianie VPC CIDR, routingu Transit Gateway, route tables, security groups, lokalnych sieci albo ogłoszeń BGP należy powtórzyć walidację VPN. Cloud VPN nie jest jednorazowym kliknięciem, tylko częścią architektury sieci.

FAQ

Czy AWS Site-to-Site VPN z Sophos Firewall powinien używać BGP czy routingu statycznego?

BGP jest zwykle lepszy dla dynamicznych albo rosnących środowisk. Trasy statyczne są prostsze, ale każdą zmianę sieci trzeba ręcznie utrzymywać w AWS i na Sophos Firewall.

Czy trzeba skonfigurować oba tunele AWS na Sophos Firewall?

Tak, w produkcji oba tunele powinny być skonfigurowane i przetestowane. AWS tworzy dwa tunele dla redundancji. Użycie tylko jednego zmniejsza dostępność.

Dlaczego tunel AWS jest zielony, ale instancja EC2 jest nieosiągalna?

Najczęściej nie brakuje IPsec, lecz routingu albo zezwoleń w AWS. Sprawdzić route tables, route propagation, security groups, NACLs i firewall systemu operacyjnego instancji.

Czy Sophos Firewall może być za NAT?

Może działać, jeśli NAT-T i publiczny adres są obsłużone poprawnie. Przy importowanych plikach AWS trzeba sprawdzić, jaki adres tunelu jest w pliku i jaki adres AWS faktycznie widzi.

Czy pobrany plik konfiguracyjny AWS wystarczy?

Nie. Plik konfiguracyjny jest dobrym początkiem, ale nadal trzeba sprawdzić tunnel options, BGP, interfejsy XFRM, route tables, security groups, reguły firewall i testy.