Konfiguracja i testowanie L2TP Remote Access na Sophos Firewall

L2TP Remote Access jest nadal dostępny na Sophos Firewall, ale nie powinien automatycznie być pierwszym wyborem dla nowych zarządzanych endpointów. Sophos Connect z IPsec lub SSL VPN jest łatwiejszy w centralnym zarządzaniu i zapewnia pełniejszą ścieżkę klienta Sophos. L2TP pozostaje przydatny, gdy system operacyjny musi korzystać z natywnego klienta VPN albo gdy istniejące zgodne środowisko ma być dalej eksploatowane w kontrolowany sposób.

Ocena dla nowych środowisk: Porównane strony pomocy dla SFOS 22 i 23 wymieniają L2TP jako konfigurowalny typ dostępu zdalnego. Potwierdza to udokumentowany zakres funkcji, a nie dostępność w każdym buildzie ani gwarancję obsługi w późniejszych wersjach głównych. Avanet nie zaleca L2TP jako nowego standardu dla zarządzanych klientów. Nowego dostępu L2TP nie należy wdrażać bez konkretnego wymagania dotyczącego obsługi starszego środowiska lub zgodności.

Sam L2TP definiuje tunel, a nie wymaganą ochronę. Na Sophos Firewall połączenie zabezpiecza polityka IPsec. Profil IPsec, uwierzytelnianie, preshared key lub certyfikat oraz konfiguracja klienta muszą więc do siebie pasować. Zielony stan Active oznacza ponadto tylko, że polityka jest aktywna; dopiero stan Connection i rzeczywisty ruch potwierdzają działanie tunelu.

⚠️ Route Precedence wymagana przez Sophos dla L2TP ustawia globalnie vpn przed Static i SD-WAN Policy Routes. Nowa polityka L2TP z peerem wildcard może też wpłynąć na istniejące preshared keys. Przed zmianą trzeba udokumentować bieżącą kolejność, niezależną ścieżkę zarządzania oraz wszystkie pozostałe ścieżki VPN, Static i SD-WAN.

L2TP w ośmiu krokach

1. Sprawdzić, czy L2TP jest rzeczywiście potrzebny oraz czy klient, profil IPsec i uwierzytelnianie są zgodne.
2. Zaplanować niepokrywający się prywatny zakres dzierżaw, wewnętrzne serwery DNS i ściśle ograniczoną grupę użytkowników.
3. W Remote access VPN > L2TP > L2TP global settings włączyć L2TP i dodać użytkowników.
4. Utworzyć politykę L2TP z właściwym profilem IPsec, portem WAN, uwierzytelnianiem i NAT Traversal.
5. W Administration > Device access zezwolić na usługę IPsec dla wymaganej dostępności od strony WAN.
6. Zapisać bieżącą Route Precedence i w kontrolowanej zmianie ustawić vpn na pierwszym miejscu.
7. Utworzyć wąską, logowaną regułę firewall ze strefy VPN do rzeczywiście wymaganych celów wewnętrznych.
8. Z zewnętrznym klientem pilotażowym sprawdzić uwierzytelnianie, adres dzierżawy, DNS, regułę, ścieżkę powrotną i test negatywny.

Kiedy L2TP jest odpowiedni

L2TP może być przydatny dla natywnych klientów systemu operacyjnego lub istniejących urządzeń, na których nie przewidziano Sophos Connect. Jest też rozsądnym wyborem, gdy niewielkie, już udokumentowane środowisko L2TP ma działać dalej bez dodatkowego oprogramowania klienckiego.

W nowym standardowym wdrożeniu zwykle lepiej sprawdza się Sophos Connect z IPsec lub SSL VPN. Dystrybucja profili, diagnostyka klienta i specyficzna dla Sophos ścieżka wsparcia są tam bardziej przejrzyste. W przypadku pojedynczych aplikacji Clientless SSL VPN może zapewnić dostęp przez przeglądarkę bez pełnego tunelu sieciowego. PPTP nie jest nowoczesnym rozwiązaniem zastępczym: sam protokół nie definiuje ani szyfrowania, ani uwierzytelniania; dostępne metody logowania nie czynią z niego bezpiecznej architektury docelowej dla nowych wdrożeń.

Przed konfiguracją trzeba znać trzy ograniczenia:

• Na Sophos Firewall L2TP korzysta z jednej wspólnej globalnej puli adresów i wspólnych ustawień DNS dla wszystkich polityk L2TP.
• Grupy zaimportowane z Active Directory lub Microsoft Entra ID nie są automatycznie włączane dla L2TP. Trzeba je jawnie dodać za pomocą Add members.
• L2TP i PPTP uwzględniają przy ocenie członkostwa tylko właściwą Main Group. Samo dodatkowe członkostwo w grupie nie potwierdza więc uprawnienia. Prawidłowe zarządzanie grupami użytkowników i Main Group wyjaśnia to zachowanie.

Przykład i przygotowanie

W przykładzie klient zewnętrzny łączy się z wewnętrzną siecią aplikacyjną. Wartości są celowo przykładami dokumentacyjnymi i trzeba je dostosować do własnego środowiska:

• pula L2TP: od 10.250.30.10 do 10.250.30.100 w obrębie 10.250.30.0/24
• wewnętrzny serwer DNS: 10.10.10.10
• dozwolona grupa: L2TP_Users
• nazwa polityki: L2TP_Remote_Access
• profil IPsec: DefaultL2TP jako punkt wyjścia do testu zgodności
• wewnętrzna sieć docelowa: 10.10.10.0/24
• przykładowa usługa: HTTPS

Zakres 10.250.30.0/24 jest wyłącznie prywatną siecią przykładową. Nie może pokrywać się z sieciami LAN, VLAN, Site-to-Site ani domowymi, ani z zakresami dzierżaw Remote Access IPsec, SSL VPN lub PPTP. Sophos pozwala w Assign IP from na maksymalnie 254 adresy w podsieci /24 lub mniejszej.

Przed rozpoczęciem należy też sprawdzić:

• Odpowiedni profil IPsec jest zgodny z ustawieniami obsługiwanymi przez natywnego klienta.
• Publiczny adres lub FQDN wybranego portu WAN jest osiągalny z klienta.
• Czas systemowy, DNS i łańcuch certyfikatów są prawidłowe, jeśli używany jest certyfikat.
• Użytkownik lub grupa istnieje, a właściwa metoda uwierzytelniania jest wpisana w Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• Bieżący wynik system route_precedence show i odpowiadające mu polecenie rollback są udokumentowane.
• WebAdmin lub konsola pozostaje osiągalna niezależną ścieżką zarządzania.

Źródło uwierzytelniania i klient muszą obsługiwać tę samą metodę: SFOS wymienia PAP, CHAP lub MSCHAPv2 dla Local i RADIUS, wyłącznie PAP dla Active Directory i LDAP oraz PAP lub CHAP dla TACACS+. Przed wdrożeniem należy sprawdzić metodę wspólną dla źródła i natywnego klienta. Zewnętrzna ochrona IPsec pozostaje obowiązkowa dla L2TP; ta macierz zgodności nie jest zaleceniem stosowania PPTP ani niezabezpieczonego PAP.

Ograniczenia wersji i klientów

Ta instrukcja jest przeznaczona dla SFOS 22.0 MR2 Build 546 i interfejsu opisanego w pomocy online 22.0. L2TP jest dostępne w tej wersji. Kontrola aktualizacji do SFOS 22 firmy Avanet zestawia aktualne blokady i obsługiwane ścieżki; przed każdą migracją należy tam porównać konkretny build źródłowy z docelowym. Nie istnieje pełna macierz zgodności natywnych klientów L2TP. Instrukcja 22.0 jako konkretny przykład klienta podaje tylko Windows 10. Nie jest to dowód zgodności z innymi ani późniejszymi wersjami systemów operacyjnych.

Pełne strony pomocy L2TP dla SFOS 22 i 23 opisują te same ustawienia globalne, pola polityk i kroki konfiguracji. To porównanie dokumentacji nie jest testem urządzenia ani klienta i nie oznacza, że przykład dla SFOS 22 jest zweryfikowaną konfiguracją SFOS 23. Macierz platform dla Sophos Connect, IPsec i SSL VPN w FAQ dotyczącym dostępu zdalnego również nie jest macierzą zgodności L2TP; przy zmianie rozwiązania należy kierować się podlinkowanym powyżej porównaniem klientów oraz odpowiednią procedurą dla IPsec lub SSL VPN.

Każdą faktycznie używaną wersję systemu należy więc osobno przetestować z planowanym profilem IPsec, serwerem uwierzytelniania i typem ID. Maksymalnie 254 adresy w puli to tylko limit adresów, a nie gwarancja takiej samej liczby jednoczesnych sesji. Publiczna pomoc 22.0 nie podaje ogólnego limitu sesji L2TP. Pojemność i stabilność trzeba sprawdzić na konkretnym modelu firewalla przy oczekiwanej równoległości.

Aktualna pomoc opisuje dostępne wartości, ale nie wskazuje uniwersalnej wartości domyślnej dla Gateway type, Authentication type, Allow NAT traversal ani Disconnect when tunnel is idle w istniejących lub migrowanych konfiguracjach. Pola te należy zapisać przed i po aktualizacji, zamiast odtwarzać je na podstawie zakładanego ustawienia domyślnego.

Konfiguracja i sprawdzenie natywnego klienta Windows

W systemie Windows utworzyć połączenie w Ustawienia > Sieć i Internet > VPN > Dodaj sieć VPN. Jako dostawcę VPN wybrać Windows (wbudowane), jako Nazwa lub adres serwera wpisać publiczny FQDN lub adres WAN firewalla, a jako typ VPN wybrać Protokół L2TP/IPsec z kluczem wstępnym albo wariant certyfikatowy zgodny z profilem firewalla. Klucz wstępny musi być zgodny z PSK polityki L2TP. Jako dane logowania użyć nazwy i hasła konta dozwolonego w Add members; typ VPN, metodę logowania, identyfikatory i wersję klienta udokumentować razem.

Pierwszy test wykonać z sieci zewnętrznej. Po połączeniu za pomocą ipconfig /all sprawdzić adres z puli L2TP i przewidziane serwery DNS, a następnie wewnętrzne rozwiązywanie nazw i dozwolony dostęp HTTPS. Jeśli nie udaje się samo zestawienie tunelu, najpierw porównać nazwę serwera, tryb PSK lub certyfikatu, metodę logowania i uzgodniony profil IPsec, a następnie skorelować czas z l2tpd.log i logami IPsec. Każda używana wersja Windows pozostaje oddzielną kombinacją klienta wymagającą weryfikacji.

Konfiguracja globalnych ustawień L2TP

W Remote access VPN > L2TP > L2TP global settings włączyć Enable L2TP. W przykładzie w Assign IP from wpisać zakres od 10.250.30.10 do 10.250.30.100. Jako Primary DNS server wybrać 10.10.10.10, jeśli ten serwer rozwiązuje nazwy wewnętrzne. Pole DNS jest opcjonalne: wybrać serwer z listy lub wpisać jego adres za pomocą Other. Secondary DNS server, Primary WINS server i Secondary WINS server ustawiać tylko wtedy, gdy środowisko rzeczywiście ich potrzebuje; WINS nie zastępuje DNS.

Opcja Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client ma sens tylko wtedy, gdy serwer RADIUS niezawodnie zwraca odpowiedni adres. Jeśli nie dostarczy adresu, firewall użyje najpierw adresu statycznego skonfigurowanego dla użytkownika, a następnie puli globalnej. Zarówno przypisanie RADIUS, jak i ścieżka fallback muszą więc być zaplanowane bez nakładania się zakresów. Konfiguracja RADIUS na Sophos Firewall opisuje ustawienia serwera.

Następnie przez Add members wybrać grupę L2TP_Users, zatwierdzić ją za pomocą Add i sprawdzić przez Show members. W przypadku użytkownika katalogowego sam poprawny import grupy nie wystarcza. Użytkownik pilotażowy musi rzeczywiście należeć do dozwolonej grupy, a ta grupa musi być uwzględniana jako grupa główna przy ocenie uprawnień L2TP.

Po zmianie ustawień globalnych i członków kliknij Apply. Ponownie sprawdź zapisane wartości globalne i Show members. Późniejsze Save dla polityki L2TP jest osobnym krokiem.

Ograniczenia automatyzacji przez API XML

Kroki wykonywane w interfejsie nie stanowią gotowego żądania do API XML. Porównane strony API dla SFOS 22 i 23 rozdzielają w ramach L2TPConfiguration wartości globalne w L2TPSettings od członków w L2TPMembers z UserName. W przeciwieństwie do interfejsu tabela oznacza PrimaryDNSServer jako pole obowiązkowe zawierające adres IPv4. Opcjonalne pole DNS w interfejsie nie dowodzi więc, że ten parametr API można pominąć. L2TPGeneralSettings i LeaseIPFromRadiusServer są tam wymienione jako opcjonalne, z Disable jako udokumentowaną wartością domyślną; nie wynika z tego przetestowane zachowanie w przypadku ich pominięcia. Przed automatyzacją należy wyjaśnić kontrakt API zainstalowanego buildu, bez zgadywania sposobu kodowania pustej wartości DNS. Następnie ponownie odczytać zamierzone wartości globalne i członkostwo; opisane wyżej kroki w interfejsie i mechanizm rezerwowy RADIUS pozostają od tego niezależne.

Dla zapisanej polityki opisanej poniżej przykład API pokazuje L2TPConnection z Configuration; obok znajdują się gałęzie sterujące Connection, DisConnection, Active i DeActive, każda z Name. Zapisanie, połączenie, rozłączenie i aktywacja nie odnoszą się więc do tej samej tożsamości ani czynności. Symbole w interfejsie nie potwierdzają wykonywalnego żądania API. Ponadto przykład i tabela pól są sprzeczne: RemoteHost zawiera w przykładzie nazwę hosta lub adres IP, natomiast tabela dopuszcza IPv4 lub *; AliasLocalWANPort oznacza w przykładzie wyłącznie alias WAN, ale w tabeli jest obowiązkowe. Dla DisconnectOnIdleInterval tabela podaje wartość domyślną 0, a jednocześnie zakres od 120 do 999; 600 jest tylko wartością przykładową. Nie należy na tej podstawie określać znaczenia zera ani wyznaczać bezpiecznych wartości zastępczych. Przed zmianami przez API wyjaśnić te kwestie dla konkretnego buildu oraz sprawdzić niezależną ścieżkę zarządzania i wpływ na współdzielone klucze PSK polityk wildcard zgodnie z opisem powyżej.

Również podczas późniejszego wycofywania konfiguracji należy odróżniać usunięcie zapisanej konfiguracji połączenia od jej dezaktywacji i globalnego wyłączenia L2TP. Najpierw zinwentaryzować istniejącą konfigurację, dezaktywować wskazane połączenie i sprawdzić zależności. Delete L2TP Connection wymaga dokładnego zapisanego Name (pierwsza litera A-Za-z, następnie A-Za-z0-9_, najwyżej 50 znaków); strona nie zawiera przykładu żądania. Przypisania stanów 200/L2TPDeleteSuccess, 203/L2TPConnInUse i 500/L2TPDeleteFail odwołują się do nierozstrzygniętych identyfikatorów Message, a nie do potwierdzonych tekstów komunikatów ani klasyfikacji HTTP. W szczególności nie traktować 203 jako ogólnego sukcesu usunięcia z klasy 2xx. Po wyjaśnieniu żądania usunięcia ponownie sprawdzić dokładną nazwę celu i potwierdzić zachowanie nadal potrzebnych dostępów produkcyjnych; nie zgadywać struktury obwiedni żądania usunięcia ani automatycznego porządkowania po tej operacji.

Statyczny adres użytkownika i istniejące zależności od PPTP

Pola dzierżawy przypisane do użytkownika znajdują się w Authentication > Users > [użytkownik], w sekcji ustawień dostępu zdalnego. L2TP zezwala na dostęp L2TP i umożliwia wpisanie adresu IP, który ma zostać wydzierżawiony użytkownikowi zdalnemu. PPTP ma osobny przełącznik i osobne pole adresu IP do dzierżawy. Są to dwa odrębne ustawienia konta, a nie pula globalna ani przypisanie adresu IP dla SSL VPN. Lokalnym użytkownikiem i jego hasłem zarządzać zgodnie z instrukcją Tworzenie lokalnych użytkowników na Sophos Firewall. Tylko dla uzasadnionego, istniejącego dostępu zaplanować unikatowy adres bez konfliktów, zapisać go przez Save, a przy następnym połączeniu z sieci zewnętrznej sprawdzić faktycznie przypisany adres i ścieżkę powrotną. Przy dzierżawie z RADIUS adres użytkownika pozostaje opisanym wyżej mechanizmem rezerwowym, gdy RADIUS nie dostarczy adresu; przełącznik konta nie zastępuje ani zezwolenia przez Add members, ani reguły firewall.

Pierwsze logowanie przed zestawieniem tunelu: Pomoc dotycząca dodawania użytkowników w SFOS 22 i 23 wymaga, aby po włączeniu L2TP lub PPTP członkowie polityki najpierw zalogowali się do VPN portal i utworzyli hasło, zanim nawiążą połączenie. Ten udokumentowany proces pierwszego dostępu należy sprawdzić na koncie pilotażowym dla używanego buildu i serwera uwierzytelniania. Nie resetować istniejących haseł na wszelki wypadek ani nie zastępować hurtowo działającego logowania katalogowego hasłami lokalnymi. Dostępność portalu i VPN portal authentication methods sprawdzić niezależnie od metody uwierzytelniania tunelu; nie trzeba w tym celu udostępniać WebAdmin od strony WAN.

Na potrzeby inwentaryzacji już istniejącego dostępu PPTP w Remote access VPN > PPTP można znaleźć Enable PPTP, Assign IP from, wspólną opcję dzierżawy z RADIUS oraz podstawowy serwer DNS i opcjonalne dodatkowe serwery DNS/WINS. Dzierżawa obowiązuje przez czas trwania połączenia; prywatny zakres mieści się w podsieci /24 lub mniejszej i obejmuje najwyżej 254 adresy. Nie może nakładać się na zakresy Remote Access IPsec ani SSL VPN. Pomoc opisuje Apply dla wartości globalnych oraz Add members i Show members dla nadawania użytkownikom dostępu; także tutaj import grup z AD lub Entra ID nie przyznaje dostępu automatycznie. Na potrzeby migracji i diagnostyki należy jedynie odczytać te pola w istniejącej konfiguracji — nie jest to zalecenie włączenia PPTP. Udokumentowane metody PAP, CHAP i MS-CHAPv2 nie zapewniają nowoczesnego standardu bezpieczeństwa; rozwiązanie zastępcze należy zaplanować z użyciem IPsec, SSL VPN lub dostępu do konkretnych aplikacji.

Tworzenie polityki L2TP

W Remote access VPN > L2TP użyć Add, aby utworzyć politykę L2TP_Remote_Access.

Profil i zachowanie po uruchomieniu

W Profile wybrać profil IPsec zgodny z klientami. W przykładzie istniejący profil DefaultL2TP jest punktem wyjścia do testu zgodności. Jego algorytmy i lifetimes trzeba mimo to porównać z wartościami obsługiwanymi przez klienta; nazwa zawierająca Default nie jest trwałą gwarancją bezpieczeństwa. Dwie wartości Gateway type mają różne skutki operacyjne:

• Respond only utrzymuje politykę w gotowości po restarcie, aby mogła odpowiadać na żądania przychodzące.
• Disable pozostawia ją nieaktywną do ręcznego włączenia przez stan Active.

Dla produkcyjnej usługi Remote Access Respond only jest zwykle najbardziej zrozumiałym punktem wyjścia. Wybór trzeba wyraźnie sprawdzić po restarcie firewalla lub usługi, aby nie pomylić aktywacji ze stanem połączenia.

Uwierzytelnianie i preshared key

Dostępne wartości Authentication type to Preshared key i Digital certificate. Digital certificate uwierzytelnia punkty końcowe przez wymianę certyfikatów podpisanych lokalnie lub wystawionych przez urząd certyfikacji. Certyfikaty eliminują współdzielony PSK, ale wymagają w pełni zaplanowanego łańcucha zaufania i odpowiedniej obsługi po stronie klienta. PSK musi być długi, losowy, przekazywany oddzielnym kanałem i regularnie odnawiany w kontrolowany sposób.

Sophos używa ostatnio skonfigurowanego PSK dla wszystkich połączeń z tym samym interfejsem nasłuchującym i tym samym zdalnym peerem. W Remote Access Remote host jest zwykle ustawiony na *. Nowa lub zmieniona polityka wildcard może więc zastąpić PSK w istniejących konfiguracjach Remote Access. Przed zapisaniem trzeba sprawdzić wszystkie polityki używające tego samego portu WAN i bramy wildcard.

Dla PSK zdefiniować zgodne wartości Local ID i Remote ID. Typ ID DER ASN1DN (X.509) nie jest akceptowany dla PSK. Identyfikatory muszą pasować do natywnego klienta i nie powinny być ustawiane na dowolne wartości dla wygody.

Port WAN, peer i selektory

W Local WAN port wybrać port WAN, który jest rzeczywiście osiągalny. Dla klientów ze zmiennymi adresami ustawić Remote host na wartość wildcard *. Włączyć Allow NAT traversal, gdy klienci znajdują się za NAT, co jest typowe w sieciach domowych, komórkowych i hotelowych.

Dla typowego przepływu Remote Access przykład Sophos używa Remote subnet: Any, Local port: 1701 i Remote port: *. 1701 jest portem L2TP na firewallu; port klienta może się zmieniać. Wartości te są selektorami tunelu i nie zastępują reguły firewall. Dalszy dostęp pozostaje ograniczony do konkretnych stref, celów i usług.

Remote host może też zawierać adres IP lub nazwę hosta dla stałego peera. Remote subnet opisuje sieci zdalne; tę wartość należy sprawdzić pod kątem konkretnego projektu konfiguracji klienta. Pomoc dla pól Local port i Remote port dopuszcza porty TCP/UDP lub wartość wildcard *; przykład z lokalnym portem 1701 nie jest uniwersalnym wymaganiem dla każdej konfiguracji selektorów. Pomoc dotycząca polityki nazywa tę sekcję QuickHA mode, podczas gdy instrukcja konfiguracji mówi o selektorach Quick Mode. Z tego nagłówka nie należy wnioskować o funkcji HA: istotne są oba pola portów i uzgodnione selektory IPsec.

Za pomocą Disconnect when tunnel is idle firewall może rozłączać nieaktywnych klientów po czasie określonym w Idle session time interval. Wartość należy dopasować do rzeczywistego sposobu pracy i sprawdzić z realistycznymi przerwami. Zbyt krótki okres powoduje niepotrzebne ponowne połączenia; bez limitu zapomniane sesje mogą pozostawać aktywne dłużej. Idle session time interval podaje się w sekundach.

Po Save włączyć politykę czerwonym symbolem w kolumnie Active. Zielony kolor w Active nie oznacza jeszcze, że klient jest połączony. Oddzielny stan Connection pokazuje, czy tunel został rzeczywiście zestawiony; pomoc opisuje użycie symbolu tego stanu do nawiązania połączenia. W przypadku klienta zdalnego rozstrzygająca pozostaje jego próba połączenia z sieci zewnętrznej. Logs na stronie L2TP otwiera logi L2TP. Gdy Active jest wyłączone, polityka pozostaje nieaktywna niezależnie od wcześniejszego stanu tunelu.

Przy wielu podsieciach lokalnych i zdalnych powstaje tunel dla każdej pary lokalna/zdalna. Connection może pokazywać stan częściowy: konfiguracja jest aktywna, ale co najmniej jeden tunel nie został zestawiony. Sprawdź osobno każdą wymaganą parę podsieci i jej przepływ danych; włączone Active nie potwierdza wszystkich tuneli.

Dostępność, routing i reguła firewall

Zezwolenie na IPsec od strony WAN

W Administration > Device access trzeba zezwolić na IPsec dla wymaganej dostępności WAN. Uprawnienie należy wdrożyć tak wąsko, jak pozwala topologia. Silny PSK ani certyfikat nie uzasadnia niepotrzebnie szerokiego dostępu do WebAdmin, User Portal lub SSH. Device Access i Local Service ACL wyjaśnia rozdział dostępności usługi od uprawnień użytkownika.

Kontrolowane ustawienie Route Precedence

Udokumentowana przez Sophos kolejność domyślna to Static, SD-WAN Policy Routes, a następnie VPN. Dla L2TP trasy VPN muszą być natomiast oceniane jako pierwsze; Static i SD-WAN mogą występować dalej w dowolnej kolejności. Zalogować się do CLI firewalla i wybrać 4. Device Console. Najpierw zapisać tam rzeczywisty stan wyjściowy:

system route_precedence show

Następnie ustawić udokumentowaną kolejność L2TP i ponownie ją sprawdzić:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Zmiana ma charakter globalny i nie jest osobnym przełącznikiem nowej polityki L2TP. Przed nią i po niej trzeba przetestować nakładające się ścieżki Static, SD-WAN i VPN oraz dostęp administracyjny. Zmiana Route Precedence na Sophos Firewall wyjaśnia wpływ i bezpieczny rollback.

Zezwolenie na dostęp do celów wewnętrznych

W Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule utworzyć regułę z włączonym logowaniem, a następnie zapisać ją przez Save. Nadać czytelną nazwę w Rule name, na przykład VPN-LAN. Przykład Sophos z Any dla źródła, celu i usługi jest prosty do pierwszego potwierdzenia działania, ale nie jest dobrym stałym standardem bezpieczeństwa. W tym przykładzie zakres jest węższy:

• Source zone: VPN
• Source network: pula L2TP 10.250.30.0/24 lub odpowiedni obiekt IP host
• Destination zone: strefa zawierająca sieć aplikacyjną
• Destination network: 10.10.10.0/24 albo, najlepiej, wymagane serwery
• Services: HTTPS lub tylko rzeczywiście wymagane usługi
• Log firewall traffic: włączone

Ruch internetowy przez firewall wymaga oddzielnej reguły z VPN do WAN oraz świadomie zaplanowanego NAT i zabezpieczeń. Dostęp nie jest tworzony automatycznie tylko dlatego, że tunel L2TP jest zestawiony.

Weryfikacja połączenia

Test należy wykonać z rzeczywistej sieci zewnętrznej. Próba z tego samego LAN lub przez istniejącą ścieżkę VPN może ukryć problemy z routingiem, NAT i dostępnością publiczną.

1. Połączyć się uprawnionym użytkownikiem pilotażowym z udokumentowaną konfiguracją klienta.
2. W Remote access VPN > L2TP osobno sprawdzić stan Active i Connection. Przy wielu podsieciach lokalnych i zdalnych powstaje tunel dla każdej pary lokalna/zdalna. Connection może pokazywać stan częściowy: konfiguracja jest aktywna, ale co najmniej jeden tunel nie został zestawiony. Sprawdź osobno każdą wymaganą parę podsieci i jej przepływ danych; włączone Active nie potwierdza wszystkich tuneli.
3. Sprawdzić, czy klient otrzymuje adres od 10.250.30.10 do 10.250.30.100 oraz przewidziane serwery DNS.
4. Rozwiązać nazwę wewnętrzną i przez HTTPS osiągnąć jawnie dozwolony cel.
5. W Log Viewer sprawdzić oczekiwany Firewall Rule ID, źródłowy adres IP z puli L2TP, cel, usługę i akcję.
6. Sprawdzić ścieżkę powrotną z sieci docelowej do puli L2TP i powtórzyć ten sam dostęp po ponownym połączeniu.
7. Wykonać test negatywny z użytkownikiem, którego nie dodano; nie może on uzyskać użytecznego tunelu.
8. Sprawdzić zachowanie idle, rozłączenie, ponowne połączenie oraz w HA kontrolowany failover z nowym logowaniem.

Poprawne uwierzytelnianie nie potwierdza jeszcze ścieżki danych. Tak samo zielony tunel nie dowodzi, że DNS, reguła, NAT i droga powrotna są prawidłowe. Testowanie reguł Sophos Firewall wyjaśnia rozdzielenie dowodów z Log Viewer i Packet Capture.

Systematyczne rozwiązywanie problemów

Polityka jest aktywna, ale tunel pozostaje down

Najpierw porównać port WAN, dostępność publiczną, IPsec w Device Access, NAT Traversal, adres klienta, PSK lub certyfikat, Local/Remote ID oraz profil IPsec. Następnie sprawdzić, czy nowsza zapisana polityka wildcard nie zastąpiła oczekiwanego PSK.

Do pierwszego rozdzielenia użyć l2tpd.log dla L2TP oraz strongswan.log lub charon.log dla negocjacji IPsec. Usługi i pliki dziennika Sophos Firewall zawierają pełne przypisanie. Logi należy korelować z dokładnym czasem, użytkownikiem, publicznym adresem IP klienta i nazwą polityki; restart usługi nie jest pierwszym krokiem diagnostycznym.

Logowanie się nie udaje lub użytkownik nie otrzymuje dostępu

W Authentication > Services sprawdzić metodę dla VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Następnie sprawdzić, czy użytkownik lub grupa są wymienione w Add members i która grupa widnieje jako Main Group w obiekcie użytkownika. Przy RADIUS dodatkowo osobno sprawdzić uwierzytelnianie i opcjonalne przypisanie dzierżawy.

Tunel jest up, ale cele wewnętrzne są nieosiągalne

W tej kolejności sprawdzić adres dzierżawy, Route Precedence, Firewall Rule ID, trasę docelową i ścieżkę powrotną. Szeroka trasa SD-WAN lub konkurencyjna Static Route może zmienić przebieg. Pula L2TP musi być osiągalna z sieci wewnętrznej bez przejmowania powrotu przez drugą identyczną trasę lub nakładającą się sieć.

Jeśli Log Viewer pokazuje Rule 0, nieoczekiwany Rule ID albo brak pasującego wpisu, trzeba ustalić faktyczne dopasowanie reguły przed rozszerzaniem czegokolwiek do Any. Jeśli pakiet wychodzący jest widoczny, ale nie wraca odpowiedź, dalsza kontrola dotyczy hosta docelowego, jego bramy, lokalnego firewalla lub trasy powrotnej.

Połączenie jest wolne lub niestabilne

Sprawdzić opóźnienia, utratę pakietów, MTU lub fragmentację, zmiany WAN i obciążenie CPU podczas powtarzalnego testu. Pojedynczy transfer SMB nie jest czystym testem przepustowości VPN. Kilka kontrolowanych strumieni TCP w obu kierunkach pomaga rozdzielić tunel, transport i aplikację.

Jeśli niestabilne są tylko połączenia L2TP, porównać znaczniki czasu w l2tpd.log, logach IPsec, zdarzeniach WAN i logu klienta. Profil, MTU lub idle time zmieniać pojedynczo w oknie serwisowym dopiero po wykazaniu konkretnego związku.

Przy przejściu na Sophos Connect nie przenosić zasad dotyczących L2TP

FAQ dotyczące dostępu zdalnego omawia IPsec i SSL VPN, a nie dodatkową obsługę klientów L2TP. Tabela platform wymienia dla Windows .pro lub .scx dla IPsec oraz .pro lub .ovpn dla SSL VPN; te same typy plików podaje dla macOS z Sophos Connect od wersji 2.1. macOS z Connect 2.0 używa odpowiednio .scx lub .ovpn; w wersjach wcześniejszych niż 2.0 IPsec nadal korzysta z Sophos Connect i .scx, natomiast SSL VPN z klienta innego producenta i .ovpn. Android korzysta z klientów innych producentów z .tgb dla IPsec lub .ovpn dla SSL VPN; iOS nie wymaga dodatkowego klienta dla IPsec i pobiera konfigurację z VPN portal, natomiast dla SSL VPN potrzebuje klienta innego producenta z .ovpn. Przed zastąpieniem dotychczasowego rozwiązania sprawdzić konkretną, aktualną kombinację klienta i systemu operacyjnego. Szyfrowanie dla IPsec sprawdzić w Remote access VPN > IPsec > IPsec profiles > Encryption algorithm, a dla SSL VPN w Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings. Ogólnego stwierdzenia z FAQ o szyfrowanym połączeniu dostępu zdalnego nie należy odnosić do PPTP bez odrębnego zabezpieczenia protokołu.

W provisioningu Sophos Connect bramy w .pro służą tylko do pobierania danych z portalu, a nie do wyboru tunelu: IPsec używa skonfigurowanego interfejsu, a SSL VPN interfejsów z .ovpn, które istnieją w Network > Interfaces i są udostępnione przez Local Service ACL. Override hostname ustawia żądany publiczny adres SSL VPN; w konfiguracji za routerem jego publiczny FQDN lub adres IP WAN należy umieścić w .pro, na routerze skonfigurować odpowiednie przekierowanie DNAT, a dla IPsec wpisać jego adres IP WAN jako bramę w .scx. Prywatny certyfikat domyślny dla WebAdmin i VPN Portal może podczas provisioningu powodować błąd zaufania; należy poprawić łańcuch certyfikatów, a nie wyłączać weryfikację. Konfiguracja firewalla dla Sophos Connect i procedura SSL VPN zastępują tutaj konfigurację L2TP.

Przy zmianach IPsec FAQ wymaga użycia Edit connection > Update policy i ponownego pobrania danych z portalu; w przypadku SSL VPN ręczne aktualizacje dotyczą przede wszystkim portu, protokołu, bramy i certyfikatu serwera SSL. .pro pobiera niektóre zmiany SSL VPN automatycznie; ponowny import może pobrać obie konfiguracje na nowo. Aby rozróżnić aktualizację profilu od błędu pobierania, skorzystać z instrukcji Ponowne pobieranie profilu SSL VPN. Sophos Connect używa bram SSL VPN z .ovpn w odwrotnej kolejności priorytetów, niekoniecznie w kolejności z .pro. SSL VPN dzieli pulę między instancje zależne od CPU, z własnymi podsieciami tun0: zakresy mniejsze niż /24 zmniejszają liczbę dostępnych dzierżaw; dla /27 i ośmiu instancji FAQ wskazuje tylko jeden pozostały adres do dzierżawy. Nie jest to limit puli L2TP. Brak możliwości pobrania .ovpn może też wiązać się z identyfikatorami użytkowników przekraczającymi wspólny limit ID użytkowników i grup wynoszący 65535; Bezpieczne sprawdzanie limitu ID użytkowników opisuje kontrolowane porządkowanie zamiast masowego usuwania.

MFA dla rozwiązania zastępczego zaplanować w Authentication > Multi-factor authentication, korzystając z wymaganych pól wyboru User portal, SSL VPN remote access i IPsec remote access. Osobne pole OTP wymaga dla IPsec Prompt users for 2FA token i Apply, a w provisioningu otp: true i 2fa: 1. Sophos Connect wysyła hasło i OTP razem jako passwordotp i według FAQ nie obsługuje uwierzytelniania OTP w trybie challenge; obsługiwane są metody telefoniczne i push, a WebAdmin dodatkowo MFA w trybie challenge. Tę różnicę należy sprawdzić w pilotażu provisioningu, a nie przenosić jej na natywnego klienta L2TP. FAQ ogranicza ponadto Remote Access IPsec do jednego interfejsu WAN; nie wynika z tego ani taki sam limit dla L2TP, ani gwarancja obsługi wielu interfejsów WAN w rozwiązaniu zastępczym.

Migracja do SFOS 22

Migrację firmware należy planować oddzielnie od zmiany konfiguracji L2TP. Przed aktualizacją trzeba zinwentaryzować dokładny firmware i platformę, globalne ustawienia L2TP, dozwolonych użytkowników i Main Groups, każdą politykę L2TP wraz z profilem, ID i uwierzytelnianiem, Device Access, Route Precedence oraz powiązane reguły firewall i NAT. Należy też przygotować szyfrowany backup i niezależną ścieżkę zarządzania. W kontroli aktualizacji do SFOS 22 trzeba porównać konkretny build źródłowy z bieżącą tabelą aktualizacji; ogólne stwierdzenie, że konfiguracje można migrować do 22.0 GA, nie zastępuje kontroli ścieżki.

Nie należy mylić L2TP z Remote Access IPsec (legacy): L2TP pozostaje dostępne w SFOS 22.0 MR2, natomiast starszy wariant IPsec wycofano w wersji 22.0 MR1. Firewalla zawierającego tę starszą konfigurację nie można zaktualizować do 22.0 MR1 ani nowszej wersji. Ponadto SFOS 22.0 GA i nowsze wersje nie obsługują urządzeń sprzętowych XG ani SG. Platforma i istniejące typy zdalnego dostępu są więc rzeczywistymi warunkami wstrzymującymi aktualizację, a nie tylko pozycjami inwentaryzacji.

W SFOS 22.0 MR1 Build 490 poprawiono NC-162171, przez który NAS-Identifier nie był wstawiany dla połączeń L2TP używających MS-CHAPv2 lub MS-CHAP. Jeśli reguły RADIUS zależą od NAS-Identifier, a firewall przechodzi ze starszego buildu, po aktualizacji trzeba sprawdzić nie tylko logowanie, lecz także odebrane żądanie RADIUS i faktycznie dopasowaną politykę RADIUS. Ta poprawka nie dowodzi automatycznej zgodności wszystkich kombinacji klienta i uwierzytelniania.

Po restarcie należy porównać wersję firmware i wszystkie zinwentaryzowane pola. Następnie wykonać pełną weryfikację z sieci zewnętrznej, w tym test negatywny, DNS, ścieżkę danych, zachowanie idle i nowe logowanie po failoverze HA. Do czasu zaliczenia testów poprzednia metoda dostępu pozostaje kontrolowaną ścieżką awaryjną.

Rollback firmware to więcej niż wyłączenie L2TP. Aktywny i poprzedni firmware wraz z odpowiadającymi im stanami konfiguracji znajdują się na oddzielnych partycjach. Uruchomienie poprzedniego firmware aktywuje również jego wcześniejszy stan konfiguracji, więc zmiany od czasu aktualizacji nie będą po rollbacku częścią działającej konfiguracji. Przed tym krokiem trzeba osobno zachować wymagane późniejsze zmiany, sprawdzić obsługiwaną wersję docelową i potwierdzić okno serwisowe na restart.

Bezpieczny rollback konfiguracji L2TP

Rollback oznacza przywrócenie wyłącznie stanów zmienionych podczas tej procedury do udokumentowanego stanu wyjściowego, a nie likwidację istniejącego środowiska L2TP. Dlatego przed pierwszą zmianą należy zapisać globalne wartości L2TP, w tym Enable L2TP, stan Active każdej objętej zmianami polityki, pełną listę w Add members, uprawnienia użytkowników, reguły firewall oraz zezwolenie na IPsec w Administration > Device access; nowe elementy i zmiany istniejących elementów należy odnotować oddzielnie. Jeśli brakuje wartości wyjściowych lub potwierdzonego sposobu ich dokładnego przywrócenia w zainstalowanym buildzie, nie należy wykonywać danej zmiany; najpierw trzeba wyjaśnić tę kwestię z Sophos Support. Udokumentowana wartość domyślna nie zastępuje odczytanej wartości wyjściowej.

Podczas rollbacku niezależna ścieżka zarządzania pozostaje otwarta. Najpierw należy przywrócić Route Precedence zmienioną podczas tej procedury dokładnie do wcześniej zapisanej kolejności, ponownie odczytać ją za pomocą system route_precedence show i sprawdzić ścieżki zarządzania, Static, SD-WAN oraz VPN. Jeśli kolejność nie została zmieniona, należy ją zachować.

W istniejącej konfiguracji należy dokładnie przywrócić tylko zmienione wartości, stany polityk, członkostwo i uprawnienia. Istniejące wcześniej polityki, członkowie, reguły i zezwolenia pozostają zachowane w swoim pierwotnym stanie; wcześniej włączone Enable L2TP pozostaje włączone. Wycofanie pojedynczej zmiany w Device Console nie jest powodem do usuwania tych dostępów ani globalnego wyłączania L2TP.

Likwidacja wdrożenia utworzonego w całości dopiero podczas tej procedury jest odrębną operacją: przed każdą dezaktywacją lub usunięciem należy sprawdzić zależności i potwierdzić, że nie wpłynie to na żaden nadal potrzebny dostęp produkcyjny. Dopiero wtedy należy dezaktywować nowo utworzoną politykę L2TP i sprawdzić skutki za pomocą klienta pilotażowego. Następnie należy wycofać wyłącznie nowo utworzone, niepotrzebne już reguły firewall i zezwolenia na IPsec oraz usunąć z Add members tylko członków dodanych podczas tej procedury. Enable L2TP należy wyłączyć tylko wtedy, gdy przed tą procedurą było wyłączone i nie istnieje żadna nadal potrzebna zależność. Istniejących elementów współdzielonych nie należy usuwać w ramach porządkowania.

Po wycofaniu zmian należy porównać zapisane wartości globalne, Show members, stan polityk, uprawnienia użytkowników, reguły i Device Access z udokumentowanym stanem wyjściowym. Za pomocą zewnętrznego klienta pilotażowego należy potwierdzić, że wcześniej wymagane dostępy produkcyjne nadal działają, a wycofane zezwolenia testowe nie umożliwiają już dostępu. Nie należy przywracać Preshared Key w ciemno do wcześniejszej wartości; wszystkie polityki z tym samym portem WAN i bramą wildcard należy sprawdzić łącznie.

FAQ