Sprawdzanie MTU i MSS w Sophos Firewall przy problemach z VPN
Kiedy połączenie VPN jest nawiązane, ale niektóre aplikacje nadal się zawieszają, często najpierw myśli się o regułach zapory, DNS lub zdalnym punkcie końcowym. To jest poprawne, ale niepełne. W przypadku dużych pakietów, narzutu IPsec, PPPoE, SD-WAN lub VPN opartych na trasach, przyczyną mogą być również MTU i MSS.
Typowym objawem jest problem, który nie wygląda jak wyraźna blokada: ping działa, małe strony ładują się, ale transfery plików przerywają, RDP zamarza, logowania HTTPS zatrzymują się lub VoIP staje się niestabilny. Artykuł ten porządkuje kwestie MTU i MSS w Sophos Firewall, bez ślepego zmieniania wartości lub budowania niebezpiecznych obejść w powłoce.
Podstawy dotyczące interfejsów, stref i XFRM można znaleźć w Konfigurowanie stref i interfejsów w Sophos Firewall. Jeśli tunel IPsec w ogóle się nie nawiązuje lub nie jest zainstalowane żadne skojarzenie bezpieczeństwa, lepszym punktem wyjścia jest Rozwiązywanie problemów z IPsec VPN w Sophos Firewall.
Krótkie wyjaśnienie MTU i MSS
MTU opisuje, jak duży może być pakiet na interfejsie lub ścieżce. Jeśli pakiet jest większy niż pozwala na to ścieżka, musi zostać zfragmentowany lub zostanie odrzucony. W przypadku VPN jest to szczególnie istotne, ponieważ IPsec dodaje dodatkowe nagłówki.
MSS dotyczy TCP i opisuje, jak duża powinna być część danych użytkownika segmentu TCP. Jeśli MSS pozostaje zbyt wysoki, mimo że rzeczywista ścieżka przez VPN, PPPoE lub inne nakładki jest mniejsza, pojawiają się typowe problemy TCP: retransmisje, zastoje, wolne połączenia lub przerwy w połączeniach przy większych ilościach danych.
Ważne: MTU i MSS nie są wartościami do strojenia, które można przypadkowo zmniejszyć, aż coś zadziała. Obie wartości są związane ze ścieżką. Przed zmianą powinno być jasne, który interfejs, który kierunek, który protokół i który tunel są dotknięte.
Kiedy podejrzewać MTU lub MSS
Problemy z MTU i MSS często pojawiają się tylko przy określonych aplikacjach lub rozmiarach pakietów.
Typowe wskazówki:
- Tunel VPN jest połączony, ale większe pobierania lub przesyłania się zawieszają.
- RDP, SMB, HTTPS, kopie zapasowe, ERP lub aplikacje chmurowe działają tylko częściowo.
- Małe testy ICMP działają, większe transfery danych nie.
- VoIP lub aplikacje konferencyjne są niestabilne tylko przez określone ścieżki VPN lub SD-WAN.
- Problem dotyczy tylko PPPoE, określonego WAN, trasy opartej na IPsec lub interfejsu XFRM.
- iPerf pokazuje wiele retransmisji lub znacznie zmieniający się przepustowość TCP.
- Po zmianie dostawcy, aktualizacji oprogramowania, przebudowie SD-WAN lub migracji VPN nagle pojawia się nowy problem.
Takie objawy nie dowodzą jeszcze problemu z MTU. Niemniej jednak są dobrym powodem, aby uwzględnić MTU i MSS w analizie.
Nie mylić z problemami z regułami, NAT lub DNS
MTU/MSS zazwyczaj nie jest pierwszym punktem kontrolnym. Najpierw powinno być jasne, że ruch zasadniczo podąża oczekiwaną ścieżką. W przeciwnym razie zmienia się rozmiary pakietów, mimo że problemem jest reguła, NAT, DNS lub błędna ścieżka zwrotna.
| Obserwacja | Bardziej prawdopodobne niż MTU/MSS |
|---|---|
| W Log Viewer nie pojawia się żaden ruch | Logowanie, brama klienta, VLAN, trasa lub błędny przepływ testowy |
| Nieprawidłowa ID reguły zapory jest używana | Kolejność reguł, strefa, źródło, cel, usługa lub dopasowanie użytkownika |
| ID reguły NAT nie pasuje | Kolejność NAT, pola oryginalne, MASQ/SNAT/DNAT lub błędny kierunek |
| Nazwa rozwiązuje się na nieoczekiwany adres IP | DNS, Split DNS, obiekt FQDN, CDN lub IPv6 |
| Małe i duże testy zawodzą tak samo | Reguła, routing, NAT, system docelowy lub punkt końcowy |
| Tylko duże transfery się zawieszają | MTU/MSS, fragmentacja, Path-MTU-Discovery lub narzut VPN do sprawdzenia |
Do tej wstępnej kontroli pasują Sprawdzanie przyczyn niepasującej reguły w Sophos Firewall, Używanie Packet Capture w WebAdmin i Zrozumienie NAT w Sophos Firewall. Dopiero gdy reguła, NAT, routing i DNS są wiarygodne, warto naprawdę śledzić ścieżkę MTU/MSS.
Typowe miejsca w Sophos Firewall
W Sophos Firewall może być istotnych kilka obszarów. Zazwyczaj nie cała zapora jest dotknięta, ale konkretna ścieżka.
| Obszar | Dlaczego istotny |
|---|---|
| Interfejs WAN | Dostawca, PPPoE, VLAN lub router przed nim mogą zmniejszyć użyteczny rozmiar pakietu |
| Interfejs XFRM | Route-based IPsec generuje dodatkowy narzut i wymaga odpowiedniej MTU tunelu |
| Trasa SD-WAN | Ścieżka może przebiegać przez inne WAN, MPLS lub VPN niż oczekiwano |
| Reguła zapory | Funkcje bezpieczeństwa lub logowanie pomagają w ograniczaniu, ale nie są samą MTU |
| Punkt końcowy | Druga zapora, VPN w chmurze lub strona dostawcy musi obsługiwać tę samą ścieżkę poprawnie |
| Interfejs Wi-Fi | Od SFOS 22.0 MR1 Sophos również wspomina o dostosowaniach MTU/MSS dla interfejsów Wi-Fi przez CLI |
W przypadku VPN opartych na trasach, Sophos Firewall tworzy interfejsy XFRM. Wartości MTU XFRM są obliczane na podstawie fizycznego interfejsu i maksymalnego narzutu IPsec i mogą być dostosowywane w razie potrzeby. To jest pomocne, ale nie zastępuje dokładnego sprawdzenia rzeczywistej ścieżki.
Najpierw udowodnij ścieżkę
Przed każdą zmianą należy dokładnie opisać dotknięty przepływ danych. W przeciwnym razie można szybko optymalizować na błędnym interfejsie.
Praktyczne pytania:
- Które adresy IP źródłowe i docelowe są dotknięte?
- Czy ruch przebiega przez LAN, VLAN, WAN, XFRM, RED, SD-WAN czy VPN zdalnego dostępu?
- Czy dotyczy to tylko jednego kierunku, czy obu?
- Czy dotyczy to TCP, UDP czy obu?
- Czy małe pakiety działają, ale większe transfery nie?
- Czy rzeczywiście działa oczekiwana reguła zapory?
- Czy na ścieżce jest NAT, MASQ, TLS Inspection, IPS lub Application Control?
- Czy punkt końcowy ma odpowiednią trasę zwrotną?
Do sprawdzenia reguł i ścieżek pomocne jest Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture. W przypadku NAT lub MASQ warto dodatkowo sprawdzić Zrozumienie NAT w Sophos Firewall.
Diagnoza za pomocą Log Viewer, Packet Capture i iPerf
Log Viewer pokazuje, czy ruch jest dozwolony czy odrzucony. Nie dowodzi jednak sam, czy pakiet jest zbyt duży. Do tego potrzebne są dodatkowo Packet Capture, powtarzalne testy i jasna interpretacja.
Log Viewer
W Log viewer najpierw sprawdź:
- Wybierz moduł
Firewalllub dotknięty moduł bezpieczeństwa. - Filtruj według Source-IP, Destination-IP i Service.
- Sprawdź, która reguła zapory pasuje.
- Upewnij się, że żadna reguła Drop, błędna strefa lub błędna reguła NAT nie jest rzeczywistym problemem.
Jeśli żaden ruch nie jest widoczny, problem często leży przed zaporą, w bramie klienta, VLAN, routingu lub na punkcie końcowym.
Packet Capture
W Diagnostics > Tools > Packet capture można zawęzić test. Sensowne jest filtrowanie dokładnie dotkniętego źródła i celu. Następnie powtarza się pojedynczy test, na przykład wywołanie HTTPS, transfer pliku lub uruchomienie aplikacji.
Ważna jest interpretacja:
| Obserwacja | Znaczenie |
|---|---|
| Pakiety nie docierają do zapory | Sprawdź klienta, bramę, VLAN lub lokalne routowanie |
| Pakiety wchodzą do tunelu, brak odpowiedzi | Sprawdź punkt końcowy, trasę zwrotną lub zdalną zaporę |
| Wiele retransmisji przy TCP | Sprawdź utratę pakietów, MTU/MSS, jakość WAN lub przeciążenie |
| Małe testy działają, duże transfery się zawieszają | Sprawdź MTU/MSS lub Path-MTU-Discovery |
Do obsługi narzędzia pasuje Używanie narzędzia Packet Capture w WebAdmin.
iPerf
iPerf jest pomocny, gdy można powtarzalnie zmierzyć trasę. Własny serwer iPerf po drugiej stronie jest znacznie bardziej miarodajny niż publiczny serwer iPerf. Jeśli przepustowość TCP jest niska i widoczne są liczne retransmisje, należy sprawdzić MTU/MSS wraz z jakością WAN, CPU, punktem końcowym i funkcjami bezpieczeństwa.
Procedura jest opisana w Rozwiązywanie problemów z Sophos Firewall za pomocą iPerf i Speedtest.
Zmieniaj wartości tylko celowo
Jeśli podejrzenie jest uzasadnione, zmiany powinny być małe, udokumentowane i odwracalne.
Przed zmianą:
- udokumentuj bieżącą wartość
- zanotuj dotknięty interfejs i tunel
- wybierz okno konserwacyjne lub kontrolowany czas testu
- zmień tylko jedną wartość na test
- przeprowadź test przed/po z tą samą aplikacją
- poinformuj punkt końcowy, jeśli dotyczy to VPN site-to-site
W przypadku VPN opartych na trasach najpierw należy sprawdzić interfejs XFRM i powiązane połączenie IPsec. W przypadku PPPoE lub nakładek dostawcy często decydującym punktem jest interfejs WAN lub ścieżka dostawcy. W przypadku SD-WAN musi być również jasne, która brama lub ścieżka VPN jest rzeczywiście używana. Artykuł Routing SD-WAN dla pakietów odpowiedzi i ruchu systemowego pomaga w klasyfikacji ścieżek SD-WAN.
⚠️ Nie używaj trwałych obejść w powłoce. Bezpośrednia manipulacja pakietami za pomocą Advanced Shell, nieudokumentowane skrypty startowe lub spontaniczne reguły filtrowania pakietów nie są czystym rozwiązaniem dla produkcyjnych zapór. Najpierw należy sprawdzić obsługiwane funkcje Sophos Firewall.
Czego unikać
Te wzorce w praktyce powodują więcej szkód niż korzyści:
- Ustawianie MSS na bardzo niskie dla wszystkich sieci.
- Zmiana wartości MTU bez testu przed/po.
- Testowanie tylko jednego kierunku i wyciąganie wniosków na temat całej ścieżki VPN.
- Używanie obejść w powłoce zamiast funkcji WebAdmin lub dokumentowanych funkcji konsoli urządzenia.
- Ignorowanie punktu końcowego, mimo że ścieżka zwrotna lub ich MSS-Clamping mogą być zaangażowane.
- Zakładanie, że MTU/MSS jest przyczyną, mimo że reguła zapory, NAT, routing lub DNS nie zostały sprawdzone.
- Długotrwałe uruchamianie logów debugowania lub przechwytywania pakietów, co zapełnia przestrzeń dyskową.
Jeśli już istnieją lokalne skrypty lub manipulacje pakietami, najpierw należy przeczytać Skrypty Sophos Firewall bez Cronjob: Ryzyka i alternatywy i dokładnie udokumentować stare obciążenia.
Tabela rozwiązywania problemów
| Objaw | Bardziej prawdopodobny obszar | Następny krok |
|---|---|---|
| VPN zielony, duże transfery się zawieszają | MTU/MSS, ścieżka zwrotna, funkcja bezpieczeństwa | Packet Capture i iPerf z tą samą ścieżką |
| Dotyczy tylko PPPoE-WAN | Ścieżka dostawcy lub MTU WAN | Sprawdź interfejs WAN, bramę i informacje od dostawcy |
| VPN oparty na trasach niestabilny przy dużych pakietach | MTU XFRM lub ścieżka SD-WAN | Sprawdź interfejs XFRM, połączenie IPsec i trasę |
| VoIP przez VPN tylko częściowo stabilny | SD-WAN, ścieżka zwrotna, utrata pakietów, MTU | Sprawdź ścieżkę SIP/RTP, trasę SD-WAN i przechwytywanie |
| TCP bardzo wolny, UDP normalny | MSS, retransmisje, okno TCP, utrata pakietów | Testuj iPerf TCP/UDP osobno |
| Małe pakiety działają, duże nie | Path-MTU-Discovery lub fragmentacja | Świadomie testuj rozmiary pakietów i sprawdź punkt końcowy |
Lista kontrolna
Natychmiast sprawdź:
- Udokumentowane dotknięte źródło, cel, usługa i kierunek.
- Potwierdzona reguła zapory i reguła NAT w Log Viewer.
- Przeprowadzono Packet Capture z wąskim filtrem.
- Sprawdzony status IPsec i licznik bajtów, jeśli dotyczy VPN.
- Sprawdzony punkt końcowy i ścieżka zwrotna.
Jeśli MTU/MSS jest prawdopodobne:
- Zidentyfikowano dotknięty interfejs lub miejsce XFRM.
- Udokumentowano bieżącą wartość MTU/MSS.
- Zaplanowano tylko jedną zmianę na test.
- Ustalono aplikację testową i wartość porównawczą.
- Zmiana uzgodniona z punktem końcowym, jeśli dotyczy VPN site-to-site.
Po zmianie:
- Przetestuj ponownie tę samą aplikację.
- Porównaj Log Viewer, Packet Capture lub iPerf.
- Udokumentuj nowe wartości i uzasadnienie.
- Sprawdź monitorowanie w ciągu najbliższych dni.