Migracja Legacy Remote Access IPsec przed SFOS 22 MR1
W SFOS 22.0 MR1 Sophos ostatecznie usunął Legacy Remote Access IPsec VPN z obsługiwanej ścieżki aktualizacji. Firewalle, na których taka stara konfiguracja Remote Access IPsec nadal istnieje, nie mogą zostać zaktualizowane do SFOS 22.0 MR1 ani nowszych wersji.
Ten artykuł opisuje, jak przed aktualizacją firmware rozpoznać starą konfigurację, poprawnie ją udokumentować, zastąpić aktualnym rozwiązaniem Remote Access i dopiero potem usunąć. Do ogólnego sprawdzenia przed aktualizacją pasuje dodatkowo Sprawdzenie Sophos Firewall przed aktualizacją do SFOS 22.
Czym jest Legacy Remote Access IPsec
Sophos przez lata wspierał kilka sposobów Remote Access. Dlatego w wielu środowiskach nie od razu widać, czy chodzi o aktualną konfigurację IPsec, stary wpis legacy, SSL VPN czy Sophos Connect.
Dla aktualizacji do SFOS 22 MR1 najważniejsze jest:
- Legacy Remote Access IPsec to stary typ konfiguracji, który może blokować aktualizację.
- Aktualny Remote Access IPsec to docelowa ścieżka, jeśli IPsec ma być nadal używany.
- SSL VPN może być alternatywą, jeśli IPsec jest regularnie blokowany w hotelach, sieciach gościnnych lub środowiskach mobilnych.
- ZTNA może mieć sens, jeśli nie jest już potrzebny pełny Client VPN, lecz dostęp do pojedynczych aplikacji.
Ta różnica jest operacyjnie ważna. Zielony status VPN lub działający Sophos Connect Client nie dowodzi automatycznie, że na firewallu nie ma już konfiguracji legacy.
Łatwo przeoczyć ważny przypadek restore: kopie zapasowe lub importowane konfiguracje mogą zawierać Legacy Remote Access IPsec, ale ta konfiguracja legacy nie jest automatycznie migrowana. Po restore, wymianie sprzętu lub imporcie konfiguracji należy więc ponownie sprawdzić ten punkt, nawet jeśli firewall wcześniej wyglądał na oczyszczony.
Kiedy należy migrować
Migracja powinna być zakończona przed planowaną aktualizacją do SFOS 22 MR1. Tego przejścia nie należy wykonywać dopiero w oknie konserwacyjnym aktualizacji firmware, ponieważ Remote Access często dotyczy użytkowników, certyfikatów, MFA, DNS, reguł firewalla i konfiguracji klientów.
Typowe wyzwalacze:
- Sophos Firewall ma zostać zaktualizowany do SFOS 22.0 MR1 lub nowszej wersji.
- Strona firmware albo dokumentacja Sophos wskazuje na Legacy Remote Access IPsec.
- W środowisku istnieją stare profile Sophos Connect, których od lat nie sprawdzano.
- Użytkownicy zgłaszają powtarzające się problemy z Remote Access po zmianach profilu lub klienta.
- Remote Access i tak ma zostać ponownie oceniony pod kątem MFA, Entra ID SSO, SSL VPN lub ZTNA.
Jeśli Remote Access jest krytyczny biznesowo, migrację należy traktować jako osobny projekt zmiany. Aktualizacja firmware jest wtedy tylko powodem, a nie całym zakresem prac.
Dokumentacja przed migracją
Najpierw dokumentuje się stan bieżący. Ten krok jest ważniejszy, niż wygląda, ponieważ wiele konfiguracji VPN nie składa się tylko z jednego profilu tunelu. Często zależą od niej grupy użytkowników, pule IP, ustawienia DNS, reguły firewalla, wyjątki NAT i pliki klientów.
Sprawdzenie konfiguracji legacy w WebAdmin
Przed planowaniem docelowym należy jednoznacznie ustalić, czy rzeczywiście dotyczy to Legacy Remote Access IPsec. Ten check jest potrzebny nie tylko przed aktualizacją firmware, lecz także po restore, wymianie sprzętu lub imporcie konfiguracji.
Praktyczny przebieg:
- Otwórz Remote access VPN > IPsec (legacy), jeśli ten punkt menu jest widoczny w zainstalowanej wersji SFOS.
- Sprawdź, czy Legacy Remote Access IPsec jest aktywny albo czy nadal istnieją obiekty konfiguracyjne.
- Otwórz Remote access VPN > IPsec i osobno udokumentuj aktualną konfigurację Remote Access IPsec.
- Sprawdź Authentication > Users i grupy użytkowników, jeśli używano statycznych adresów IP, lokalnych użytkowników lub starych przypisań grup.
- Przeszukaj Rules and policies > Firewall rules pod kątem reguł ze strefy
VPNdoLAN,DMZlubWAN. - Sprawdź Administration > Device access, czy IPsec, VPN Portal, DNS lub Ping są osiągalne z wymaganych stref.
- Ponownie otwórz stronę firmware i sprawdź, czy nadal wyświetlany jest blocker aktualizacji.
Jeśli obszar legacy nie jest już widoczny, ale aktualizacja nadal jest blokowana, nie należy usuwać obiektów na wyczucie. Wtedy ważniejsze są zrzut ekranu komunikatu, aktualna kopia zapasowa i przejrzysta lista obiektów niż nerwowe sprzątanie w oknie konserwacyjnym.
Należy udokumentować co najmniej:
| Obszar | Co należy sprawdzić |
|---|---|
| Użytkownicy i grupy | Którzy użytkownicy mogą używać Remote Access? Czy używani są użytkownicy lokalni, AD, RADIUS lub Entra ID? |
| Uwierzytelnianie | Hasło, MFA, certyfikat, Preshared Key lub zależności SSO |
| Pula IP | Jakie adresy otrzymują klienci VPN? Czy istnieją konflikty z LAN, WLAN, VLAN lub innymi VPN? |
| DNS | Jakie serwery DNS i domeny są przekazywane klientom? |
| Dostęp | Jakie sieci wewnętrzne, serwery i usługi muszą być osiągalne? |
| Reguły firewalla | Jakie reguły dopuszczają ruch z VPN do LAN, DMZ lub WAN? |
| Dystrybucja klientów | Gdzie znajdują się aktualne profile Sophos Connect lub konfiguracje SSL VPN? |
| Operacje | Kto może poinformować użytkowników, dystrybuować profile i przyjmować błędy? |
Jeśli już występują problemy z routingiem lub ruchem przez tunel, nie należy przenosić ich bez sprawdzenia do nowej konfiguracji. W analizie pomaga Troubleshooting Sophos Firewall IPsec VPN.
Wybór ścieżki docelowej
Nie ma jednego właściwego zamiennika dla Legacy Remote Access IPsec. Wybór zależy od tego, czego użytkownicy naprawdę potrzebują i jak środowisko jest utrzymywane.
Aktualny Remote Access IPsec
Aktualny Remote Access IPsec jest oczywistym wyborem, jeśli Sophos Connect z IPsec ma być nadal używany i środowisko zasadniczo działało z nim dobrze. IPsec jest często wydajny, ale w restrykcyjnych sieciach zewnętrznych może zwracać uwagę przez blokowane porty UDP lub szczególne przypadki NAT.
Ta ścieżka pasuje dobrze, jeśli:
- Sophos Connect jest już dystrybuowany
- użytkownicy pracują głównie z Windows lub macOS
- IPsec był dotychczas stabilny
- sieci wewnętrzne mają być osiągalne przez klasyczne reguły firewalla
Istniejąca instrukcja Konfiguracja Sophos Connect Client na Sophos Firewall może służyć jako podstawa, ale musi zostać porównana z aktualnymi wersjami SFOS i własnym projektem uwierzytelniania.
SSL VPN
SSL VPN ma sens, jeśli Remote Access ma możliwie niezawodnie działać przez różne sieci zewnętrzne. W zależności od środowiska SSL VPN może być prostszy, ale powoduje inne pytania dotyczące wydajności i klienta. Dla Windows istnieje instrukcja Instalacja Sophos Connect SSL VPN Client.
Ta ścieżka pasuje dobrze, jeśli:
- użytkownicy często pracują w hotelach, gościnnych WLAN lub obcych sieciach firmowych
- połączenia IPsec regularnie zawodzą przez ograniczenia sieci
- istniejące procesy SSL VPN są już wdrożone
- znaczenie mają platformy mobilne lub zewnętrzni klienci OpenVPN
ZTNA lub Clientless Access
Jeśli użytkownicy potrzebują tylko pojedynczych aplikacji webowych albo zdefiniowanych aplikacji wewnętrznych, należy sprawdzić, czy klasyczny pełny tunel VPN nadal jest właściwym rozwiązaniem. ZTNA nie zastępuje bezpośrednio każdego scenariusza VPN, ale w jasno ograniczonych przypadkach użycia może być lepszą architekturą.
Istniejący artykuł Sophos ZTNA Gateway Connector jest dobrym punktem startowym. Dla prostego dostępu webowego znaczenie może mieć również Clientless Access, jeśli wymagania do niego pasują.
Budowa nowej konfiguracji Remote Access
Nową konfigurację należy przygotować równolegle, zanim stara zostanie usunięta. Celem nie jest przeniesienie wszystkich użytkowników jednocześnie do nieprzetestowanego setupu.
Zalecany przebieg:
- Ustal wariant docelowy: aktualny Remote Access IPsec, SSL VPN, ZTNA lub kombinacja.
- Wybierz nową pulę IP i sprawdź nakładanie się adresów.
- Ustal źródło uwierzytelniania i MFA.
- Przypisz wymaganych użytkowników lub grupy.
- Zdefiniuj serwery DNS i domeny wewnętrzne.
- Utwórz reguły firewalla dla nowych źródeł VPN.
- Wygeneruj profil testowy dla kilku użytkowników.
- Przetestuj połączenie na co najmniej dwóch różnych łączach sieciowych.
- Dopiero potem zaplanuj komunikację z użytkownikami i rollout.
MFA w Remote Access nie powinno być traktowane jako opcjonalny detal. Jeśli VPN jest osiągalny globalnie, MFA, czyste grupy użytkowników, logging i przegląd ustawień Device Access należą do jednego pakietu. Artykuł Konfiguracja MFA w Sophos Firewall obejmuje podstawy.
Planowanie koegzystencji i drogi powrotu
Nowe rozwiązanie Remote Access należy najpierw przetestować obok starej konfiguracji. Dzięki temu można stopniowo migrować użytkowników i w przypadku błędów wracać celowo, bez jednoczesnej zmiany Remote Access, reguł firewalla, DNS, MFA i dystrybucji klientów w tym samym oknie konserwacyjnym.
Ważne jest jednak, aby koegzystencję zaplanować czysto. Nowa konfiguracja nie powinna używać tej samej puli IP, tych samych niejasno nazwanych reguł firewalla ani tych samych nazw profili co stara konfiguracja legacy. W przeciwnym razie później w Log Viewer nie będzie już widać, który dostęp faktycznie połączył użytkownika.
Przed pilotażem powinny być ustalone:
| Punkt | Zalecenie |
|---|---|
| Grupa pilotażowa | kilku technicznie dostępnych użytkowników z różnymi urządzeniami i sieciami |
| Pula IP | osobny zakres bez nakładania się z LAN, WLAN, Site-to-Site VPN lub starym Remote Access |
| Reguły firewalla | osobne, jasno nazwane reguły dla nowej puli VPN |
| Profile klientów | nowa nazwa profilu, aby użytkownicy mogli odróżnić stare i nowe połączenie |
| Kryterium powrotu | z góry określić, kiedy wraca się do starego połączenia |
| Okno wsparcia | helpdesk lub administrator musi być dostępny podczas pilotażu |
Droga powrotu nie oznacza stałego utrzymywania konfiguracji legacy. Służy tylko do kontrolowanego przerwania pilotażu, jeśli logowanie, MFA, DNS, routing lub kluczowe aplikacje nie działają. Gdy nowe rozwiązanie jest stabilne, stara konfiguracja powinna zostać usunięta, a blocker aktualizacji ponownie sprawdzony.
Testy przed usunięciem konfiguracji legacy
Starą konfigurację należy usunąć dopiero wtedy, gdy rozwiązanie zastępcze zostało przetestowane. W przeciwnym razie problem aktualizacji jest wprawdzie rozwiązany, ale Remote Access może produkcyjnie przestać działać.
Test funkcjonalny
Należy sprawdzić co najmniej:
- logowanie użytkownikiem testowym działa
- MFA lub SSO jest wywoływane zgodnie z oczekiwaniem
- klient otrzymuje właściwy adres VPN-IP
- wewnętrzne nazwy DNS są rozwiązywane
- centralne serwery są osiągalne
- zachowanie internetu odpowiada projektowi: Split Tunnel albo Full Tunnel
- wylogowanie i ponowne zalogowanie działają
Test firewalla i routingu
W Log Viewer należy sprawdzić, czy ruch ze strefy VPN trafia w oczekiwane reguły. Jeśli ruch jest odrzucany, nie należy sprawdzać tylko konfiguracji VPN, lecz także regułę firewalla, NAT, Route Precedence i drogę powrotną. Dla pojedynczych połączeń pomocny jest artykuł Testowanie reguły firewalla przy użyciu Log Viewer, Policy Test i Packet Capture.
Test klienta
W przypadku Sophos Connect istniejące profile nie powinny być po cichu nadpisywane. Lepszy jest mały pilotaż z jasną informacją zwrotną:
- Czy klient importuje nową konfigurację?
- Czy stare połączenie zostaje dla użytkownika zrozumiale zastąpione?
- Czy zestawianie połączenia działa po restarcie?
- Czy sufiksy DNS, trasy i zapisane połączenia są poprawne?
- Czy występują różnice między Windows i macOS?
Przed szerokim rolloutem należy sprawdzić również używaną wersję klienta. Do tego pasuje Sprawdzenie wersji Sophos Connect Client i bezpieczna aktualizacja.
Usunięcie konfiguracji legacy
Gdy nowe rozwiązanie zostało produkcyjnie przetestowane, można usunąć konfigurację legacy. Wcześniej należy jeszcze raz utworzyć aktualną kopię zapasową. Jest to szczególnie ważne, jeśli w tej samej zmianie dostosowywane są także reguły firewalla, grupy użytkowników lub serwery uwierzytelniania.
Praktyczny przebieg:
- Utwórz świeżą kopię zapasową.
- Poinformuj aktywnych użytkowników o oknie konserwacyjnym.
- Pozostaw nową konfigurację Remote Access aktywną.
- Usuń Legacy Remote Access IPsec w WebAdmin.
- Sprawdź stare profile, pule IP i reguły, które nie są już potrzebne.
- Ponownie otwórz stronę firmware i sprawdź, czy blocker aktualizacji zniknął.
- Udokumentuj wynik.
Nie należy od razu usuwać wszystkiego, co wygląda staro. Stare reguły firewalla, hosty lub grupy mogą być używane również dla Site-to-Site VPN, SSL VPN lub innych celów. Najpierw należy sprawdzić zależności, potem porządkować.
Po restore lub imporcie konfiguracji kontrolę należy powtórzyć. Kopia zapasowa może zawierać stare obiekty legacy, ale nie oznacza to automatycznie aktualnej konfiguracji Remote Access IPsec. Dla eksploatacji i dokumentacji decydujące jest więc, czy docelowa konfiguracja produkcyjna została rzeczywiście zbudowana od nowa, przetestowana i rozdystrybuowana.
Troubleshooting
Aktualizacja nadal jest blokowana
Jeśli aktualizacja nadal jest blokowana mimo usunięcia widocznej konfiguracji legacy, najpierw należy przeładować firewall albo ponownie otworzyć obszar firmware. Następnie sprawdzić, czy rzeczywiście usunięto wszystkie obiekty Legacy Remote Access. Jeśli nadal nie jest jasne, który obiekt blokuje aktualizację, należy przygotować Sophos Support Case ze zrzutem ekranu komunikatu aktualizacji i aktualną kopią zapasową.
Po restore pytanie o legacy pojawia się ponownie
Po restore, wymianie sprzętu lub imporcie starej konfiguracji należy ponownie sprawdzić Remote Access. Decydujące nie jest to, czy wcześniejsza zmiana została kiedyś zakończona, lecz co znajduje się w aktualnie działającej konfiguracji. Stare kopie zapasowe mogą przywrócić historyczne obiekty Remote Access albo wywołać nową kontrolę ścieżki aktualizacji.
Użytkownicy nie mogą się zalogować
Przy problemach z logowaniem najpierw należy sprawdzić uwierzytelnianie, MFA, grupę użytkowników i VPN policy. Jeśli używane są RADIUS, AD lub Entra ID, połączenie z serwerem należy przetestować niezależnie od VPN. Problem z VPN nie zawsze jest problemem IPsec.
Połączenie działa, ale systemy wewnętrzne nie są osiągalne
Wtedy przyczyna często leży w regułach firewalla, NAT, DNS lub routingu. Należy sprawdzić, czy klient otrzymuje właściwy adres VPN-IP, czy nazwy wewnętrzne są poprawnie rozwiązywane i czy ruch w Log Viewer trafia w oczekiwaną regułę.
Pojedyncze sieci działają, inne nie
W takim przypadku często znaczenie mają sieci Split Tunnel, trasy IPsec, trasy statyczne albo brakujące trasy powrotne. W scenariuszach IPsec sensownym artykułem uzupełniającym jest Trasa IPsec na Sophos Firewall.
Checklista
Przed rolloutem
- Legacy Remote Access IPsec zidentyfikowany
- użytkownicy, grupy, pula IP, DNS i reguły firewalla udokumentowane
- ścieżka docelowa wybrana: aktualny IPsec, SSL VPN, ZTNA lub kombinacja
- MFA i uwierzytelnianie sprawdzone
- Device Access dla IPsec, VPN Portal, DNS i Ping sprawdzony
- koegzystencja i kryterium powrotu zdefiniowane
- użytkownicy testowi zdefiniowani
- kopia zapasowa utworzona
Podczas rollouta
- nowa konfiguracja przetestowana z użytkownikami pilotażowymi
- profile klientów rozdystrybuowane
- Log Viewer i dotknięte reguły firewalla sprawdzone
- droga powrotu zakomunikowana
- zebrano feedback użytkowników
Po migracji
- konfiguracja legacy usunięta
- blocker aktualizacji ponownie sprawdzony
- scenariusz restore i importu udokumentowany
- stare profile i reguły sprawdzone pod kątem zależności
- dokumentacja zaktualizowana
- aktualizacja firmware zaplanowana dopiero potem