Przeprowadzanie testu prędkości Internetu na Sophos Firewall przez SSH

Test prędkości Internetu w przeglądarce nie zawsze pokazuje, co rzeczywiście może osiągnąć łącze internetowe. Przeglądarka, klient, WLAN, proxy, IPS, filtr sieciowy, inspekcja TLS, VPN, NAT i zasady zapory mogą wpływać na wynik. Czasami pomocny jest test bezpośrednio na Sophos Firewall, aby rozgraniczyć połączenie WAN zapory od problemów z klientem lub zasadami.

Artykuł opisuje prosty test pobierania przez SSH na Sophos Firewall, właściwą interpretację wyniku i granice w porównaniu do iPerf, Log Viewer lub Packet Capture. Szczególnie ważne jest rozgraniczenie przy wielu połączeniach WAN: test mierzy ruch pobierania generowany przez zaporę, a nie automatycznie tę samą ścieżkę, co klient za zaporą.

Jaki test wydajności wybrać?

Pobieranie bezpośrednio na zaporze to tylko jedno z narzędzi. W zależności od pytania, inny test może być bardziej odpowiedni:

• Sprawdzenie pobierania WAN bezpośrednio na zaporze: Ten artykuł
• Pomiar przepustowości między dwoma zdefiniowanymi sieciami: Prawidłowe użycie iPerf za Sophos Firewall
• Interpretacja wartości z karty katalogowej i rzeczywistej wydajności zabezpieczeń: Prawidłowe zrozumienie danych wydajności Sophos Firewall
• Sprawdzenie, która zasada zapory lub polityka jest stosowana: Testowanie zasady zapory za pomocą Log Viewer, Policy Test i Packet Capture
• Analiza pojedynczych pakietów, NAT lub ścieżki zwrotnej: Celowe wykorzystanie Packet Capture na Sophos Firewall
• VPN jest wolny lub niestabilny: Sprawdzenie MTU i MSS przy problemach z VPN na Sophos Firewall
• Obserwacja wzorców ruchu i szczytów wolumenu na interfejsach: Konfiguracja monitorowania sFlow na Sophos Firewall

To rozgraniczenie zapobiega błędnym interpretacjom. Szybkie pobieranie na zaporze nie dowodzi, że ścieżka klienta, połączenie VPN lub zasada inspekcji TLS również muszą być szybkie.

Co dowodzi test prędkości na zaporze

Test prędkości bezpośrednio na zaporze odpowiada na konkretne pytanie: Czy zapora sama może pobrać plik z Internetu z oczekiwaną prędkością przez swoją aktualną ścieżkę routingu?

To jest pomocne, gdy chcemy wiedzieć:

• czy łącze WAN jest zasadniczo wystarczająco szybkie
• czy połączenie z dostawcą dostarcza oczekiwaną prędkość pobierania
• czy problem leży raczej przed czy za zaporą
• czy klient, WLAN, przełącznik, filtr sieciowy, inspekcja TLS lub VPN muszą być uwzględnione w analizie

Test nie dowodzi jednak automatycznie, że klienci za zaporą muszą osiągać tę samą prędkość. Ruch klienta przechodzi przez zasady zapory, NAT, polityki bezpieczeństwa i w zależności od konfiguracji przez IPS, ochronę sieciową, kontrolę aplikacji lub inspekcję TLS. Lokalny pobieranie na zaporze omija część tego przetwarzania i dlatego nadaje się jako rozgraniczenie, a nie jako pełny test end-to-end.

Dla interpretacji wartości z karty katalogowej, funkcji zabezpieczeń i rzeczywistej wydajności, dodatkowo pasuje Prawidłowe zrozumienie danych wydajności Sophos Firewall.

Uwzględnienie wielu połączeń WAN i SD-WAN

W przypadku zapór z wieloma łączami WAN, przed testem należy ustalić, przez którą ścieżkę zapora sama łączy się z Internetem. Pobieranie jest generowane przez Sophos Firewall. Jest to ruch systemowy i niekoniecznie podąża tą samą decyzją, co przepływ klienta przetwarzany przez zasadę zapory, zasadę NAT lub trasę SD-WAN.

Typowe błędne założenia:

• Wiele bram WAN: Pobieranie zapory może przebiegać przez inną bramę niż ruch klienta
• Routing SD-WAN dla klientów: Zasady SD-WAN dla klientów nie dowodzą automatycznie ścieżki dla ruchu systemowego zapory
• Aktywne przełączanie awaryjne lub zapasowe WAN: Test może mierzyć właśnie ścieżkę awaryjną
• Routing oparty na politykach lub specjalny NAT: Ścieżka klienta może być traktowana inaczej niż lokalne pobieranie na zaporze

W takich konfiguracjach wynik zawsze powinien być dokumentowany z czasem, aktywnym łączem WAN i obserwowaną bramą. Jeśli ruch systemowy, pakiety odpowiedzi lub decyzje SD-WAN są niejasne, dodatkowo pasuje Zrozumienie routingu SD-WAN, pakietów odpowiedzi i ruchu systemowego na Sophos Firewall.

Wymagania

Przed testem należy spełnić następujące warunki:

• Dostęp SSH lub Advanced Shell jest świadomie dozwolony, najlepiej tylko z zaufanej sieci administracyjnej.
• Zapora ma dostęp do Internetu i DNS działa poprawnie.
• Istnieje okno konserwacyjne lub przynajmniej niekrytyczny czas.
• Jest jasne, przez który interfejs WAN zapora wykonuje pobieranie.
• Jest wystarczająco dużo wolnego miejsca na plik testowy.
• Plik testowy zostanie usunięty po teście.

Dla bezpiecznego dostępu SSH pasuje Połączenie z Sophos Firewall przez SSH. W SFOS SSH zezwala się w Administration > Device access przez Local service ACL albo precyzyjniej przez Local service ACL exception rule. SSH nie powinno być szeroko dozwolone ze stref WAN lub Wi-Fi, a po zadaniach rozwiązywania problemów należy je ograniczyć do niezbędnego minimum. Sophos Firewall zamyka nieaktywne sesje SSH po 15 minutach.

⚠️ Test pobierania generuje rzeczywisty ruch i może tymczasowo obciążyć łącze. Na produkcyjnych zaporach takie testy nie powinny być wykonywane w krytycznych godzinach pracy lub równolegle z oknami kopii zapasowych, VoIP lub konserwacji.

Sprawdź DNS i routing przed pobieraniem

Przed pobraniem dużego pliku testowego należy krótko sprawdzić, czy rozwiązywanie nazw i osiągalność zasadniczo działają. W przeciwnym razie łatwo pomylić problemy DNS, routingu albo dostawcy z wynikiem speedtestu.

W głównym menu CLI najpierw otwórz 4 Device Console i wykonaj proste kontrole:

dnslookup www.avanet.io
ping www.avanet.io
traceroute www.avanet.io

dnslookup sprawdza rozwiązywanie nazw, ping daje szybki test osiągalności, a traceroute pokazuje przybliżoną ścieżkę do celu. Sophos obsługuje w Device Console dodatkowe parametry ping, takie jak interface lub sourceip. Jest to przydatne przy wielu łączach WAN, gdy trzeba sprawdzić konkretną źródłową adresację lub interfejs.

Jeśli DNS już zawodzi, kolejny test curl nie jest miarodajny. Najpierw należy sprawdzić DNS, default route, bramę WAN, decyzję SD-WAN albo dostępność dostawcy.

Przeprowadzanie testu prędkości przez SSH

Zaloguj się do Sophos Firewall przez SSH jako admin. W głównym menu CLI wybierz 5 Device Management, a następnie otwórz 3 Advanced Shell. Advanced Shell to powłoka Linux z głębokim dostępem do komponentów systemowych. W tym artykule służy wyłącznie do pobrania pliku do /tmp i późniejszego usunięcia go.

Następnie pobierz plik testowy do tymczasowego katalogu, aby przypadkowo nie pozostał w nieodpowiednim katalogu roboczym.

cd /tmp
curl -L -o 1GB.bin https://www.avanet.io/1GB.bin

Serwer testowy znajduje się w Szwajcarii i jest przeznaczony do ogólnego pomiaru łącza. Dla mniejszych testów można użyć 100MB.bin zamiast 1GB.bin:

cd /tmp
curl -L -o 100MB.bin https://www.avanet.io/100MB.bin

Jeśli DNS nie działa, test zakończy się niepowodzeniem już na etapie rozwiązywania nazw. Wtedy nie należy analizować prędkości łącza, lecz najpierw DNS, routingu i dostępności WAN.

W przypadku zapór z wieloma łączami WAN test nie powinien być rozpatrywany w izolacji. Równolegle należy sprawdzić w WebAdmin, które łącze WAN jest aktywne i czy występuje właśnie przełączanie awaryjne, zmiana SD-WAN lub awaria dostawcy.

Usunięcie pliku testowego

Po teście plik powinien zostać usunięty:

rm /tmp/1GB.bin

W przypadku testu z mniejszym plikiem:

rm /tmp/100MB.bin

Jeśli test został przerwany, mimo to sprawdź, czy istnieje częściowo pobrany plik:

ls -lh /tmp/*GB.bin

Duże pliki testowe nie powinny pozostawać na zaporze. Zwłaszcza w przypadku małych urządzeń lub już zapełnionych partycji, niepotrzebne zużycie pamięci może później prowadzić do trudnych do zdiagnozowania problemów.

Analiza testu prędkości

Podczas i po pobieraniu curl pokazuje między innymi średnią prędkość pobierania. W przykładzie wartość wynosi około 107 MB/s.

Ważna jest jednostka:

• MB/s oznacza megabajty na sekundę.
• Mbit/s lub Mbps oznacza megabity na sekundę.
• 1 bajt odpowiada 8 bitom.

Jako ogólne przeliczenie:

MB/s x 8 = Mbit/s

107 MB/s odpowiada więc około 856 Mbit/s. Nadmiar, zachowanie TCP, strona przeciwna, routing i obciążenie mogą wpływać na wartość. Dlatego nie należy używać pojedynczego pomiaru jako ostatecznego dowodu.

Zaleca się przeprowadzenie kilku testów o różnych porach dnia. Jeśli wartości znacznie się różnią, należy sprawdzić dostawcę, łącze WAN, routing SD-WAN, błędy interfejsu i obciążenie.

Dla wsparcia lub dokumentacji wewnętrznej nie należy notować tylko liczby. Krótki zestaw danych pomiarowych znacznie pomaga później:

• Czas: 2026-06-21 10:15
• Zapora i oprogramowanie: XGS 2100, SFOS 22.0 MR1
• Plik testowy: 1GB.bin
• Zmierzona prędkość: 107 MB/s, około 856 Mbit/s
• Aktywne łącze WAN: WAN1 Fiber
• Zauważone problemy: równoległe kopie zapasowe, przełączanie awaryjne, wysokie zużycie CPU, aktywne Packet Capture

Jeśli porównuje się kilka pomiarów, plik testowy, cel, czas i ścieżka WAN powinny być możliwie takie same. W przeciwnym razie można szybko porównać czas dnia, ścieżkę dostawcy lub stronę przeciwną zamiast rzeczywistej wydajności zapory.

Porównanie z testami klienta

Kolejnym krokiem jest porównanie z klientem za zaporą. Dzięki temu można określić, gdzie tracona jest wydajność.

• Pobieranie bezpośrednio na zaporze jest szybkie: Połączenie WAN zapory prawdopodobnie nie jest głównym wąskim gardłem
• Pobieranie bezpośrednio na zaporze jest wolne: Sprawdź dostawcę, łącze WAN, routing, DNS lub połączenie zapory
• Zapora szybka, klient wolny: Sprawdź klienta, WLAN, przełącznik, zasady zapory, NAT, politykę bezpieczeństwa lub inspekcję TLS
• Tylko pojedyncze aplikacje są wolne: Sprawdź filtr sieciowy, kontrolę aplikacji, DNS, proxy lub serwer docelowy
• Tylko VPN jest wolny: Sprawdź protokół VPN, MTU/MSS, routing, zasady zapory i sieć klienta

Dla celowych testów ścieżki iPerf jest często lepszy niż publiczne pobieranie. Dzięki iPerf można określić, gdzie znajduje się serwer i klient, czy testowany jest TCP czy UDP oraz jaka przepustowość jest oczekiwana.

Typowe błędne interpretacje

Test prędkości zapory jest szybki, użytkownicy nadal zgłaszają wolny Internet

Wtedy łącze WAN nie jest automatycznie niewinne, ale zmienia się punkt skupienia. Należy sprawdzić sieć klienta, WLAN, port przełącznika, DNS, zasady zapory, NAT, IPS, ochronę sieciową, kontrolę aplikacji i inspekcję TLS. Szczególnie inspekcja TLS lub agresywne profile bezpieczeństwa mogą traktować ruch klienta zupełnie inaczej niż pobieranie bezpośrednio na zaporze.

Test prędkości w przeglądarce jest wolny, test prędkości zapory jest szybki

To często wskazuje na problem za zaporą lub w ścieżce klienta. Mimo to należy przetestować kilka przeglądarek, klienta przewodowego i drugi cel, zanim przyjmie się stałą przyczynę.

Test prędkości zapory jest wolny

Wtedy najpierw sprawdź status WAN, prędkość łącza, dupleks, routing SD-WAN, DNS, awarię dostawcy i obciążenie. W przypadku wielu połączeń WAN powinno być jasne, przez którą bramę przebiega pobieranie.

Tylko wysyłanie jest wolne

Opisywany tutaj curl-download testuje głównie kierunek pobierania. Dla testów wysyłania lub dwukierunkowych lepiej nadaje się iPerf lub inna zdefiniowana konfiguracja testowa.

Rozwiązywanie problemów po teście

Jeśli po teście prędkości nadal nie jest jasne, gdzie leży problem, należy kontynuować w sposób uporządkowany:

1. Sprawdź Device Console: użyj dnslookup, ping i traceroute, zanim zinterpretujesz wartości pobierania.
2. Sprawdź Log Viewer: Która zasada zapory dotyczy ruchu klienta?
3. Użyj Policy Test: Sprawdź oczekiwane źródło, cel, usługę i użytkownika.
4. Uruchom Packet Capture: Czy widać pakiety, pakiety odpowiedzi i NAT?
5. Sprawdź status interfejsu: Oceń prędkość łącza, błędy, straty i obciążenie.
6. Sprawdź funkcje bezpieczeństwa: IPS, filtr sieciowy, inspekcja TLS, kontrola aplikacji.
7. Przeprowadź test porównawczy z iPerf: Testuj ścieżkę, TCP/UDP i kierunek celowo.

Dla analiz zasad i przepływu pakietów pasuje Testowanie zasady zapory za pomocą Log Viewer, Policy Test i Packet Capture. Dla głębszych logów pomaga Rozwiązywanie problemów z Sophos Firewall: Usługi i logi.

Lista kontrolna

Przed testem

• Świadomie dozwolony dostęp SSH lub Advanced Shell.
• Device Access albo Local Service ACL exception rule dla SSH ograniczone w czysty sposób.
• DNS i osiągalność sprawdzone przez Device Console.
• Wybrany czas testu.
• Znana ścieżka WAN.
• Wystarczająca ilość miejsca na dysku.
• Zdefiniowany cel pomiaru: test WAN, porównanie klienta lub rozgraniczenie VPN.

Podczas testu

• Pobierz plik testowy do /tmp.
• Zanotuj prędkość pobierania i jednostkę.
• W przypadku błędów nie myl DNS, routingu lub dostępności z prędkością.
• Nie przeprowadzaj równolegle dużych zmian w zasadach zapory lub SD-WAN.

Po teście

• Usuń plik testowy.
• Przelicz wynik na Mbit/s.
• Porównaj z testem klienta lub iPerf.
• W przypadku rozbieżności użyj Log Viewer, Policy Test i Packet Capture.
• Udokumentuj wynik z czasem, łączem WAN i celem testu.

FAQ