Konfiguracja VPN IPsec Site-to-Site Sophos Firewall

VPN IPsec Site-to-Site łączy dwie lokalizacje albo Sophos Firewall z firewallem innego dostawcy przez szyfrowany tunel. W praktyce taki tunel rzadko przestaje działać z powodu jednego ustawienia w interfejsie. Częściej przyczyną są niejasne sieci, różne profile IPsec, brakujące reguły firewall, szczególne przypadki NAT albo zapomniana ścieżka powrotna po jednej stronie.

Ten artykuł wyjaśnia, jak poprawnie zbudować tunel IPsec Site-to-Site na Sophos Firewall. Skupia się na planowaniu, wdrożeniu i teście odbiorczym. Jeśli istniejący tunel jest już zielony, ale ruch nie przepływa, lepszym artykułem uzupełniającym jest Sophos Firewall IPsec VPN Troubleshooting.

Kiedy ten artykuł pasuje

Artykuł pasuje do klasycznych połączeń między lokalizacjami, na przykład:

• Centrala z oddziałem
• Sophos Firewall z Sophos Firewall
• Sophos Firewall z firewallem innego dostawcy
• Sophos Firewall z cloud gateway, gdy nie jest używany specjalny asystent cloud
• Migracja prostych starych tuneli policy-based do udokumentowanej aktualnej konfiguracji

Nie chodzi tu o Remote Access dla pojedynczych użytkowników. Do tego pasują artykuły Konfiguracja Sophos Connect na Sophos Firewall, Sophos Connect czy SSL VPN: które rozwiązanie Remote Access pasuje? oraz Migracja legacy Remote Access IPsec przed SFOS 22 MR1.

IPsec policy-based czy route-based

Przed konfiguracją trzeba zdecydować, czy tunel ma być zbudowany jako policy-based, czy route-based. W aktualnych wersjach SFOS te pojęcia są rozdzielone wyraźniej niż w starszych instrukcjach, które częściowo nadal mówią o Site-to-Site albo Tunnel Interface.

Dla małych, stabilnych połączeń policy-based IPsec jest często najszybszy do zrozumienia. Dla większych albo dynamicznych sieci lokalizacji route-based IPsec jest zwykle czystszy, ponieważ lepiej rozdziela routing i negocjację VPN. Jeśli uczestniczy wiele sieci, SD-WAN, BGP, OSPF albo sieci cloud, najpierw należy sprawdzić route-based IPsec.

Wymagania

Przed konfiguracją należy udokumentować te informacje:

⚠️ VPN Site-to-Site nie powinien być wdrażany bez udokumentowanej ścieżki powrotnej. Jeśli lokalny firewall wysyła ruch do tunelu, ale strona zdalna nie zna trasy powrotnej albo inaczej oczekuje NAT, tunel często wygląda zdrowo, mimo że aplikacje nie działają.

Planowanie przed konfiguracją

Utrzymać jednoznaczne sieci

Sieci lokalne i zdalne nie mogą przypadkowo się nakładać. Szczególnie problematyczne są częste sieci domyślne, takie jak 192.168.0.0/24, 192.168.1.0/24 albo wielokrotnie używane sieci oddziałów. Jeśli sieci się nakładają, potrzebny jest świadomy projekt NAT. Użycie tego samego zakresu adresów po obu stronach i późniejsze tłumaczenie go “jakoś” tworzy tunele trudne w utrzymaniu.

Dla nowych lokalizacji warto więc przygotować czystą koncepcję adresacji IP. Jeśli VLANs albo zones nie są jeszcze dobrze zamodelowane, pomaga konfiguracja zones i interfaces w Sophos Firewall.

Uzgodnić profil IPsec

Obie strony muszą używać zgodnych parametrów w Phase 1 i Phase 2. Należą do nich szyfrowanie, uwierzytelnianie, DH group, PFS i czas życia. Przy połączeniach z firewallami innych dostawców najłatwiej często najpierw zapisać wspólny profil na piśmie, a dopiero potem skonfigurować obie strony.

Jeśli tunel się nie zestawia, typowymi wskazówkami są NO_PROPOSAL_CHOSEN, błędy ID albo błędy uwierzytelniania. Ustrukturyzowana analiza znajduje się w Sophos Firewall IPsec VPN Troubleshooting.

Nie zapomnieć o regułach firewall

Tunel IPsec sam w sobie nie daje jeszcze dostępu produkcyjnego. Ruch przez tunel nadal wymaga odpowiednich reguł firewall. Przy połączeniach policy-based są to najczęściej reguły między LAN i VPN albo między własnymi zones. Przy projektach route-based zależy to od tego, do której zone przypisany jest interfejs XFRM albo właściwa ścieżka.

Podczas wdrożenia należy włączyć Log firewall traffic w odpowiednich regułach. W przeciwnym razie później zabraknie dokładnie tej informacji, która reguła dopuściła albo zablokowała test. Ogólny przebieg kontroli opisuje test reguły firewall z Log Viewer, Policy Test i Packet Capture.

Świadomie sprawdzić reguły utworzone automatycznie

Podczas tworzenia połączenia IPsec Site-to-Site opcja Create firewall rule może pomóc utworzyć pierwszy zestaw reguł. Nie zastępuje to jednak kontroli bezpieczeństwa. Sophos Firewall tworzy te reguły na samej górze listy reguł firewall. W aktualnych wersjach SFOS powstają osobne reguły dla ruchu przychodzącego i wychodzącego z prefiksami Incoming i Outgoing.

Dla eksploatacji ważne jest więc:

⚠️ Automatycznie utworzone reguły firewall są punktem startowym, a nie gotowym projektem bezpieczeństwa. Szczególnie przy tunelach lokalizacji do sieci serwerowych po pierwszym teście należy ograniczyć usługi, źródła i cele.

Przy route-based IPsec z subnetami Any-to-Any trzeba pracować szczególnie dokładnie. Dla takich projektów route-based nie można tworzyć automatycznych reguł firewall. Przy wersjach dual IP reguły IPv4 i IPv6 należy planować oddzielnie. W tych scenariuszach reguły firewall, interfejs XFRM, trasy i testy powinny być świadomie zbudowane ręcznie.

Konfiguracja IPsec policy-based

Policy-based IPsec to klasyczny wariant dla prostych połączeń Site-to-Site. Sieci lokalne i zdalne są definiowane bezpośrednio w połączeniu IPsec.

1. Sprawdzić albo utworzyć profil IPsec

Menu path:

Profiles > IPsec profiles

Najpierw sprawdzić, czy istniejący profil pasuje do strony zdalnej. Jeśli potrzebny jest własny profil, powinien mieć jednoznaczną nazwę, na przykład IPsec_IKEv2_AES256_G14. Nazwa musi pozostać zrozumiała później, gdy istnieje wiele tuneli i stron zdalnych.

Udokumentować co najmniej:

• Wersja IKE
• Phase 1 Encryption i Authentication
• DH Group
• Phase 2 Encryption i Authentication
• PFS
• Key lifetime

Przy firewallach innych dostawców strona zdalna powinna potwierdzić te same wartości na piśmie. Sam zrzut ekranu często nie wystarcza, bo poszczególne pola mogą mieć inne nazwy zależnie od producenta.

2. Dodać połączenie IPsec

Menu path:

Site-to-site VPN > IPsec

Utworzyć nowe połączenie IPsec i jako Connection type wybrać Policy-based. Następnie ustawić dane podstawowe:

• Nazwa tunelu, na przykład branch-zurich
• Local gateway albo Listening interface
• Remote Gateway jako adres IP albo FQDN
• Authentication type: Preshared Key albo certyfikat
• Local ID i Remote ID, jeśli potrzebne
• IPsec profile
• Local subnet
• Remote subnet

Dla Preshared Keys należy użyć silnego, unikalnego klucza i bezpiecznie go udokumentować. Współdzielony stary standardowy klucz używany w kilku lokalizacjach to niepotrzebne ryzyko operacyjne.

3. Aktywować tunel

Podczas zapisu można ustawić Activate on save. W środowiskach produkcyjnych powinno to nastąpić w zdefiniowanym oknie serwisowym, gdy strona zdalna jest osiągalna i obie strony mogą sprawdzać logi.

Po zapisaniu lista pokazuje dwa istotne stany:

• czy połączenie jest aktywne
• czy tunel faktycznie jest established

Aktywny wpis nie oznacza automatycznie zestawionego tunelu. Przy wielu sieciach lokalnych albo zdalnych może też istnieć wiele Security Associations.

Konfiguracja IPsec route-based

Route-based IPsec wyraźniej rozdziela negocjację VPN i routing. Sophos Firewall tworzy przy tym interfejs XFRM. Następnie trasy statyczne, SD-WAN Routes albo routing dynamiczny decydują, który ruch przechodzi przez tunel.

1. Utworzyć połączenie jako route-based

Menu path:

Site-to-site VPN > IPsec

W połączeniu wybrać Route-based (Tunnel interface). Parametry gateway, uwierzytelniania, IDs i profilu IPsec nadal muszą pasować do strony zdalnej. Dodatkowo trzeba rozumieć, jaki interfejs XFRM powstanie później i jak będzie routowany.

Sophos pokazuje wygenerowany interfejs XFRM pod użytym interfejsem fizycznym w:

Network > Interfaces

Zależnie od projektu interfejs XFRM potrzebuje adresu IP. Szczególnie przy projektach Any-to-Any, wersji dual IP albo bardziej złożonych scenariuszach routingu adresacja interfejsu powinna być starannie zaplanowana.

Gdy używa się Any-to-Any, sam Tunnel Selector nie decyduje już, który ruch przechodzi przez tunel. Wtedy trasy i reguły firewall stają się centralnym sterowaniem. To elastyczne, ale też podatne na błędy: zbyt szeroka reguła może dopuścić więcej ruchu niż planowano, a brakująca trasa może pokazywać tunel jako zielony bez przepływu ruchu użytkowego.

2. Ustawić routing

Przy VPN route-based samo połączenie IPsec nie wystarcza. Potrzebna jest trasa do sieci zdalnej:

• trasa statyczna do interfejsu XFRM
• SD-WAN Route z odpowiednim gateway albo profilem
• trasa dynamiczna przez BGP albo OSPF, jeśli projekt jest do tego zbudowany

Dla prostych konfiguracji trasa statyczna często wystarcza. Jeśli używa się wielu łączy WAN, kontroli SLA albo ścieżek failover, sensowniejsza jest SD-WAN Route. Ogólny kontekst SD-WAN, Reply Packets i ruchu generowanego przez system opisuje sprawdzenie routingu SD-WAN Sophos Firewall dla Reply Packets i System Traffic.

3. Uwzględnić XFRM i MTU

VPN route-based są bardziej podatne na nieporozumienia związane z routingiem, MTU i MSS. Jeśli małe testy działają, ale większe transfery się zawieszają, nie należy od razu zmieniać profilu IPsec. Najpierw trzeba sprawdzić MTU, MSS, fragmentację i rzeczywistą ścieżkę. Odpowiedni przebieg opisuje sprawdzenie MTU i MSS w Sophos Firewall przy problemach VPN.

Tworzenie reguł firewall

Po konfiguracji IPsec potrzebne są reguły dla ruchu produkcyjnego. Bez odpowiednich reguł tunel może być zielony, ale aplikacje nie będą działać.

Menu path:

Rules and policies > Firewall rules

Typowe reguły:

Dobra praktyka:

• Nazwa reguły z tunelem albo lokalizacją, na przykład LAN_to_Branch_Zurich.
• Ustawić Source i Destination możliwie wąsko.
• Konkretnie zdefiniować Services.
• Włączyć logging podczas wdrożenia i troubleshooting.
• Sprawdzić pozycję reguły.
• Funkcje ochronne ustawić świadomie, zamiast przejmować je przypadkowo.

Jeśli ruch internetowy oddziału ma przechodzić przez centralę, potrzebna jest dodatkowo świadoma koncepcja NAT i bezpieczeństwa. To inny projekt niż proste połączenie lokalizacji dla sieci wewnętrznych.

Świadomie zaplanować NAT

NAT nie jest zabroniony przy IPsec, ale musi być jasno uzasadniony. Typowe przypadki to nakładające się sieci, wymagania cloud albo strony trzecie akceptujące tylko określone adresy źródłowe.

Menu path:

Rules and policies > NAT rules

Przed regułą NAT należy odpowiedzieć na te pytania:

• Czy strona zdalna oczekuje oryginalnych adresów IP czy adresów tłumaczonych?
• Czy istnieją nakładające się sieci?
• Czy NAT jest rozwiązany w połączeniu IPsec czy przez oddzielne reguły NAT?
• Czy kierunek powrotny jest udokumentowany?
• Czy Log Viewer pokazuje po NAT oczekiwane Source i Destination?

Dla szczególnych przypadków policy-based z NAT może być istotna ręczna IPsec Route na Sophos Firewall. Nie jest to jednak standardowy krok dla każdego tunelu.

Device Access i dostęp WAN

Dla przychodzących zapytań IPsec firewall musi móc przyjmować ruch IPsec na właściwej zone WAN. Nie rozwiązuje się tego zwykłą regułą LAN-to-WAN, lecz przez lokalne usługi firewalla.

Menu path:

Administration > Device access

Tam IPsec musi być dozwolony dla wymaganej zone. Jednocześnie należy sprawdzić, czy inne lokalne usługi, takie jak WebAdmin, SSH, User Portal albo VPN Portal, nie są osiągalne zbyt szeroko. Do utwardzenia tych lokalnych usług centralnym artykułem jest zabezpieczenie dostępu do Sophos Firewall: poprawna konfiguracja Device Access.

Test tunelu

Dobry test odbiorczy sprawdza nie tylko zielony status. Sprawdza rzeczywisty przepływ danych.

1. Sprawdzić status

W interfejsie WebAdmin:

Site-to-site VPN > IPsec

Sprawdzić:

• Połączenie jest aktywne.
• Status tunelu jest established.
• Przy wielu sieciach wszystkie oczekiwane Child SAs są zestawione.
• Nie widać powtarzających się reconnects ani błędów.

2. Sprawdzić Log Viewer

Menu path:

Log viewer

Wygenerować ruch testowy z jasnym Source, Destination i Service. Następnie w Log Viewer sprawdzić, która reguła firewall pasuje i czy NAT, Webfilter, IPS albo inne moduły wpływają na ruch.

3. Użyć Packet Capture

Jeśli Log Viewer nie wystarcza, należy użyć Packet Capture z wąskim filtrem:

Diagnostics > Tools > Packet capture

Przykład filtra:

host 172.16.10.25 and host 10.20.30.15

Przy VPN troubleshooting ważne jest sprawdzenie obu kierunków. Tylko wychodzące pakiety bez odpowiedzi wskazują najczęściej na problem ścieżki powrotnej, NAT albo strony zdalnej.

4. CLI używać tylko celowo

Do głębszej analizy można użyć Advanced Shell przez SSH:

ipsec statusall

Interesujące są między innymi:

• IKE SA established
• Child SA installed
• sieci lokalne i zdalne
• liczniki bajtów w obu kierunkach
• powtarzające się komunikaty rekey albo disconnect

Jeśli SSH nie jest jeszcze przygotowany, pomaga połączenie z Sophos Firewall przez SSH.

Typowe błędy

Lista kontrolna

Przed zmianą:

• Sieci lokalne i zdalne są jednoznaczne.
• Policy-based albo route-based wybrano świadomie.
• Profil IPsec jest uzgodniony ze stroną zdalną.
• Preshared Key albo certyfikaty są bezpiecznie udokumentowane.
• Reguły firewall są zaplanowane, wraz z kierunkiem, pozycją reguły, logging i usługami.
• Przy Create firewall rule wiadomo, które automatycznie utworzone reguły trzeba poprawić.
• Przy route-based Any-to-Any zaplanowano ręczne reguły firewall i trasy.
• NAT jest wykluczony albo świadomie udokumentowany.
• Device Access dla IPsec został sprawdzony.
• Okno serwisowe, strona zdalna i ścieżka fallback są znane.

Po zmianie:

• Status tunelu jest established.
• Log Viewer pokazuje oczekiwaną regułę firewall.
• Packet Capture pokazuje kierunek wychodzący i powrotny.
• Przetestowano wewnętrzne DNS i dostęp do aplikacji.
• Liczniki bajtów rosną w obu kierunkach.
• NAT i ścieżka powrotna są uzgodnione ze stroną zdalną.
• Zmiana została ujęta w dokumentacji sieciowej.

Częste pytania