Bezpieczne używanie globalnych ustawień VPN w Sophos Firewall

Device Console w Sophos Firewall udostępnia pod set vpn globalne ustawienia failover VPN, przetwarzania IPsec oraz starszych protokołów L2TP i PPTP. Nie dotyczą one wyłącznie aktualnie analizowanego połączenia. Nieprecyzyjny test może wpłynąć na inne tunele, usunąć istniejące sesje albo osłabić funkcję ochronną.

To nie jest ogólna recepta na wydajność: nie należy zapobiegawczo zwiększać ipsec-max-workqueue-items ani okna anti-replay, ani włączać use-resolved-ip-address. Sophos opisuje te opcje jako ustawienia zaawansowane do konkretnej potrzeby sieciowej lub do użycia zgodnie z zaleceniem Sophos Support.

Przy typowych problemach z tunelem najpierw stosuje się troubleshooting VPN IPsec. Obejmuje on IKE, Child SA, routing, NAT, reguły i rzeczywisty przepływ pakietów. Globalne przełączniki z tego artykułu są istotne dopiero wtedy, gdy objaw dokładnie odpowiada ich przeznaczeniu.

Zapisanie stanu początkowego przed każdą zmianą

Polecenia wykonuje się w 4. Device Console. Przed zmianą należy zapisać wersję i kompilację SFOS, czas, objęte tunele, oczekiwany przepływ testowy oraz niezależną drogę zarządzania. Trzeba też utworzyć aktualną kopię zapasową konfiguracji. Powiązana pomoc CLI dla SFOS 22 dokumentuje dla tych wartości tylko set vpn, a nie polecenie odczytu. Dokumentacja zmian i kopie zapasowe są jedynie dowodami pomocniczymi i nie potwierdzają aktualnie aktywnej wartości. Sophos Support musi potwierdzić metodę odczytu dokładnej wartości w zainstalowanej kompilacji. Przed zmianą należy zapisać jej wynik i przygotować odpowiadające mu polecenie wycofania set vpn. Jeśli Support nie może potwierdzić metody odczytu albo nie można ustalić bieżącej wartości, należy przerwać procedurę i nie zmieniać ustawienia globalnego.

Pomoc SFOS 22 podaje default tylko dla MTU L2TP, anti-replay, progu cookie i rozwiązanego adresu peer. Nawet te wartości domyślne nie dowodzą, że konkretne urządzenie nadal ma niezmienioną konfigurację.

Wycofanie zawsze wykorzystuje wartość początkową bezpiecznie ustaloną przed zmianą. Udokumentowana składnia nie zawiera uniwersalnego parametru default. Polecenia przywracające wartości domyślne, pokazane niżej, są właściwe tylko wtedy, gdy zmiana ma jawnie przywrócić udokumentowaną wartość domyślną SFOS 22; nie mogą zastąpić celowo niestandardowej wartości początkowej.

Sesje podczas zmian tunelu i WAN

conn-remove-tunnel-up określa, czy istniejące połączenia są usuwane po zestawieniu tunelu IPsec. Może to mieć znaczenie, gdy przepływ rozpoczął się inną ścieżką i pozostaje do niej przypisany po uruchomieniu tunelu. Usunięcie może również przerwać sesje produkcyjne. Pomoc SFOS 22 nie dokumentuje defaultu; dlatego przywraca się wartość bezpiecznie ustaloną przed zmianą.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover steruje globalnym czyszczeniem podczas failover i failback. all dotyczy wszystkich połączeń, natomiast non-tcp ogranicza czyszczenie do ruchu innego niż TCP, takiego jak UDP lub ICMP. Właściwa wartość nie jest więc wyłącznie decyzją dotyczącą VPN: w tym samym oknie testowym trzeba obserwować VoIP, wideokonferencje, DNS i inne aplikacje UDP.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

Pomoc SFOS 22 nie podaje defaultu dla żadnego ustawienia conn-remove-*. Rollback przywraca dokładnie udokumentowaną wartość początkową.

W HA każdy protokół trzeba testować osobno. Według pomocy HA dla SFOS 22 tunele IPsec route-based, policy-based i remote access są odtwarzane podczas failover. Dla ruchu wewnątrz tunelu IPsec failover sesji obsługuje UDP i ICMP, ale nie TCP. conn-remove-* nie zastępuje projektu HA ani testu istniejącego przepływu TCP i UDP.

Rozróżnienie ustawień o innym zakresie

• Profil IPsec: Use strict profile i Pass data in compressed format w System > Profiles > IPsec profiles dotyczą wyłącznie połączeń z tym profilem. Pomoc profilu wiąże strict profile z problemami handshake powodowanymi przez fragmentację i podaje, że kompresja zachodzi przed szyfrowaniem. Nie są to ustawienia globalne.
• SSL VPN: Remote access VPN > SSL VPN > SSL VPN global settings dotyczy wszystkich policies SSL VPN remote access i pliku .ovpn. Pomoc SSL VPN podaje dla Disconnect dead peer after default 180 sekund dla TCP i 100 dla UDP; dla UDP dozwolone jest 60-110. Disconnect idle peer after jest podawane w minutach bez udokumentowanego defaultu. Wartości te nie dotyczą IPsec ani L2TP.
• L2TP w interfejsie webowym: Remote access VPN > L2TP > L2TP global settings dotyczy wszystkich zasad L2TP i steruje włączeniem, zakresem dzierżaw, dzierżawami RADIUS, DNS, WINS oraz członkami. Udokumentowany zakres musi być prywatny, należeć do podsieci /24 lub mniejszej i zawierać najwyżej 254 adresy. Sophos podaje, że zakresy adresów L2TP i PPTP nie mogą nakładać się na konfiguracje zdalnego dostępu IPsec ani SSL VPN; ta strona nie stwierdza, że zakresy L2TP i PPTP nie mogą nakładać się wzajemnie. Uwierzytelnianie i MTU w CLI opisane niżej pozostają specyficzne dla L2TP.
• Wartości globalne firewalla: tcp-est-idle-timeout, udp-timeout, udp-timeout-stream i fragmented-traffic w set advanced-firewall nie są ustawieniami VPN. Pomoc CLI podaje 2700-432000 sekund dla zestawionego TCP, 30-3600 dla obu timeoutów UDP i allow jako default ruchu fragmentowanego. Nie należy ich zmieniać dla jednego tunelu.

Wydajność IPsec i funkcje ochronne

Grupa ipsec-performance zawiera cztery bardzo różne funkcje. Jej nazwa może zachęcać do eksperymentów z tuningiem, chociaż tylko jedna funkcja bezpośrednio określa rozmiar kolejki pracy.

Zmiana workqueue tylko przy potwierdzonym wąskim gardle

ipsec-max-workqueue-items przyjmuje wartości od 1024 do 10240. Kolejka przechowuje zadania przetwarzania IPsec. Większa wartość nie gwarantuje wyższego throughputu i nie naprawia Packet Loss, problemów MTU, słabego wyniku pojedynczego streamu ani nasyconego łącza WAN.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

Zmiana ma sens tylko wtedy, gdy powtarzalny test obciążenia, wykorzystanie systemu i diagnostyka Sophos wskazują dokładnie to wąskie gardło. Najpierw osobno sprawdza się MTU i MSS, opóźnienie, Packet Loss, profil szyfrowania, IPsec Acceleration i równoległe streamy. Bez poprawy przywraca się zapisaną wartość początkową.

Sophos nie dokumentuje defaultu dla ipsec-max-workqueue-items. Rollback używa set vpn ipsec-performance ipsec-max-workqueue-items <zapisana-wartosc-poczatkowa>.

Okno anti-replay jest funkcją bezpieczeństwa

IPsec zapisuje w oknie replay pakiety już widziane podczas odszyfrowywania. Pozwala to wykrywać i odrzucać powtórzone pakiety. SFOS 22 akceptuje 0, 32, 64, 128, 256, 512, 1024, 2048 i 4096; udokumentowany default to 1024.

set vpn ipsec-performance anti-replay window-size <wartosc>

Większe okno może mieć znaczenie przy silnym przestawianiu pakietów na równoległych ścieżkach. Nie jest ogólnym przełącznikiem throughputu. Wartość 0 usuwa ochronę anti-replay i nie jest zalecana jako rozwiązanie. Taki test wymaga izolowanego okna, wyraźnego zalecenia Sophos Support i natychmiast dostępnego rollbacku.

set vpn ipsec-performance anti-replay window-size 1024 przywraca udokumentowany default. Jeśli wartość początkowa była niestandardowa, należy przywrócić dokładnie ją.

Próg cookies IKEv2 chroni półotwarte SA

Według Sophos walidacja cookies jest zawsze aktywna i dostępna tylko dla IKEv2. cookie_threshold jej nie włącza ani nie wyłącza. Gdy liczba jednoczesnych półotwartych IKE SA przekroczy próg, responder żąda cookie od initiatora. Chroni to stan zestawiania przed obciążeniem DoS. Udokumentowany default to 30.

set vpn ipsec-performance cookie_threshold <liczba>

Niższą lub wyższą wartość wybiera się wyłącznie na podstawie rzeczywistego obciążenia IKE i diagnostyki supportu. Nie naprawia ona brakującej Child SA, niezgodnych proposals ani błędów uwierzytelniania. Podczas walidacji obserwuje się nowe połączenia IKEv2, strongswan.log, CPU i legalne jednoczesne logowania.

set vpn ipsec-performance cookie_threshold 30 przywraca udokumentowany default. Niestandardowy próg przywraca się tą samą składnią.

Użycie rozwiązanego adresu peer tylko w udokumentowanym przypadku Charon

use-resolved-ip-address jest przeznaczone dla wielu tuneli IPsec site-to-site z peerami FQDN i wolnym rozwiązywaniem DNS. Według Sophos właśnie ta kombinacja może zablokować thread charon. Przy enable firewall używa już rozwiązanego adresu zamiast rozpoczynać tunel z ponownym rozwiązaniem zdalnego FQDN.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

FQDN musi być już poprawnie rozwiązany. Udokumentowany default to Off; przywraca go set vpn ipsec-performance use-resolved-ip-address disable. Jeśli zapisaną wartością początkową było enable, należy użyć jej jako niestandardowego rollbacku. Opcja nie zastępuje sprawnego DNS ani osiągalnych resolverów. Przed włączeniem koreluje się czas rozwiązania, rozwiązany adres peer, liczbę tuneli i charon.log. Po zmianie DNS lub providera sprawdza się, czy firewall używa nowego adresu peer w oczekiwanym czasie.

Zgodność L2TP, MTU i PPTP

set vpn zawiera także protokoły uwierzytelniania dla L2TP i PPTP oraz globalne MTU L2TP. Nie czyni to PPTP właściwym wyborem dla nowych środowisk. PPTP jest przestarzały i nie powinien być wdrażany. L2TP Remote Access również pozostaje kontrolowanym rozwiązaniem zgodności, a nie preferowanym standardem dla nowych zarządzanych klientów.

Dla L2TP i PPTP dostępne są ANY, CHAP, MS_CHAPv2 oraz PAP:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

Wartości nie wybiera się wyłącznie na podstawie najsilniej brzmiącej nazwy. Klient, serwer uwierzytelniania i metoda VPN ustawiona w Authentication > Services muszą obsługiwać ten sam protokół. Szczególnie w Active Directory wspierana kombinacja może różnić się od ścieżki RADIUS. ANY nie zwiększa bezpieczeństwa, lecz rozszerza akceptowane metody i wymaga świadomej decyzji o ryzyku.

Sophos nie dokumentuje defaultu dla tych dwóch wartości CLI. Rollback używa zapisanego tokenu początkowego z tą samą składnią, na przykład set vpn l2tp authentication MS_CHAPv2, jeśli była to wartość początkowa.

MTU L2TP można ustawić od 576 do 1460; udokumentowany default to 1410:

set vpn l2tp mtu <576-1460>

MTU L2TP nie zmienia interfejsu IPsec site-to-site route-based ani policy-based. Dostosowuje się je stopniowo tylko przy powtarzalnym problemie fragmentacji L2TP. Następnie nadal muszą działać małe i duże transfery, DNS, uwierzytelnianie i ponowne połączenie.

set vpn l2tp mtu 1410 przywraca udokumentowany default. Jeśli początkowe MTU było celowo dostosowane, należy zamiast tego przywrócić zapisaną wartość.

Kontrolowane testowanie i wycofanie

Powrót do jawnie udokumentowanych defaultów:

set vpn ipsec-performance anti-replay window-size 1024
set vpn ipsec-performance cookie_threshold 30
set vpn ipsec-performance use-resolved-ip-address disable
set vpn l2tp mtu 1410

Sophos nie podaje defaultów dla conn-remove-*, ipsec-max-workqueue-items ani dwóch protokołów uwierzytelniania. Konfigurację niestandardową zawsze przywraca się wcześniej zapisaną wartością i tą samą składnią set vpn.

W jednym oknie serwisowym zmienia się dokładnie jedną wartość globalną. Przed i po zmianie używa się tych samych tuneli, przepływu testowego i przełączenia WAN lub HA. Dla IPsec zapisuje się stan tunelu, Child SA, liczniki, strongswan.log, charon.log, CPU i Packet Loss. Przy czyszczeniu sesji uwzględnia się VoIP, DNS i inne przepływy UDP.

Udany ping nie jest pełnym testem akceptacyjnym. Trzeba sprawdzić istniejący przepływ, nowe połączenie, oba kierunki i kontrolowany test negatywny. Current activities > IPsec connections pokazuje IPsec, a Current activities > Remote users użytkowników SSL VPN. Dokumentacja dzienników przypisuje IPsec pliki strongswan.log, ipsec_monitor.log i charon.log, SSL VPN sslvpn.log, a L2TP l2tpd.log. Diagnostics > Packet capture pokazuje interfejs wejściowy i wyjściowy, identyfikator reguły, status i przyczynę odrzucenia; należy użyć wąskiego filtra dla zanonimizowanych punktów końcowych testu, aby nie zbierać niepowiązanych danych. Po zmianie wartość docelową należy sprawdzić metodą odczytu potwierdzoną przez Support. Samo przyjęcie polecenia i obserwowany ruch nie dowodzą, która wartość globalna jest aktywna.

Jeżeli oczekiwana poprawa nie nastąpi lub pojawią się nowe przerwy, ustawia się dokładnie wartość zapisaną przed testem. Następnie ponownie sprawdza się tunel i ruch. Bez znanego stanu początkowego, niezależnej drogi zarządzania i uzasadnionego objawu nie wykonuje się zmiany set vpn.

FAQ