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.

Skrócony przebieg: wybrać typ tunelu, uzgodnić profil i identyfikatory, utworzyć połączenie, dla route-based Any-to-Any skonfigurować routing interfejsu XFRM, ustawić reguły firewall i NAT, a następnie odebrać tunel przy użyciu rzeczywistego ruchu, logów i Packet Capture.

Procedura pasuje do połączeń Sophos-to-Sophos oraz z rozwiązaniami innych dostawców między centralą, oddziałem lub cloud gateway. Dla Microsoft Azure i AWS obowiązują dodatkowe szczegóły dostawcy: łączenie Sophos Firewall z Azure VPN Gateway oraz łączenie Sophos Firewall z AWS Site-to-Site VPN. Dla Remote Access pojedynczych użytkowników właściwy jest wybór między Sophos Connect i SSL VPN. Jeśli istniejący tunel jest już zielony, ale ruch nie przepływa, należy skorzystać z Sophos Firewall IPsec VPN Troubleshooting.

Jeśli łączone są wyłącznie dwie Sophos Firewall, a oddział ma zestawiać tunel jako klient do centrali dostępnej pod stałym adresem, prostszą alternatywą jest SSL Site-to-Site VPN. W przypadku innych producentów, redundancji, routingu dynamicznego lub rosnących sieci route-based IPsec pozostaje bardziej elastycznym wyborem.

Dla wielu firewalli zarządzanych przez Sophos Fusion (dawniej Sophos Central) SD-WAN Connection Group może automatycznie generować tunele oparte na trasach, interfejsy XFRM, trasy i opcjonalne reguły. Nie zastępuje to planowania topologii ani lokalnej weryfikacji ruchu.

Wybór policy-based lub route-based

Przed konfiguracją trzeba zdecydować, czy tunel będzie zbudowany jako policy-based, czy route-based. Poza interfejsem Sophos wariant route-based jest często nazywany również tunnel-based. Oba określenia opisują tunel z własnym interfejsem XFRM. Spotykany czasem termin “root-based” nie jest natomiast trybem VPN.

Sophos zaleca VPN route-based dla nowych projektów. Any-to-Any jest szczególnie elastyczny w rosnących sieciach, ponieważ zmiany tras nie rozłączają tunelu. Zmiany podsieci lub Traffic Selectors przerywają natomiast istniejące połączenia. Oba końce tunelu muszą używać tego samego typu: policy-based po jednej stronie i route-based po drugiej nie jest obsługiwane.

Dla OSPF lub BGP przez tunel przejrzystym rozwiązaniem jest route-based Any-to-Any z zaadresowanymi interfejsami XFRM. Przed aktualizacją starszego projektu policy-based należy sprawdzić, czy sieci VPN są rozgłaszane przez redistribute kernel; artykuł SFOS 22: trasy IPsec i redistribute kernel wyjaśnia zmianę wersji i bezpieczne ramy migracji.

Co naprawdę potwierdza zielony tunel

Stan taki jak Established potwierdza, że peery wynegocjowały IKE i co najmniej jedną Child SA. Nie potwierdza, że wybrano trasę, reguła firewall pasuje, NAT jest poprawny, peer zna drogę powrotną ani że host docelowy odpowiada. Tunel może więc być zielony, a mimo to nie przenosić użytecznego ruchu między lokalizacjami.

Sophos Firewall używa ESP w trybie tunelowym. ESP chroni integralność danych, uwierzytelnia pochodzenie przenoszonych danych i zapewnia ochronę anti-replay przed ponownym odtworzeniem pakietów.

Ścieżkę danych można przedstawić za pomocą następującego modelu:

Policy-based
Źródło -> Reguła firewall -> Selector Local/Remote -> Child SA -> Peer -> Trasa powrotna i reguła -> Cel

Route-based Any-to-Any
Źródło -> Trasa lub SD-WAN Route -> Reguła firewall -> XFRM -> Child SA -> Peer -> Trasa powrotna i reguła -> Cel

Jest to model diagnostyczny, a nie pełne odwzorowanie wewnętrznej kolejności przetwarzania SFOS. Rozróżnienie jest jednak kluczowe podczas odbioru: w trybie policy-based para sieci w połączeniu IPsec określa ruch należący do tunelu. W trybie route-based Any-to-Any wyboru dokonuje routing lub SD-WAN.

Wymagania i dane planistyczne

Przed konfiguracją należy udokumentować co najmniej te dane:

• Lokalny endpoint: interfejs WAN Sophos Firewall oraz adres, pod którym strona zdalna osiąga ten interfejs.
• Remote Gateway: publiczny adres IP lub hostname DNS strony zdalnej.
• Gateway type: w centrali najczęściej Respond only, w oddziale najczęściej Initiate the connection.
• IP version: IPv4, IPv6 lub Dual. Dual jest dostępny tylko dla interfejsów tunelowych route-based z Any-to-Any jako lokalne i zdalne podsieci. Przy Dual reguły firewall IPv4 i IPv6 trzeba planować oddzielnie.
• Sieci lokalne: na przykład 172.16.10.0/24 i 172.16.20.0/24.
• Sieci zdalne: na przykład 10.20.30.0/24.
• Typ VPN: policy-based lub route-based. Connection type Host-to-host również istnieje, ale nie jest zakresem tej instrukcji połączeń między lokalizacjami.
• Listening interface: interfejs WAN lokalnego firewalla. Nie można do tego użyć bridge interface.
• Wersja IKE: preferowana IKEv2, jeśli strona zdalna ją obsługuje.
• Authentication type: Preshared key, Digital certificate lub RSA key.
• Local ID i Remote ID: szczególnie ważne przy FQDN, dynamicznych stronach zdalnych, NAT-T lub Wildcard Gateway.
• Profil IPsec: Encryption, Authentication, DH Group, PFS i Key life.
• Reguły firewall: dozwolone źródła, cele i usługi.
• NAT: bez NAT albo SNAT/DNAT z powodu nakładających się sieci lub wymagań dostawcy.
• Eksploatacja: owner, okno serwisowe, plan testów, monitoring i ścieżka awaryjna.

Spójny przykład dla obu firewalli

Poniższe wartości dokumentacji ułatwiają realizację kolejnych kroków. Zastąp je wszystkie własnymi adresami WAN, sieciami i nazwami:

Najpierw utworzyć obie sieci LAN jako obiekty sieciowe w Hosts and services > IP host. W centrali 10.10.10.0/24 jest Local subnet, a 10.20.20.0/24 — Remote subnet; w oddziale wartości te należy odwrócić. To samo dotyczy identyfikatorów: Local ID jednej strony musi być oczekiwany jako Remote ID przez drugą. Sieć transferowa 10.255.0.0/30 jest używana tylko dla route-based Any-to-Any i nie może nakładać się na żadną sieć produkcyjną, VPN ani zarządzającą.

Dla identyfikatorów w tym przykładzie na obu firewallach ustawić Local ID type = DNS i Remote ID type = DNS. W centrali wprowadzić Local ID vpn-hq.example.invalid i Remote ID vpn-branch.example.invalid; w oddziale dokładnie odwrotnie. Wartości te identyfikują peery i nie służą do rozwiązywania ich adresów gateway przez DNS. Przy innym typie identyfikatora również typ i format muszą pasować krzyżowo.

Dla każdego obiektu sieciowego IPv4 wybrać Add, IP version = IPv4, Type = Network, wprowadzić adres sieci i maskę podsieci /24, a następnie zapisać. Czytelne nazwy to HQ_LAN dla 10.10.10.0/24 i Branch_LAN dla 10.20.20.0/24; oba obiekty są potrzebne na obu firewallach. Obiekt hosta służy natomiast do zdefiniowania pojedynczego adresu używanego do testów lub monitoringu.

Ustawienie oddziału jako inicjatora rozkłada ponawianie prób połączenia na poszczególne oddziały i jest przydatne przy zmiennym adresie IP WAN oddziału. Jeśli inicjator ma połączyć się z peerem o dynamicznym adresie IP WAN, pole Gateway address tego peera musi zawierać hostname DNS, który faktycznie rozwiązuje się na jego aktualny publiczny adres. Konfiguracja i weryfikacja Dynamic DNS na Sophos Firewall opisuje rejestrację i test rozwiązywania nazwy. Sam identyfikator DNS ID nie jest osiągalnym adresem gateway. DDNS skonfigurowany wyłącznie w centrali nie umożliwia ustalenia dynamicznego adresu oddziału.

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

Sieci, profil, identyfikatory i certyfikaty

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 przetłumaczenie go “w jakiś sposób” tworzy tunele trudne w utrzymaniu.

Dla nowych lokalizacji warto więc przygotować spójną koncepcję adresacji IP. Jeśli VLAN lub strefy nie są jeszcze poprawnie zamodelowane, pomaga konfiguracja stref i interfejsów w Sophos Firewall.

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 uzgodnić wspólny profil na piśmie, a dopiero potem skonfigurować obie strony.

W IKEv2 Sophos może używać unikalnych Preshared Key dla każdej kombinacji Local ID i Remote ID. W IKEv1 jest to bardziej ograniczone, ponieważ dla każdej kombinacji gateway obowiązuje tylko jeden PSK. W środowiskach z wieloma tunelami do tej samej strony zdalnej należy więc preferować IKEv2 z jednoznacznymi identyfikatorami.

⚠️ W IKEv1 firewall używa PSK z ostatnio skonfigurowanego połączenia dla tej samej kombinacji bramy lokalnej i zdalnej. Dotyczy to konfiguracji IPsec site-to-site i zdalnego dostępu. Późniejsze skonfigurowanie połączenia dla tej kombinacji bram z innym PSK może spowodować błąd uwierzytelniania istniejących połączeń podczas kolejnej negocjacji. Przed dodaniem takiego połączenia lub zmianą PSK sprawdzić wszystkie powiązane konfiguracje IKEv1 i uzgodnić PSK z odpowiednimi stronami zdalnymi przed następną negocjacją.

NAT Traversal jest na Sophos Firewall zawsze aktywny. Jeśli jedna strona znajduje się za routerem lub NAT-em dostawcy, identyfikatory stają się ważniejsze, ponieważ publiczny adres gateway nie opisuje jednoznacznie peer. Local ID jednej strony musi odpowiadać Remote ID oczekiwanemu przez stronę zdalną. Identyfikatory DNS, IP lub e-mail nie muszą być publicznie rozwiązywalne, ale ich format i wartość muszą pasować krzyżowo.

Sophos Firewall nie udostępnia osobnego przełącznika NAT-T: Urządzenia automatycznie wykrywają NAT. Bez NAT negocjacje IKE używają UDP 500, a ruch danych korzysta z ESP przez IP protocol 50. Po wykryciu urządzenia NAT firewall enkapsuluje dalsze negocjacje IKE i fazy 2 oraz pakiety ESP w UDP 4500.

Jeśli na ścieżce IPsec znajduje się urządzenie NAT, a peer jest zaporą innego producenta, NAT-T musi być włączony również na tej zaporze. Ustawienie sprawdza się na podstawie dokumentacji tego peera; w Sophos Firewall nie jest potrzebny dodatkowy przełącznik.

Peery wykrywają urządzenie NAT podczas wymiany IKE fazy 1 i uzgadniają wtedy użycie NAT-T. ESP jest protokołem warstwy 3 bez informacji o portach warstwy 4, natomiast PAT może tłumaczyć również porty. Enkapsulacja UDP przez port 4500 zapewnia więc rozpoznawalną otoczkę UDP na ścieżce NAT; peer usuwa tę otoczkę i przetwarza oryginalny pakiet IPsec.

Jeśli Sophos Firewall znajduje się za routerem, router musi stosować DNAT lub przekierowanie portów z adresu publicznego na prywatny adres Listening interface zapory. W przyjętym przykładzie adres WAN routera w centrali może wynosić 198.51.100.10, podczas gdy WAN firewalla używa 172.31.255.2. Centrala wybiera wtedy swój prywatny interfejs WAN jako Listening interface; oddział nadal łączy się z 198.51.100.10, a nie z 172.31.255.2. Router tłumaczy adres docelowy ze swojego adresu publicznego na 172.31.255.2. Selectors sieci LAN pozostają bez zmian: w centrali Local 10.10.10.0/24, Remote 10.20.20.0/24, a w oddziale dokładnie odwrotnie.

Dla NAT-T trzeba zezwolić na UDP 500 i UDP 4500. Instrukcje SFOS 22 i SFOS 23 dotyczące firewalla za routerem wymieniają dodatkowo IP protocol 50, a nie port TCP/UDP 50. Przy wynegocjowanym NAT-T pakiety ESP są przenoszone wewnątrz UDP 4500; natywny ESP używa protokołu 50. Listy wymaganych zezwoleń na routerze i opisu NAT-T nie wolno więc traktować jako opisów identycznych ścieżek pakietów. Przed zmianą udokumentować funkcje routera i istniejące przekierowania, a następnie na podstawie logów IKE oraz Packet Capture sprawdzić, która ścieżka jest faktycznie używana. Nie usuwać istniejącego zezwolenia na ESP bez weryfikacji; dodatkowe zezwolenia ograniczyć do zaplanowanych adresów peerów. Jeśli negocjacja nie dochodzi do skutku, przywrócić udokumentowaną konfigurację routera. Jest to odrębne od SNAT/DNAT dla nakładających się sieci LAN lub tłumaczonego ruchu danych.

Przy Digital certificate formaty i role certyfikatów po obu stronach muszą dokładnie do siebie pasować. Sophos nie obsługuje certyfikatów ECDSA dla połączeń IPsec; wymagane są certyfikaty RSA. Local certificate należy do lokalnego firewalla, Remote certificate do strony zdalnej, a Remote CA certificate stanowi podstawę zaufania do jej certyfikatu. Nie używać publicznego CA jako Remote CA certificate: atakujący posiadający ważny certyfikat wystawiony przez ten CA mógłby w przeciwnym razie uzyskać nieuprawniony dostęp. Przy typie identyfikatora DER.ASN1 DN (X.509) używany jest Distinguished Name odpowiedniego certyfikatu; jako Remote ID należy wpisać DN certyfikatu peera.

RSA key jest osobnym Authentication type, a nie wyborem certyfikatu RSA. Firewall automatycznie generuje parę kluczy i w polu Local RSA key pokazuje tylko klucz publiczny. Skopiować go do Remote RSA key strony zdalnej, a jej klucz publiczny wkleić do lokalnego pola Remote RSA key. Obie strony muszą używać tego samego formatu PKCS1 lub DNS. Kluczy prywatnych nie przesyła się między firewallami.

Zmiana lokalnego CA Default na Sophos Firewall jest zmianą trust anchor, a nie kosmetyczną edycją certyfikatu. Peery z zaimportowanym Default.pem i lokalnie podpisane certyfikaty muszą zostać zmigrowane w sposób kontrolowany. Kontrolowane odnawianie Default CA na Sophos Firewall opisuje inwentaryzację, okno serwisowe, testy i odzyskiwanie.

Po wybraniu Digital certificate sama opcja w formularzu połączenia nie wystarcza. Zaufanie do CA, certyfikaty lokalne, certyfikaty peerów i Certificate IDs muszą być przygotowane wcześniej. Pełną procedurę opisuje Konfiguracja IPsec Site-to-Site z certyfikatami. Jeśli CA unieważnia certyfikaty przed końcem ważności, aktualna lista unieważnień również musi znaleźć się w planie operacyjnym. Osobna procedura opisuje import CRL, kontrolę nextUpdate i kontrolowany test negatywny na Sophos Firewall.

Jeśli tunel się nie zestawia, typowymi wskazówkami są NO_PROPOSAL_CHOSEN, błędy identyfikatorów lub uwierzytelniania. Sekcja Testowanie tunelu i rozwiązywanie problemów zaczyna się od odpowiedniego zawężenia przyczyny.

Konfiguracja IPsec policy-based

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

1. Sprawdzenie lub utworzenie profilu IPsec

Ścieżka menu:

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 Branch-Zurich-IKEv2. Nazwa musi pozostać zrozumiała, 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 life

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

Zależności między Phase 1, Phase 2, PFS, lifetimes, rekeyingiem i DPD wyjaśnia artykuł Zrozumienie i bezpieczna konfiguracja profili IPsec Sophos Firewall. Przed aktywacją sprawdzić Dead peer detection: Sophos przewiduje Hold lub Disconnect dla peera odpowiadającego oraz Re-initiate dla inicjatora. Grupa failover IPsec zmienia to zachowanie i nie działa według tej samej logiki DPD.

2. Dodanie połączenia IPsec

Ścieżka menu:

Site-to-site VPN > IPsec

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

• Nazwa tunelu, na przykład branch-zurich
• IP version, zwykle IPv4
• Gateway type, na przykład Respond only w centrali lub Initiate the connection w oddziale
• Listening interface jako lokalny interfejs WAN
• Gateway address strony zdalnej jako adres IP lub hostname DNS
• Authentication type: Preshared key, Digital certificate lub RSA key
• Local ID i Remote ID, jeśli potrzebne
• IPsec profile
• Local subnet
• Remote subnet

W tym przykładzie policy-based po obu stronach wybierane są konkretne sieci. Dokumentacja SFOS 22 i SFOS 23 nie jest jednolicie sformułowana w kwestii Any: przegląd Policy-based stwierdza, że Any nie można wybrać dla lokalnych i zdalnych podsieci; instrukcja Add an IPsec connection dopuszcza Any najwyżej po jednej stronie. Nie należy na tej podstawie wyprowadzać konfiguracji policy-based Any-to-Any. Jeśli wymagane jest jednostronne Any, przed wdrożeniem sprawdzić w izolowanej konfiguracji testowej dostępność tej opcji w zainstalowanym buildzie, Selectors strony zdalnej i zamierzony routing. W razie nieoczekiwanej SA lub nieprawidłowego przypisania ruchu dezaktywować nowe połączenie i przywrócić udokumentowane konkretne Selectors. Przy wielu konkretnych sieciach lokalnych i zdalnych powstaje jedna Phase 2 SA dla każdej kombinacji: dwie sieci lokalne i dwie zdalne dają cztery SA. Wszystkie połączenia policy-based współdzielą jeden interfejs IPsec; samo przechwycenie pakietów na tym interfejsie nie identyfikuje więc tunelu.

Przy Respond only adres wildcard * może być przydatny, gdy wiele oddziałów lub dynamicznych stron zdalnych łączy się z centralą. Wtedy trzeba ustawić co najmniej Local ID lub Remote ID; dla jednoznacznego przypisania zwykle warto użyć obu. Local ID jednej strony odpowiada Remote ID oczekiwanemu przez drugą. Initiate the connection nie obsługuje adresu wildcard, dlatego stronę zdalną definiuje się jako adres IP lub hostname DNS.

Dla Preshared Key należy użyć silnego, unikalnego klucza i bezpiecznie go udokumentować. Stary standardowy klucz współdzielony przez wiele lokalizacji stanowi niepotrzebne ryzyko operacyjne.

Przy Authentication type = Preshared key wprowadzić uzgodniony PSK i powtórzyć go w polu potwierdzenia. Po stronie zdalnej wprowadzić dokładnie ten sam PSK i również go potwierdzić; lustrzane ustawienie identyfikatorów nie zmienia wspólnego klucza. PSK przekazywać wyłącznie przez przewidziany do tego bezpieczny kanał; nie umieszczać go na zrzutach ekranu ani w publicznych zgłoszeniach.

Następnie utworzyć połączenie po stronie zdalnej z ustawieniami lustrzanymi. W tym przykładzie centrala oczekuje na 203.0.113.20 z ustawieniem Respond only; jej sieci Local/Remote to odpowiednio 10.10.10.0/24 i 10.20.20.0/24. Oddział używa Initiate the connection, Gateway address 198.51.100.10 i zamienia miejscami sieci oraz identyfikatory Local/Remote. Profil, uwierzytelnianie i PSK muszą być zgodne. Połączenie należy aktywować dopiero po zapisaniu obu wpisów i sprawdzeniu reguł.

Zaawansowane ustawienia User authentication mode dotyczą tylko profili IKEv1 z logiką XAuth, na przykład bardzo starych projektów client-server. W normalnych połączeniach Site-to-Site z IKEv2 nie należy traktować tego jako dodatkowego kroku uwierzytelniania. Przestarzałych ustawień Idle Connection również nie należy planować jako nowoczesnego modelu eksploatacji.

3. Aktywacja tunelu

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.

Bez Activate on save zapisane połączenie aktywuje się za pomocą jego przycisku Status w Site-to-site VPN > IPsec. Należy odróżnić to od Gateway type = Disable: połączenie pozostaje wtedy nieaktywne do chwili zainicjowania go przez użytkownika. Respond only oczekuje na żądania; Initiate the connection rozpoczyna negocjację również po ponownym uruchomieniu usługi VPN lub firewalla. Po samym Disconnect inicjator może ponownie zestawić połączenie; przy wycofywaniu konfiguracji trzeba więc dodatkowo dezaktywować połączenie.

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 lub zdalnych może też istnieć wiele Security Associations.

API XML: oddzielenie konfiguracji od operacji sterujących

Aby zautomatyzować tę procedurę, nie należy po prostu tłumaczyć pól GUI na żądanie XML. Dokumentacja API dla SFOS 22 i SFOS 23 pokazuje ustawienia w VPNIPSecConnection/Configuration, a obok osobne gałęzie sterujące Active, DeActive, Connection i DisConnection, każdą z Name. Komentarz w przykładzie wskazuje, że te cztery gałęzie działają dopiero po utworzeniu połączenia. Przykład konfiguracji zawiera osobno Status z Active/Deactive; wiersz parametru ActivateOnSave podaje y/n. Zapis, aktywacja, zachowanie po restarcie i faktycznie zestawiony tunel nie są więc zamiennymi ustawieniami ani dowodem na poprawność wykonywalnego żądania API.

Ten starszy opis zawiera również sprzeczności między przykładem a wierszami parametrów:

• W przykładzie AliasLocalWANPort występuje po komentarzu dotyczącym aliasu portu WAN, ale tabela określa go jako obowiązkowe ARRAY. Name i RemoteHost też są tam ARRAY; nie określa to ani bezpiecznej serializacji wielu wartości, ani ich przypisania parami.
• Przykład UserAuthenticationMode pokazuje AsServer/AsClient, a wiersz podaje EnableAsServer/EnableAsClient. Dla DisconnectOnIdleInterval wartość domyślna 0 leży poza wskazanym zakresem 120..21600; 600 jest tylko wartością przykładową. Nie ujednolicać tych różnic po cichu ani nie przyjmować tych wartości jako domyślnych dla IKEv2.
• Starsze pole AllowNATTraversal z Enable/Disable nie potwierdza istnienia obecnego przełącznika NAT-T. Wiersz RemoteHost zabrania * przy RSAKey; jest to ograniczenie tego opisu, a nie potwierdzona tutaj ogólna reguła działania GUI.

Dopóki reprezentacja API zainstalowanego buildu nie jest wyjaśniona, używać opisanej powyżej procedury WebAdmin i wyjaśnić niejasności przed automatyzacją. Automatyczne wykrywanie NAT-T oraz wskazówki dotyczące IKEv2, RSA i identyfikatorów pozostają bez zmian dla opisanej procedury GUI.

Konfiguracja IPsec route-based

IPsec route-based rozdziela negocjację VPN od wyboru trasy. Przy Any-to-Any SFOS udostępnia własny, adresowalny interfejs XFRM. Instrukcje SFOS 22 i SFOS 23 opisują utworzenie interfejsu XFRM również przy konkretnych Traffic Selectors; w odróżnieniu od Any-to-Any nie wolno przypisywać mu adresu IP ani ręcznej trasy. Przed migracją należy udokumentować zainstalowaną wersję SFOS, przypisanie interfejsu i faktycznie utworzoną trasę.

1. Utworzenie połączenia jako route-based

Ścieżka menu:

Site-to-site VPN > IPsec

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

2. Implementacja Any-to-Any lub Traffic Selectors

Przy Any-to-Any Sophos pokazuje utworzony interfejs XFRM pod używanym interfejsem fizycznym w:

Network > Interfaces

Utworzony interfejs XFRM zawsze pozostaje przypisany do strefy VPN. Oba warianty konfiguruje się inaczej.

Any-to-Any z IPv4, IPv6 lub Dual

Gdy Local subnet i Remote subnet są ustawione na Any, SFOS automatycznie tworzy interfejs XFRM dla połączenia IPsec route-based. Nie dodaje się osobnego interfejsu XFRM. W Network > Interfaces rozwinąć interfejs fizyczny wybrany jako Listening interface i otworzyć wygenerowany interfejs XFRM. W tym przykładzie przypisać 10.255.0.1/30 centrali, a 10.255.0.2/30 oddziałowi. Przy Dual wymagane są również oddzielne reguły firewall IPv4 i IPv6.

Edytowalne pole Name jest nazwą wyświetlaną. Nie należy go mylić z wartościami przypisywanymi przez SFOS: Hardware to nazwa rekordu, IPsec connection to powiązane połączenie route-based, a Network zone ma zawsze wartość VPN. Skonfigurować wyłącznie pola adresowe wersji IP wybranej w połączeniu IPsec:

• IPv4/netmask: wprowadzić zaplanowany adres transferowy IPv4 i wybrać podsieć.
• IPv6/prefix: wprowadzić zaplanowany adres transferowy IPv6 i prefiks.
• Przy Dual skonfigurować obie rodziny adresów. Jeśli połączenie używa wyłącznie IPv4 lub IPv6, SFOS nie stosuje wartości wprowadzonych dla drugiej wersji.

W Advanced settings > Interface settings zachować domyślną wartość MTU lub wprowadzić wartość sprawdzoną w ukierunkowanych testach. SFOS oblicza wartość domyślną, odejmując maksymalny narzut IPsec od MTU interfejsu fizycznego. Override MSS włączyć i podać wartość tylko wtedy, gdy sieć wymaga wartości innej niż domyślna firewalla; nie zakładać nieudokumentowanej domyślnej wartości liczbowej.

Przed zmianą zapisać bieżącą nazwę, adresy, MTU, stan i wartość Override MSS oraz zależne trasy lub gatewaye. Po zapisaniu ponownie otworzyć interfejs i sprawdzić, czy przypisane wartości Hardware, IPsec connection i strefa VPN pozostały bez zmian. Następnie wykonać Route lookup na obu peerach i przetestować rzeczywisty ruch w obu kierunkach, a po zmianie MTU lub MSS również duży transfer. Aby wycofać zmianę, przywrócić zapisane wartości pól i poprzednie trasy lub gatewaye. Nowe połączenie należy dezaktywować i usunąć tylko jego zależne trasy i reguły; nie wolno oddzielnie usuwać ani odtwarzać wygenerowanego interfejsu XFRM.

Następnie należy utworzyć trasę do zdalnej sieci LAN po obu stronach. W prostej konfiguracji statycznej otworzyć Routing > Static routes > IPv4 unicast route > Add:

• Centrala: Destination 10.20.20.0/24, Interface lokalny interfejs XFRM.
• Oddział: Destination 10.10.10.0/24, Interface lokalny interfejs XFRM.

Alternatywnie użyć SD-WAN Route lub routingu dynamicznego przez BGP lub OSPF. Dla SD-WAN Route zdecydować wyraźnie, czy inna ścieżka jest dopuszczona jako awaryjna. Jeżeli ruch nie może korzystać z innej trasy, gdy tunel jest niedostępny, włączyć Route only through specified gateways i oddzielnie przetestować ten scenariusz awarii.

Trasy i reguły firewall określają, jaki ruch trafia do tunelu. Prosta trasa statyczna może wskazywać bezpośrednio interfejs XFRM. Przy wielu łączach, kontrolach SLA lub określonych projektach failover tworzy się dodatkowo Custom Gateway z adresem IP XFRM strony zdalnej i wykorzystuje go w SD-WAN Route.

Dla alternatywnego wariantu SD-WAN w Routing > SD-WAN routes wybrać IPv4 i Add. W centrali ustawić Source networks = HQ_LAN, Destination networks = Branch_LAN, a w Link selection settings wybrać Primary and backup gateways. W Primary gateway > Add ustawić Gateway IP na 10.255.0.2, a jako Interface wybrać lokalny XFRM z adresem 10.255.0.1/30. W oddziale zamienić Source/Destination, użyć Gateway IP 10.255.0.1 i lokalnego XFRM z adresem 10.255.0.2/30. Dla Health check w Monitoring condition wybrać wewnętrzny host po stronie zdalnej, który faktycznie odpowiada, na przykład 10.20.20.15 w oddziale lub 10.10.10.25 w centrali. Sama sonda musi być dozwolona i korzystać z właściwego tunelu. Dla wyboru ścieżki na podstawie SLA wybrać profil SD-WAN z gatewayami tunelowymi. Trasa statyczna i trasa SD-WAN są tutaj alternatywami; nie tworzyć obu jako konkurencyjnych ścieżek bez uprzedniej weryfikacji. Przed zmianą udokumentować istniejące Route Precedence i reguły, a przy wycofywaniu przywrócić poprzedni wybór trasy/gateway.

Tunele Any-to-Any mogą sterować wieloma gatewayami XFRM bezpośrednio przez SD-WAN i kontrole SLA; nie wymagają do tego dodatkowej grupy VPN failover. Natomiast tunele policy-based i route-based z Traffic Selectors używają grupy failover IPsec do obsługi połączeń redundantnych. Podlinkowany proces wyjaśnia kolejność, Health Check, Automatic failback i kontrolowany test awarii. Grupa wyłącza DPD dla przypisanych połączeń i ustawia Key negotiation tries na 3.

Sprawdź cztery punkty po zapisaniu:

1. Interfejs XFRM jest widoczny w Network > Interfaces i ma planowany adres IP.
2. Trasa do sieci zdalnej wskazuje bezpośrednio interfejs XFRM lub, w projekcie z gatewayem/SD-WAN, odpowiedni gateway XFRM.
3. Diagnostics > Tools > Route lookup zwraca oczekiwany interfejs XFRM lub gateway XFRM dla rzeczywistego hosta w zdalnej sieci LAN. Ten sam test przeprowadzić po stronie zdalnej.
4. Reguły firewall zezwalają tylko na planowane kierunki i usługi.

Traffic Selectors

Dla konkretnych podsieci przeanalizowane instrukcje SFOS 22 i SFOS 23 opisują jeden interfejs XFRM na konfigurację IPsec. W Network > Interfaces rozwinąć Listening interface za pomocą niebieskiego oznaczenia. Nie przypisywać utworzonemu interfejsowi adresu IP ani ręcznej trasy: trasa statyczna powstaje automatycznie, gdy tunel ma stan established. W centrali wybrać Local HQ_LAN i Remote Branch_LAN, a w oddziale Local Branch_LAN i Remote HQ_LAN. Gateway, profil, uwierzytelnianie i identyfikatory skonfigurować lustrzanie, tak jak w pozostałych wariantach. Any tylko po jednej stronie i konkretny Selector po drugiej nie są obsługiwane w trybie route-based. Jeśli w zainstalowanym buildzie brakuje interfejsu opisanego w dokumentacji, najpierw wyjaśnić konfigurację, wersję i logi; nie próbować wymuszać zastępczego XFRM ani adresacji właściwej dla Any-to-Any.

Ten wariant nadaje się do małych, jasno zdefiniowanych sieci; Sophos zaleca go zamiast policy-based, również dla zgodnych połączeń z urządzeniami innych producentów. Użyć interfejsu XFRM w Diagnostics > Packet capture, aby przypisać ruch wychodzący do właściwego połączenia; dodatkowo sprawdzić trasę automatyczną, każdą oczekiwaną Child SA, logi i ruch w obu kierunkach. WAF przez IPsec route-based z Traffic Selectors nie jest obsługiwany; do tego zastosowania można rozważyć odpowiednią konfigurację route-based Any-to-Any. W razie nieudanej migracji dezaktywować nowe połączenie i tylko jego nowe reguły, a następnie ponownie aktywować udokumentowane poprzednie połączenie.

Tunelu Any-to-Any nie można bezpośrednio zmienić na konkretne Traffic Selectors. Połączenie trzeba sklonować lub utworzyć ponownie, a następnie przełączyć w kontrolowany sposób.

3. Uwzględnienie 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 sprawdzić MTU, MSS, fragmentację i rzeczywistą ścieżkę. Odpowiednią procedurę opisuje sprawdzenie MTU i MSS w Sophos Firewall przy problemach VPN.

Reguły firewall, NAT i Device Access

Reguły firewall i reguły automatyczne

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

Ścieżka menu:

Rules and policies > Firewall rules

Typowe reguły:

• Sieć lokalna do sieci zdalnej: na przykład LAN do VPN.
• Sieć zdalna do lokalnej sieci serwerowej: na przykład VPN do Server.
• Management lub Monitoring: zezwalać tylko zdefiniowanym systemom administracyjnym lub monitorującym.
• DNS, AD, RDP, HTTPS: udostępniać tylko potrzebne usługi, nie ogólne Any.

Interfejsy XFRM zawsze należą do strefy VPN. Jeśli używane są oba kierunki, potrzebne są odpowiednie reguły inbound i outbound. Oddzielne reguły z loggingiem wyraźniej pokazują podczas odbioru, która strona może osiągać konkretne usługi. Ogólną konfigurację opisuje tworzenie i bezpieczne sprawdzanie reguł Sophos Firewall.

Przychodzące pakiety IPsec są najpierw dekapsulowane i odszyfrowywane. Następnie pasująca reguła firewall stosuje swoje polityki bezpieczeństwa do ruchu danych, zanim zostanie on przekazany do celu. Dla ruchu wychodzącego pasująca reguła firewall jest stosowana przed enkapsulacją i szyfrowaniem.

Opcja Create firewall rule tworzy osobne reguły z prefiksami Incoming i Outgoing na początku listy reguł. Następnie:

• Sprawdzić pozycję reguł.
• Zawęzić Source i Destination.
• Ograniczyć Any do wymaganych Services.
• Włączyć Log firewall traffic na czas wdrożenia i analizy błędów.
• Świadomie wybrać IPS, Web, Application Control i inne Security Features.
• Nadać regule zrozumiałą nazwę, na przykład LAN_to_Branch_Zurich.

Utworzone reguły znajdują się w grupie Automatic VPN rules. W przykładzie centrala zezwala na ruch wychodzący z ustawieniami Source zone LAN, Source network HQ_LAN, Destination zone VPN, Destination network Branch_LAN; dla ruchu przychodzącego strefy i sieci należy zamienić miejscami. W oddziale obowiązuje analogiczna konfiguracja lustrzana z Branch_LAN jako siecią lokalną. Services każdorazowo ograniczyć do zatwierdzonych portów aplikacyjnych i włączyć Log firewall traffic. Zamiast tworzyć nowe reguły dla każdego tunelu, można uzupełnić istniejące odpowiednie reguły o właściwe sieci Source/Destination. Wcześniej sprawdzić wpływ na wszystkie pozostałe połączenia objęte daną regułą. SFOS sprawdza reguły od góry do dołu i zatrzymuje się na pierwszym dopasowaniu; nowa reguła na początku listy może więc sprawić, że dotychczasowe ograniczenia nie zostaną zastosowane.

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

Dla route-based Any-to-Any Sophos nie może automatycznie tworzyć reguł. Przy Dual reguły IPv4 i IPv6 są tworzone oddzielnie. Jeśli ruch internetowy oddziału ma przechodzić przez centralę, potrzebny jest dodatkowo własny projekt NAT i bezpieczeństwa.

Planowanie NAT według typu tunelu

NAT nie jest zakazany w przypadku IPsec, ale musi mieć jasny powód. Typowymi przypadkami są nakładające się na siebie sieci, wymogi dotyczące chmury lub zewnętrzne systemy, które akceptują tylko określone adresy źródłowe. NAT nie zastępuje trasy i nie zmienia decyzji routingu: niezależnie od translacji SFOS musi być w stanie wybrać odpowiednią trasę VPN, statyczną, SD-WAN lub dynamiczną do miejsca docelowego.

Ścieżka menu:

Rules and policies > NAT rules

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

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

Logika NAT różni się zależnie od typu VPN:

• Przy IPsec policy-based i VPN route-based z Traffic Selectors NAT dla nakładających się sieci można skonfigurować bezpośrednio w połączeniu IPsec.
• Przy route-based Any-to-Any reguły SNAT i DNAT są używane w Rules and policies > NAT rules.
• Przy nakładających się sieciach obie strony muszą rozumieć ten sam plan translacji. Jednostronny NAT bez planowania powrotu często tworzy zielone tunele bez użytecznego ruchu.

Przy NAT konfigurowanym wewnątrz połączenia IPsec włączyć Network Address Translation (NAT). Translated subnet pokazuje lokalną sieć po translacji wybraną w połączeniu; w Original subnet wybrać rzeczywistą lokalną sieć, która nakłada się na sieć po drugiej stronie. Dla sieci bez translacji pozostawić Not translated. Przed zapisaniem porównać w tabeli sieć oryginalną, sieć po translacji, Remote Selector peera i docelowy adres DNS. Nie odgadywać kierunku wyłącznie na podstawie nazw pól; podlinkowana procedura NAT zawiera kompletny przykład. Dla Any-to-Any nie używać tych pól jako zamiennika osobnych reguł SNAT/DNAT.

⚠️ Przy route-based IPsec z Traffic Selectors użyć ustawienia NAT w połączeniu IPsec i nie przypisywać adresu IP ani ręcznej trasy do interfejsu XFRM wyświetlanego przez zainstalowany build. IPsec z NAT dla nakładających się sieci pokazuje kompletny, lustrzany projekt adresacji, DNS i NAT.

Jeśli ruch VPN route-based z Traffic Selectors pasuje do reguły SNAT z ustawieniem Translated source = MASQ, firewall odrzuca pakiety, ponieważ te interfejsy XFRM nie mają przypisanych adresów IP. Może to wyjaśniać zielony tunel bez użytecznego ruchu. Dla danego przepływu testowego sprawdzić pasującą regułę NAT i jej pozycję, a następnie skorygować tylko regułę powodującą konflikt; nie wyłączać MASQ zbiorczo dla innych połączeń. Następnie ponownie sprawdzić ten sam przepływ w obu kierunkach za pomocą Log Viewer i Packet Capture.

Jeśli ruch użyteczny policy-based IPsec jest translacją objęty przez oddzielną regułę SNAT, jej Outbound interface należy ustawić na Any. Reguła, która wymienia tam tylko konkretne porty WAN — zazwyczaj domyślna reguła SNAT — nie pasuje do tego ruchu VPN. Przy ustawieniu Any firewall używa wartości Translated source skonfigurowanej w pasującej regule SNAT. To zachowanie obowiązuje również wtedy, gdy Override source translation (SNAT) jest włączone dla określonych interfejsów wychodzących.

Od SFOS 22 policy-based IPsec tworzy trasę VPN w backendzie. Ręczna ipsec_route nie jest standardowym krokiem, ale może mieć znaczenie w określonych scenariuszach ruchu przekazywanego. W przypadku żądań uwierzytelniania generowanych przez system teksty pomocy Sophos dla SFOS 22 i SFOS 23 są ze sobą sprzeczne: przegląd routingu/NAT stwierdza, że ten ruch nie wymaga użycia polecenia; instrukcja uwierzytelniania opisuje natomiast wyjątek dla policy-based, gdy wybrane ustawienie Route Precedence nie kieruje ruchu do tunelu. Nie wynika z tego ani konieczność dodania trasy dla każdego rodzaju ruchu systemowego, ani ogólna zmiana globalnego ustawienia Route Precedence.

Przed zmianą adres źródłowy, sys-traffic-nat, Traffic Selectors i ścieżka powrotna muszą odpowiadać faktycznie obserwowanemu przepływowi pakietów. Istniejąca instrukcja dotycząca tras IPsec oraz procedura dla żądań uwierzytelniania generowanych przez system wyjaśniają ukierunkowane kontrole z użyciem rzeczywistego żądania i Packet Capture oraz oddzielny rollback dla NAT i trasy. Jeśli zachowanie w zainstalowanym buildzie pozostaje niejasne, należy je wyjaśnić z Sophos Support przed wprowadzeniem zmiany w środowisku produkcyjnym. Dalsze podstawy NAT opisano w Zrozumienie reguł NAT w Sophos Firewall.

Device Access dla przychodzącego IPsec

Dla przychodzących żądań IPsec firewall musi móc przyjmować ruch IPsec w odpowiedniej strefie WAN. Nie realizuje się tego zwykłą regułą LAN-do-WAN, lecz przez lokalne usługi firewalla.

Ścieżka menu:

Administration > Device access

IPsec musi być dozwolony dla WAN, jeśli firewall przyjmuje żądania przychodzące, na przykład z Respond only. Nie zastępuje to reguł dla ruchu użytkowego przez tunel. Jednocześnie należy sprawdzić, czy WebAdmin, SSH, User Portal lub VPN Portal nie są niepotrzebnie szeroko dostępne. Centralnym artykułem dotyczącym zabezpieczania tych lokalnych usług jest zabezpieczenie dostępu do Sophos Firewall: poprawna konfiguracja Device Access.

Jeśli peer ma pingować przez tunel sam firewall, w Ping/Ping6 zezwolić na dostęp ze strefy VPN i wybrać Apply. Nie jest to wymagany krok globalny dla pingowania hosta w sieci LAN: w tym przypadku znaczenie mają odpowiednie reguły tranzytowe i firewall hosta. Włączyć tylko dostęp do lokalnej usługi potrzebnej do testu, udokumentować jej pierwotne ustawienie i przywrócić je po teście, chyba że dostęp jest potrzebny na stałe. Ping z powłoki firewalla ma ponadto inny adres źródłowy niż ping z klienta LAN; nie traktować obu testów jako równoważnej weryfikacji reguły dla klienta.

Testowanie tunelu i rozwiązywanie problemów

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

Definiowanie macierzy odbioru

Przed pierwszym testem należy przygotować małą macierz odbioru. Dzięki temu wiadomo, które połączenia naprawdę muszą działać, a które celowo nie powinny być dozwolone.

Przydatne przypadki testowe:

• Lokalna sieć klientów do zdalnej sieci serwerów: typowy test aplikacyjny, na przykład HTTPS, RDP, SMB, SQL albo ICMP tylko jako test podstawowy.
• Zdalna sieć klientów do lokalnej sieci serwerów: sprawdzić kierunek przeciwny, jeśli połączenie jest używane dwukierunkowo.
• DNS lub AD przez tunel: testować tylko wtedy, gdy te usługi naprawdę mają działać przez tunel. Dokładnie określić Source, serwer docelowy i port.
• Monitoring lub backup: sprawdzić, czy zaplanowane systemy łączą się z właściwego kierunku i nie wymagają przypadkowo reguł Any.
• Test niedozwolony: celowo niedozwolony port lub sieć powinny być blokowane. W przeciwnym razie baza reguł jest zbyt szeroka.
• Duży transfer: przy transferze plików, RDP, VoIP lub problemach aplikacyjnych dodatkowo obserwować MTU/MSS i fragmentację.

Dla każdego przypadku testowego zanotować Source IP, Destination IP, Service, oczekiwaną regułę firewall, oczekiwaną regułę NAT i oczekiwany kierunek. Po każdym teście porównać Log Viewer, Packet Capture i liczniki bajtów. Jeśli testowany jest tylko ping, tunel nie został jeszcze odebrany.

1. Sprawdzenie statusu

W interfejsie WebAdmin:

Site-to-site VPN > IPsec

Sprawdzić:

• Połączenie jest aktywne.
• Status tunelu jest established.
• Przy wielu sieciach wszystkie oczekiwane Child SA są zestawione.

W Current activities > IPsec connections wyświetlane są tylko faktycznie zestawione połączenia. Dostępne filtry to Connection name, Local server name, Local subnet, Username, Remote server/host i Remote subnet; Refresh odświeża widok. Disconnect kończy istniejącą SA w kontrolowany sposób, na przykład gdy obie strony są gotowe do zmiany konfiguracji; nie zastępuje wyłączenia ani wycofania połączenia.

Z góry określić oczekiwaną liczbę: route-based Any-to-Any tworzy jedno połączenie Phase 2 na interfejs XFRM, natomiast Dual tworzy po jednym dla IPv4 i IPv6. Policy-based i route-based z Traffic Selectors tworzą jedno połączenie dla każdej kombinacji Local i Remote subnet.

Przed wysłaniem pierwszego ruchu użytecznego przez route-based Any-to-Any sprawdzić rzeczywisty adres hosta docelowego w Diagnostics > Tools > Route lookup. Na każdym firewallu wynik musi wskazywać planowany interfejs XFRM lub gateway XFRM.

2. Sprawdzenie Log Viewer

Ścieżka menu:

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 lub inne moduły wpływają na ruch. Procedurę opisuje testowanie reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture. Powtarzające się rekey, rozłączenia i błędy połączeń należy sprawdzać w logach IPsec, a nie wyprowadzać z bieżącego statusu SA.

3. Packet Capture i Advanced Shell

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

Diagnostics > 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 lub strony zdalnej.

W przyjętym przykładzie z klienta LAN 10.10.10.25 przetestować faktycznie istniejący host w oddziale 10.20.20.15, a nie adres sieci 10.20.20.0. W Windows polecenie ping 10.20.20.15 -t uruchamia test ciągły; zakończyć go za pomocą Ctrl+C. W Diagnostics > Packet capture > Configure ustawić BPF string na host 10.10.10.25 and host 10.20.20.15 and proto ICMP, zapisać i włączyć przechwytywanie. W trybie route-based sprawdzić ruch wychodzący na powiązanym XFRM i pakiety powrotne. W Log viewer wyszukać rzeczywisty adres klienta; na podstawie Firewall rule ID i za pomocą Filter firewall rule otworzyć dopasowaną regułę. Następnie przetestować także zaplanowany port aplikacyjny i kierunek przeciwny. Wyłączyć przechwytywanie i wycofać tymczasowe filtry oraz zezwolenia; ciągłe przechwytywanie nie jest monitoringiem eksploatacyjnym. Przy firewallu za routerem dodatkowo sprawdzić w logach obu peerów, czy wykryto NAT i wynegocjowano NAT-T.

Advanced Shell

Do głębszej analizy przez SSH otworzyć 5. Device Management > 3. Advanced Shell i sprawdzić bieżący status SA:

ipsec statusall

Istotne są między innymi:

• IKE SA established
• Child SA installed
• lokalne i zdalne Traffic Selectors
• liczniki bajtów w obu kierunkach

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

Aktualne logi IPsec

Aktualny przegląd logów SFOS 22 rozdziela zadania:

• strongswan.log: usługa IPsec i połączenia.
• charon.log: usługa IPsec oraz NAT w połączeniach IPsec.
• ipsec_monitor.log: monitoring usługi IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: aktywacja, dezaktywacja i łączenie przez WebAdmin.
• xfrmi.log: interfejsy XFRM przy IPsec route-based.
• dgd.log: tylko dodatkowo przy VPN failover, SD-WAN, DGD lub Link Load Balancing, nie jako ogólny log IPsec.

Pełną diagnostykę logów i XFRM opisuje Sophos Firewall IPsec VPN Troubleshooting.

Typowe błędy

• Tunel się nie zestawia: prawdopodobnie nie pasuje wersja IKE, profil, PSK, certyfikat, Local ID lub Remote ID. Sprawdzić strongswan.log, profil IPsec i stronę zdalną.
• Phase 1 działa, Phase 2 nie: prawdopodobnie nie pasują sieci lokalne lub zdalne albo Phase 2 proposal. Sprawdzić Traffic Selectors, podsieci i PFS.
• Tunel jest zielony, ale brak dostępu: prawdopodobnie brakuje reguły firewall, NAT, routingu lub ścieżki powrotnej. Sprawdzić Log Viewer, Packet Capture i routing.
• Działa tylko jeden kierunek: strona zdalna nie zna trasy powrotnej albo NAT jest błędny. Sprawdzić stronę zdalną, reguły NAT i liczniki bajtów.
• Małe pingi działają, aplikacje wiszą: prawdopodobnie uczestniczą MTU/MSS, fragmentacja lub Security Feature. Sprawdzić MTU/MSS i Packet Capture.
• Route-based Any-to-Any nie działa: prawdopodobnie nie pasuje IP XFRM, gateway, trasa lub reguła firewall. Sprawdzić Network > Interfaces, routing i reguły strefy VPN.
• Route-based z Traffic Selectors nie działa: sprawdzić opisany w dokumentacji XFRM pod Listening interface, trasę automatyczną, każdą oczekiwaną Child SA, Selectors, reguły strefy VPN i ewentualną regułę MASQ. Użyć XFRM w Packet Capture, ale nie przypisywać mu adresu IP ani ręcznej trasy. Jeśli go brakuje, wyjaśnić build i konfigurację zamiast tworzyć interfejs zastępczy.
• Kilka tuneli wpływa na siebie: prawdopodobnie istnieją nakładające się sieci lub podobne konfiguracje Selector. Sprawdzić obiekty tuneli, Failover Group i trasy.

Rollback po nieudanej akceptacji

Nowy tunel należy wycofać w sposób kontrolowany, zamiast usuwać reguły i obiekty na podstawie przypuszczeń:

1. W Current activities > IPsec connections zakończyć odpowiednią SA za pomocą Disconnect i wyłączyć nowe połączenie IPsec.
2. Wyłączyć tylko trasy statyczne lub SD-WAN, reguły NAT i reguły firewall utworzone dla tej zmiany, w tym automatycznie wygenerowane reguły VPN. Nie usuwać oddzielnie wygenerowanego interfejsu XFRM; wyłączenie połączenia zarządza tym interfejsem.
3. Przy migracji ponownie przypisać poprzedni profil do starego połączenia, a następnie aktywować połączenie i starą ścieżkę routingu.
4. Ponownie sprawdzić pierwotny przepływ testowy oraz lokalny ruch internetowy lub ruch między lokalizacjami za pomocą Log Viewer i Packet Capture.
5. Nowe obiekty usuwać dopiero wtedy, gdy Object Usage nie wykazuje dalszych zależności, a działanie starej ścieżki zostało jednoznacznie potwierdzone.

Usunięcie konkretnego zapisanego połączenia

Usunięcie zapisanego połączenia IPsec różni się od Disconnect, dezaktywacji czy usunięcia grupy failover. Przed oddzielnie zatwierdzonym usunięciem udokumentować dokładną istniejącą wartość Name, Object Usage, członkostwo w grupach i dostęp administracyjny niezależny od tunelu. Nie usuwać połączenia, dopóki należy do grupy failover; podlinkowana procedura failover opisuje kontrolowane usunięcie przypisania.

Dokumentacja usuwania przez API XML dla SFOS 22 i SFOS 23 określa Name jako obowiązkowe ARRAY o typie danych STRING: pierwszy znak A-Za-z, kolejne A-Za-z0-9_, maksymalnie 100 znaków, wiele wartości dozwolonych. Nie zawiera jednak przykładu żądania. Nie wyprowadzać z tego serializatora wielu nazw ani nazwy celu z przykładu GUI branch-zurich; nie przepisywać zapisanej nazwy, aby pozornie dostosować ją do tych wymagań.

Dokumentacja przypisuje status operacji XML 200 do Message.IPSecDeleteSuccess, 201 do Message.IPSecConnInUse, a 500 do Message.IPSecDeleteFail. Teksty komunikatów są wstawiane przez JavaScript i nie zostały tu odtworzone: nie są to kody statusu HTTP ani potwierdzone teksty wyświetlanych odpowiedzi. Nie uznawać 201 za udane usunięcie tylko dlatego, że liczba zaczyna się od 2; dla Edit ta sama liczba odpowiada Message.IPSecUpdated. Po zatwierdzonym usunięciu odczytać ponownie dokładnie ten cel i sprawdzić pozostałe ścieżki produkcyjne. Przy niejasnym wyniku najpierw wyjaśnić stan celu i zależności, a dopiero potem rozważyć ponowienie; nie powtarzać w ciemno.

Lista kontrolna

Przed zmianą:

• Sieci lokalne i zdalne są jednoznaczne.
• Policy-based lub route-based wybrano świadomie.
• Profil IPsec jest uzgodniony ze stroną zdalną.
• Preshared Key, certyfikaty lub klucze RSA są bezpiecznie udokumentowane.
• Reguły firewall są zaplanowane, wraz z kierunkiem, pozycją, loggingiem i usługami.
• Przy Create firewall rule wiadomo, które automatycznie utworzone reguły trzeba poprawić.
• Dla route-based Any-to-Any zaplanowano adres IP XFRM, gateway, ręczne reguły firewall i trasy.
• Dla route-based Traffic Selectors udokumentowano rzeczywistą widoczność interfejsu XFRM; niezależnie od tego, czy jest wyświetlany, nie zaplanowano adresu IP XFRM ani ręcznej trasy.
• NAT jest wykluczony albo świadomie udokumentowany.
• Device Access dla przychodzącego IPsec został sprawdzony.
• Okno serwisowe, strona zdalna i ścieżka awaryjna są znane.

Po zmianie:

• Status tunelu jest established.
• Macierz odbioru z co najmniej jednym testem dla każdego wymaganego kierunku została wykonana i zaliczona.
• 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