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: Aktualna pomoc SFOS 22 nadal dokumentuje L2TP jako konfigurowalny typ dostępu zdalnego. Sophos nie opublikował informacji o wycofaniu tej funkcji. Nie stanowi to jednak gwarancji obsługi w przyszłej wersji głównej. 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 zgodności lub dalszej obsługi istniejącego środowiska.

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. PPTP nie jest nowoczesnym rozwiązaniem zastępczym: sam protokół nie definiuje szyfrowania i nie powinien być planowany dla nowych połączeń Remote Access.

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.

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. Secondary DNS i WINS ustawiać tylko wtedy, gdy środowisko rzeczywiście ich potrzebuje.

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 dodać grupę L2TP_Users i sprawdzić ją za pomocą 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ć Main Group używaną przy ocenie L2TP.

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. Certyfikaty eliminują współdzielony PSK, ale wymagają w pełni zaplanowanego łańcucha zaufania i odpowiedniego wsparcia klienta. PSK musi być długi, losowy, przekazywany oddzielnym kanałem i 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.

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.

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.

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

Sophos wymaga dla L2TP, aby trasy VPN były oceniane przed Static i SD-WAN Policy Routes. Najpierw zapisać stan wyjściowy w Device Console:

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 utworzyć logowaną regułę IPv4. Przykład Sophos z Any dla źródła, celu i usługi jest prosty do pierwszego testu funkcjonalnego, ale nie jest dobrym stałym standardem bezpieczeństwa. Ten przykład 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.
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.

Bezpieczny rollback

Podczas rollbacku niezależna ścieżka zarządzania pozostaje otwarta. Najpierw przywrócić dokładnie zapisaną Route Precedence i sprawdzić ścieżki zarządzania, Static, SD-WAN i VPN. Następnie wyłączyć politykę L2TP i potwierdzić klientem pilotażowym, że nie istnieje już żadna zależność produkcyjna.

Potem można usunąć reguły firewall i zezwolenie IPsec, jeśli nie zależy od nich żadna inna usługa. Dopiero wtedy usunąć użytkowników z Add members i wyłączyć Enable L2TP. Nie przywracać Preshared Key w ciemno do wcześniejszej wartości; wszystkie polityki z tym samym portem WAN i bramą wildcard trzeba sprawdzić razem.

FAQ