Sprawdzanie MTU i MSS w Sophos Firewall przy problemach z VPN

Typowy problem z MTU/MSS nie wygląda jak jednoznaczna blokada: tunel VPN jest połączony i ping działa, ale pobieranie plików zostaje przerwane, RDP się zawiesza albo logowanie przez HTTPS nie dochodzi do skutku. Przyczyną może być mniejszy użyteczny rozmiar pakietu na ścieżce przez IPsec, PPPoE, XFRM lub SD-WAN.

Jeśli tunel w ogóle się nie zestawia lub nie ma skojarzenia zabezpieczeń, należy najpierw skorzystać z artykułu Rozwiązywanie problemów z IPsec VPN w Sophos Firewall. Informacje o typach interfejsów i XFRM zawiera artykuł Konfigurowanie stref i interfejsów w Sophos Firewall.

Szybka diagnostyka: potwierdzenie problemu z MTU lub MSS

1. W Log Viewer potwierdzić oczekiwany Firewall Rule ID, a jeśli ścieżka korzysta z NAT, także NAT Rule ID. Jeśli ruch w ogóle się nie pojawia lub działają niewłaściwe reguły, najpierw poprawić routing, strefę, NAT lub DNS.
2. Zanotować Source, Destination, Service, kierunek, TCP/UDP oraz rzeczywistą ścieżkę przez LAN, VLAN, WAN, XFRM, RED, SD-WAN lub Remote Access VPN.
3. Wyświetlić i udokumentować bieżące wartości MTU i MSS na odpowiednim interfejsie.
4. Wykonać test DF, ściśle filtrowany Packet Capture oraz ten sam rzeczywisty test aplikacji.
5. Zmienić wartość tylko wtedy, gdy można powtarzalnie wykazać różnicę między małymi i dużymi pakietami. Następnie dokładnie powtórzyć ten sam test.

Ogólną kontrolę reguł opisuje artykuł Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture. W przypadku nieoczekiwanego NAT Rule ID pomaga artykuł Zrozumienie NAT w Sophos Firewall.

Testowanie rozmiaru pakietu z bitem DF

W IPv4 do ładunku ICMP dochodzi 20 bajtów nagłówka IP i 8 bajtów nagłówka ICMP. Ładunek 1472 odpowiada więc pakietowi o wielkości około 1500 bajtów.

Windows:

ping -f -l 1472 <target-ip>

macOS:

ping -D -s 1472 <target-ip>

Linux:

ping -M do -s 1472 <target-ip>

Jeśli test z wartością 1472 kończy się niepowodzeniem, należy stopniowo zmniejszać ładunek do 1464, 1452, 1412 lub mniej. Trzeba udokumentować zarówno działający, jak i niedziałający rozmiar. Filtry ICMP, dostawca, bramy chmurowe lub zdalna strona mogą zniekształcić wynik, dlatego test DF nie zastępuje ani Packet Capture, ani testu aplikacji.

Klasyfikacja MTU, MSS i badanej ścieżki

MTU to maksymalny rozmiar pakietu na interfejsie lub ścieżce. Większe pakiety są fragmentowane albo odrzucane. MSS ogranicza rozmiar danych użytkowych TCP w segmencie. Jeśli pozostaje zbyt wysoki mimo narzutu VPN lub dostawcy, przy większych ilościach danych pojawiają się retransmisje, zastoje i przerwane połączenia.

MTU i MSS nie są ogólnymi parametrami do strojenia. Znaczenie ma konkretna ścieżka:

• WAN, PPPoE lub VLAN: dostawca, router albo dodatkowy nagłówek zmniejsza użyteczny rozmiar pakietu.
• XFRM: IPsec oparty na trasach wprowadza narzut; trasy, reguły i interfejs XFRM wspólnie określają ścieżkę.
• SD-WAN: przepływ może korzystać z innego WAN, MPLS lub VPN, niż oczekiwano. Wybór ścieżki opisuje artykuł Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego.
• Zdalna strona: trasa zwrotna, zdalna zapora, Cloud VPN i MSS Clamping muszą odpowiadać badanemu kierunkowi.
• Wi-Fi: od SFOS 22.0 MR1 wartości MTU i MSS istniejących interfejsów Wi-Fi można zmieniać za pomocą udokumentowanych poleceń CLI.

Podejrzenie powinny wzbudzić duże pobrania lub wysyłki, RDP, SMB, HTTPS, kopie zapasowe, ERP, aplikacje chmurowe i konferencyjne albo VoIP, które zawodzą tylko na określonej ścieżce VPN lub SD-WAN. Pasują do tego również liczne retransmisje w iPerf, silnie zmienna przepustowość TCP lub błąd pojawiający się bezpośrednio po zmianie dostawcy, aktualizacji firmware, przebudowie SD-WAN czy migracji VPN. Jeśli małe i duże testy kończą się tak samo, bardziej prawdopodobną przyczyną są reguła, NAT, routing, DNS, system docelowy lub trasa zwrotna.

Sprawdzanie przepływu danych za pomocą Log Viewer, Packet Capture i iPerf

Wykluczanie problemów z regułami, NAT i DNS

• Brak ruchu w Log Viewer: sprawdzić bramę klienta, VLAN, trasę, logowanie i przepływ testowy.
• Niewłaściwy Firewall Rule ID: sprawdzić kolejność, strefę, Source, Destination, Service i User Matching. Dalsze przyczyny opisuje artykuł Reguła Sophos Firewall nie jest stosowana.
• Niewłaściwy NAT Rule ID: sprawdzić kolejność, pola Original, MASQ, SNAT, DNAT i kierunek.
• Nieoczekiwany docelowy adres IP: sprawdzić DNS, Split DNS, obiekt FQDN, CDN i IPv6.

Jeśli używany jest VPN, należy dodatkowo sprawdzić stan tunelu i liczniki bajtów. Trzeba też udokumentować TLS Inspection, IPS oraz Application Control, aby testy przed zmianą i po niej rzeczywiście porównywały tę samą ścieżkę oraz te same funkcje bezpieczeństwa.

Analiza Packet Capture

W obszarze Diagnostics > Tools > Packet capture należy ustawić filtr na odpowiednie Source i Destination, a następnie odtworzyć dokładnie jedno wywołanie HTTPS, transfer lub uruchomienie aplikacji:

• Jeśli pakiety nie docierają, błąd zwykle leży po stronie klienta, bramy, VLAN lub routingu lokalnego.
• Jeśli pakiety trafiają do tunelu, ale brakuje odpowiedzi, należy sprawdzić zdalną stronę i trasę zwrotną.
• Wiele retransmisji TCP wskazuje na utratę pakietów, MTU/MSS, jakość WAN lub przeciążenie.
• Jeśli małe testy działają, ale duże transfery nie, należy sprawdzić Path MTU Discovery i fragmentację.

Obsługę narzędzia opisuje artykuł Używanie Packet Capture w WebAdmin. Przechwytywanie pakietów i włączone logi debugowania powinny działać tylko tak długo, jak to konieczne, aby nie zajmowały niepotrzebnie miejsca.

Porównanie iPerf z testem aplikacji

Dedykowany serwer iPerf po zdalnej stronie daje bardziej miarodajny wynik niż serwer publiczny. TCP i UDP należy testować oddzielnie, a niską przepustowość TCP lub retransmisje oceniać razem z jakością WAN, obciążeniem CPU, zdalną stroną i funkcjami bezpieczeństwa. Pełną procedurę opisuje artykuł Rozwiązywanie problemów z Sophos Firewall za pomocą iPerf i Speedtest.

Wyświetlanie lub zmiana MTU i MSS

WebAdmin i XFRM

W obszarze Network > Interfaces należy edytować odpowiedni interfejs i otworzyć Advanced settings > Interface settings. Znajdują się tam pola MTU i Override MSS. Interfejsy XFRM są widoczne pod fizycznym Listening Interface.

Sophos Firewall domyślnie oblicza MTU interfejsu XFRM na podstawie MTU interfejsu Listening Interface i maksymalnego narzutu IPsec. Jeśli MTU XFRM zostanie zmienione ręcznie, musi być co najmniej o 113 bajtów mniejsze niż MTU interfejsu Listening Interface. Przy wartości 1400 bajtów na Listening Interface dozwolone maksimum dla XFRM wynosi 1287 bajtów. Ten zapas zapobiega utracie pakietów podczas FastPath Offload, gdy do ruchu IPsec stosowane jest odszyfrowywanie SSL/TLS.

Sprawdzanie wartości w Device Console

Należy zalogować się przez SSH, w menu głównym wybrać 4. Device Console i podać identyfikator interfejsu:

show mtu-mss Port2

Dla interfejsów fizycznych Sophos dokumentuje następującą składnię zmiany:

set network mtu-mss <PortID> mtu <number|default> mss <number|default>

Przykład obliczenia: jeśli potwierdzone MTU ścieżki IPv4 wynosi 1492 bajty, bez dodatkowych opcji TCP MSS wynosi 1452 bajty (1492 - 20 - 20). Nie jest to ani ogólna wartość domyślna SFOS, ani uniwersalne zalecenie dla fizycznego interfejsu PPPoE.

⚠️ Zmiana wpływa na aktywny ruch i może przerwać połączenie SSH lub WebAdmin. Nie należy jej wykonywać przez jedyne połączenie zarządzające korzystające z odpowiedniego interfejsu. Musi istnieć lokalna lub pozapasmowa (Out-of-Band) możliwość przywrócenia dostępu. Port2 jest tylko przykładem i należy zastąpić go identyfikatorem faktycznie sprawdzonego interfejsu.

Najpierw należy zapisać wyświetlone wartości. Parametr default ustawia udokumentowane przez Sophos wartości domyślne produktu: MTU 1500 i MSS 1460:

set network mtu-mss Port2 mtu default mss default

Jest to wycofanie zmiany tylko wtedy, gdy te wartości były aktywne przed modyfikacją. W przeciwnym razie należy jawnie przywrócić wartości początkowe udokumentowane za pomocą show mtu-mss.

Weryfikacja zmiany

• udokumentować odpowiedni interfejs, tunel i wartości początkowe;
• wybrać okno serwisowe lub kontrolowany termin testu;
• wykonywać tylko jedną zmianę na test;
• poinformować zdalną stronę w przypadku VPN site-to-site;
• po zmianie i wycofaniu zmiany za pomocą show mtu-mss Port2 sprawdzić, czy aktywne są oczekiwane wartości;
• powtórzyć ten sam test DF, Packet Capture, iPerf i aplikacji;
• udokumentować nowe wartości, uzasadnienie oraz wynik;
• w kolejnych dniach sprawdzać monitoring.

⚠️ Nie należy stosować trwałych obejść w Advanced Shell, skryptów startowych ani doraźnych reguł filtrowania pakietów. Są trudne w utrzymaniu, a po aktualizacji, odtworzeniu konfiguracji lub przełączeniu awaryjnym HA mogą działać nieprawidłowo albo zniknąć. Jeśli takie pozostałości już istnieją, pomocny jest artykuł Skrypty Sophos Firewall bez Cronjob: zagrożenia i alternatywy.

Nie należy znacząco obniżać MSS ogólnie dla wszystkich sieci, testować tylko jednego kierunku ani ignorować zdalnej strony. Jeśli kontrolowany test nie przynosi poprawy, trzeba przywrócić udokumentowaną wartość początkową.

Rozwiązywanie problemów według objawu

• VPN jest aktywny, ale duże transfery się zawieszają: sprawdzić MTU/MSS, trasę zwrotną lub funkcję bezpieczeństwa za pomocą Packet Capture i iPerf na tej samej ścieżce.
• Problem dotyczy tylko WAN z PPPoE: sprawdzić interfejs WAN, bramę, dane dostawcy i użyteczny rozmiar pakietu.
• VPN oparty na trasach jest niestabilny przy dużych pakietach: sprawdzić interfejs XFRM, połączenie IPsec, trasę i regułę 113 bajtów.
• VoIP przez VPN jest niestabilny: sprawdzić ścieżkę SIP/RTP, trasę SD-WAN, trasę zwrotną, utratę pakietów i Packet Capture.
• TCP jest bardzo wolny, UDP działa normalnie: sprawdzić MSS, retransmisje, okno TCP i utratę pakietów w oddzielnych testach iPerf.
• Małe pakiety działają, duże nie: udokumentować test DF oraz sprawdzić Path MTU Discovery, fragmentację i zdalną stronę.

FAQ