Konfiguracja IPsec Site-to-Site z certyfikatami w Sophos Firewall
Wspólną preshared key można szybko skonfigurować dla pojedynczego tunelu między lokalizacjami. Przy większej liczbie firewalli lub bardziej rygorystycznych wymaganiach PKI digital certificate jest często łatwiejszy do kontrolowania: każda strona ma własny klucz prywatny, peery ufają wystawiającym CA, a pojedynczy certyfikat można selektywnie odnowić lub unieważnić.
Ta procedura przedstawia połączenie policy-based IPsec między dwiema Sophos Firewall. Uzupełnia ogólny poradnik konfiguracji VPN IPsec Site-to-Site. Projekty route-based wymagają dodatkowo zaplanowania routingu i XFRM, ale opisany tu proces zaufania i certyfikatów pozostaje taki sam.
Bezpieczna procedura w ośmiu krokach
- Udokumentować role tunelu, sieci, profil IKEv2 oraz Certificate ID.
- Sprawdzić backup konfiguracji i działający dostęp administracyjny na obu firewallach.
- Wyeksportować CA wystawiający z każdego firewalla i zaimportować go na peerze.
- Wygenerować na każdym firewallu osobny certyfikat podpisany lokalnie z unikatowym Certificate ID.
- Wyeksportować tylko certyfikat publiczny i zaimportować go na peerze jako Remote Certificate.
- Utworzyć po obu stronach policy-based IPsec z Authentication type > Digital certificate.
- Dokładnie sprawdzić Device Access i automatycznie utworzone reguły firewalla.
- Zweryfikować stan tunelu, zaufanie do certyfikatów, logi oraz rzeczywisty ruch w obu kierunkach.
⚠️ Plik klucza prywatnego pozostaje na firewallu, na którym wygenerowano certyfikat. Do wymiany zaufania przesyłane są wyłącznie certyfikaty CA i publiczne certyfikaty peerów. Bez przetestowanego drugiego dostępu administracyjnego, backupu i udokumentowanej drogi odzyskiwania nie należy wyłączać istniejących tuneli PSK ani zastępować certyfikatów produkcyjnych.
Przykład i wartości planowania
Przykład łączy centralę SF1 z oddziałem SF2:
SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN
- WAN SF1:
172.10.10.1 - WAN SF2:
172.20.20.1 - Certyfikat SF1:
SF1_Certificate - Certyfikat SF2:
SF2_Certificate - Certificate ID SF1:
172.10.10.1 - Certificate ID SF2:
172.20.20.1
Te adresy i nazwy są wartościami dokumentacyjnymi. W rzeczywistym środowisku należy użyć właściwych adresów WAN, obiektów sieciowych i unikatowego w całej organizacji schematu ID. Certificate ID musi być trwale przypisany do odpowiedniego peera i nie wolno go mylić z nazwą wyświetlaną ani dowolnym SAN.
Ustanowienie wzajemnego zaufania CA
Najpierw na SF1 należy sprawdzić i pobrać CA wystawiający w Certificates > Certificate authorities. Jeśli w przykładzie używany jest lokalny CA Default, wyeksportowanemu plikowi należy nadać jednoznaczną nazwę, taką jak Head_Office_Default.pem. Na SF2 należy go zaimportować w Certificates > Certificate authorities > Add, na przykład jako SF1_CA.
Następnie należy powtórzyć procedurę w przeciwnym kierunku: wyeksportować CA z SF2, nadać mu jednoznaczną nazwę, taką jak Branch_Office_Default.pem, i zaimportować na SF1, na przykład jako SF2_CA.
Nazwy plików służą wyłącznie do administracji. Istotne są Subject, Issuer, Fingerprint, okres ważności i prawidłowy łańcuch CA. Przed importem należy porównać te wartości niezależnym kanałem. Artykuł Zarządzanie certyfikatami w Sophos Firewall opisuje ogólne zadania związane z CA, certyfikatami i przypisywaniem ich do usług.
Nie należy przy okazji ponownie generować wbudowanego CA
Default. Regeneracja zmienia Trust Anchor i może wpłynąć na inne portale, usługi TLS oraz peery IPsec. W przypadku firmowego CA należy zamiast tego zaimportować cały zaufany łańcuch.
Przygotowanie certyfikatów lokalnych i zdalnych
Utworzenie lokalnego certyfikatu na SF1
Na SF1 należy utworzyć certyfikat w Certificates > Certificates > Add > Generate locally-signed certificate. Przykład Sophos używa RSA, Key length 2048 oraz SHA-256. Wartości te nie zastępują polityki kryptograficznej i okresu ważności organizacji; wybrany profil IPsec i oba peery muszą je obsługiwać.
W Subject Alternative Names (SANs) > Advanced settings należy wybrać Certificate ID. Obsługiwane typy to DNS, IP address, Email oraz DER ASN1 DN [X.509]. W przykładzie użyto IP address z wartością 172.10.10.1.
Przy DER ASN1 DN [X.509] Sophos używa Subject wystawiającego CA. W takim przypadku pola DNS names i IP address w SAN należy pozostawić puste, ponieważ według Sophos dodatkowe wartości powodują konflikt podczas uwierzytelniania IPsec.
Po wybraniu Save należy sprawdzić ważność, Issuer, Certificate ID oraz obecność klucza prywatnego. Następnie wyeksportować certyfikat publiczny, w razie potrzeby zmienić rozszerzenie na .cer i zaimportować go na SF2 w Certificates > Certificates > Add > Upload certificate jako SF1_Certificate. Kolumna Trusted na peerze musi potwierdzać zaufanie za pośrednictwem SF1_CA.
Utworzenie lokalnego certyfikatu na SF2
Na SF2 należy powtórzyć procedurę z osobnym kluczem prywatnym. W przykładzie certyfikat nosi nazwę SF2_Certificate, jego Certificate ID to 172.20.20.1, a wystawiającym CA jest lokalny CA na SF2.
Certyfikat publiczny należy zaimportować na SF1. Tam Trusted musi zostać potwierdzone za pośrednictwem wcześniej zaimportowanego SF2_CA. Każdy firewall ma teraz dokładnie dwie różne role:
- Local certificate: własny certyfikat z kluczem prywatnym.
- Remote certificate: publiczny certyfikat peera zweryfikowany przez jego CA.
Zielony znacznik zaufania potwierdza łańcuch certyfikatów, ale nie działanie tunelu. Okres ważności, Certificate ID, profil IKE, gateway i sieci nadal muszą być zgodne. Unieważnianie i dystrybucja CRL stanowią osobny proces operacyjny; zobacz Certificate Revocation Lists w Sophos Firewall.
Utworzenie połączenia IPsec po obu stronach
W Site-to-site VPN > IPsec > Add należy utworzyć dwa zgodne połączenia. W przykładzie centrala oczekuje na oddział:
- Connection type:
Policy-based - Gateway type:
Respond only - Profile:
Head office (IKEv2)lub uzgodniony klon własnego profilu - Authentication type:
Digital certificate - Local certificate:
SF1_Certificate - Remote certificate:
SF2_Certificate - Listening interface: WAN na
SF1 - Local subnet:
SF1_LAN - Gateway address: adres WAN
SF2 - Remote subnet:
SF2_LAN
W oddziale należy odwrócić role:
- Gateway type:
Initiate the connection - Profile:
Branch office (IKEv2)lub odpowiadający mu własny profil - Local certificate:
SF2_Certificate - Remote certificate:
SF1_Certificate - Local subnet:
SF2_LAN - Gateway address: adres WAN
SF1 - Remote subnet:
SF1_LAN
Profile należy planować jako parę. Artykuł Profile IPsec w Sophos Firewall wyjaśnia współdziałanie IKEv2, fazy 1, fazy 2, PFS, lifetime i DPD.
Sprawdzenie Device Access i reguł firewalla
Strona z Gateway type > Respond only musi móc przyjmować połączenia IPsec na przewidzianej ścieżce WAN. Dlatego w Administration > Device access należy włączyć IPsec tylko dla faktycznie wymaganej strefy WAN albo użyć ograniczonego wyjątku Local Service ACL dla znanych adresów peerów. SSO, certyfikaty ani silny algorytm IPsec nie uzasadniają szerokiego dostępu do WebAdmin lub SSH. Artykuł Bezpieczna konfiguracja Device Access w Sophos Firewall opisuje planowanie ACL.
Gdy włączone jest Create firewall rule, SFOS tworzy automatyczne reguły VPN. Są one punktem wyjścia. W Rules and policies > Firewall rules należy sprawdzić kolejność, kierunek, sieci źródłowe i docelowe, usługi oraz logging, a następnie ograniczyć reguły do rzeczywistych potrzeb. Artykuł Tworzenie reguł firewalla w Sophos Firewall opisuje ich weryfikację.
Ping/Ping6 dla strefy VPN jest potrzebny tylko wtedy, gdy jako cel testu celowo ma służyć adres samego firewalla. W zwykłym teście end-to-end między hostami za firewallami nie trzeba szeroko włączać tej usługi lokalnej.
Weryfikacja tunelu i certyfikatów
Weryfikacja rozdziela cztery poziomy:
- W Site-to-site VPN > IPsec połączenie i tunel są aktywne.
- Oba firewalle pokazują oczekiwane Local i Remote Certificate, prawidłowe okresy ważności oraz zaufanego Issuer.
- Rzeczywisty host testowy osiąga zamierzoną usługę w sieci zdalnej, a następnie testowany jest kierunek przeciwny.
- Firewall Rule ID, Packet Capture i logi IPsec potwierdzają tę samą ścieżkę i te same znaczniki czasu.
strongswan.log jest głównym punktem wyjścia dla błędów IKE i certyfikatów. Dodatkowych danych dostarczają charon.log, ipsec_monitor.log i log konkretnego połączenia w /log/ipsec_conn/. Artykuł Troubleshooting IPsec w Sophos Firewall opisuje pełną procedurę diagnostyczną.
Zawężanie błędów według objawu
Tunel pozostaje down
Najpierw należy potwierdzić, że Local certificate i Remote certificate są rzeczywiście odwrócone po obu stronach. Następnie sprawdzić Certificate ID, Gateway address, profil IKEv2, ważność i łańcuch zaufania. Zaimportowany certyfikat peera bez odpowiadającego mu CA nie jest zaufanym dowodem tożsamości.
Certyfikat jest Trusted, ale uwierzytelnianie nadal się nie udaje
Trusted potwierdza tylko łańcuch. Przy DER ASN1 DN [X.509] żadne dodatkowe wartości DNS lub IP w SAN nie mogą nadpisywać identyfikatora. W przypadku pozostałych typów ID wartość, typ i oczekiwany peer muszą być dokładnie zgodne. W strongswan.log należy porównać rzeczywiście oferowane i oczekiwane ID dla tej samej próby połączenia.
Tunel jest zielony, ale ruch nie przepływa
Uwierzytelnianie certyfikatem już się powiodło. Teraz należy sprawdzić lokalne i zdalne podsieci, automatyczne reguły VPN, Rule ID, NAT, trasę powrotną oraz właściwą usługę docelową. Ponowne generowanie certyfikatów bez dowodów jedynie zaciera pierwotny stan w tym scenariuszu.
Certyfikat wkrótce wygaśnie
Nowy lokalny certyfikat należy przygotować równolegle, przekazać jego część publiczną peerowi i potwierdzić tam zaufanie. Dopiero w oknie serwisowym należy w kontrolowany sposób zmienić Local certificate i Remote certificate po obu stronach. Stare certyfikaty i CA należy zachować do pomyślnego zakończenia weryfikacji dwukierunkowej, a usunąć lub unieważnić dopiero później.
Rollback i eksploatacja
Przed zmianą należy udokumentować oba połączenia IPsec, nazwy certyfikatów, Fingerprint, Certificate ID, okresy ważności i bieżącą kolejność reguł. Backup konfiguracji Sophos Firewall jest częścią przygotowania, ale nie zastępuje bezpośredniego dostępu awaryjnego do firewalla.
Jeśli weryfikacja się nie powiedzie, należy przywrócić wcześniejsze przypisania certyfikatów albo ponownie aktywować nadal dostępny tunel PSK. Nowo zaimportowane certyfikaty peerów lub CA można usunąć dopiero po potwierdzeniu, że nie korzysta z nich żadne inne połączenie ani usługa. Następnie należy ponownie sprawdzić stan tunelu i rzeczywisty przepływ testowy.
W eksploatacji certyfikaty wymagają właściciela, monitorowania daty wygaśnięcia i zaplanowanego okna odnowienia. Pierwszy alert powinien pozostawiać wystarczająco dużo czasu na wystawienie, dystrybucję zaufania, test równoległy i rollback. Wymiana certyfikatu dopiero w dniu wygaśnięcia zmienia planowaną konserwację w awarię VPN.