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 build SFOS, czas, objęte tunele, oczekiwany przepływ testowy oraz niezależną drogę zarządzania. Istniejące wartości sprawdza się osobno:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance pokazuje między innymi wartości workqueue i replay. show vpn configuration dotyczy bieżącej konfiguracji L2TP i PPTP. Jeżeli wartość nie pojawia się w wyniku na zainstalowanym buildzie, nie wolno wyprowadzać jej z zakładanego defaultu. Przed globalną zmianą zaawansowaną trzeba uwzględnić backup konfiguracji i Sophos Support.

Rollback zawsze wykorzystuje wartość rzeczywiście odczytaną z appliance. default nie jest udokumentowany jako uniwersalny powrót dla tych poleceń VPN i nie może być używany na podstawie założenia.

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. Nowe konfiguracje od SFOS 19.0 używają domyślnie disable, a systemy migrowane mogą zachować starszą wartość.

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

Sophos zmienił te defaulty w SFOS 19.0 dla nowych konfiguracji, aby ograniczyć flapping połączeń innych niż TCP podczas podnoszenia lub opadania tuneli IPsec. Zmiana celowo nie była stosowana globalnie przy upgrade i migracji. W SFOS 22 liczy się zatem bieżący wynik z urządzenia, nie zakładana wartość fabryczna.

W HA należy też pamiętać, że Sophos Firewall nie przekazuje sesji VPN i innych niż TCP do peer tak jak zwykłych przekazywanych sesji TCP. Dwa przełączniki conn-remove-* nie zastępują ani projektu HA, ani kontrolowanego testu failover.

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ą.

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.

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.

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. Opcja nie zastępuje sprawnego DNS, właściwych TTL ani osiągalnych resolverów. Przed włączeniem koreluje się czas rozwiązania, bieżące odpowiedzi A i AAAA, liczbę tuneli i charon.log. Po zmianie DNS lub providera sprawdza się, czy firewall używa nowego adresu peer w oczekiwanym czasie. Bez opisanego przypadku Charon ustawienie pozostaje wyłączone.

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.

Najpierw odczytuje się konfigurację poleceniem show vpn configuration. 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.

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.

Kontrolowane testowanie i wycofanie

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. Należy sprawdzić co najmniej jeden istniejący przepływ, nowe połączenie, oba kierunki i kontrolowany test negatywny. Potem ponownie odczytuje się stan odpowiednim poleceniem show vpn ....

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