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

Pobieranie uruchomione bezpośrednio w Advanced Shell odpowiada na jasno określone pytanie: jaką prędkość pobierania osiąga sam Sophos Firewall przez swoją aktualną ścieżkę WAN? Pozwala to odróżnić wolne łącze internetowe od problemów w sieci klienta, WLAN, VPN lub polityce bezpieczeństwa.

Test nie jest pełnym testem end-to-end. Ruch generowany przez zaporę nie przebiega tą samą trasą co ruch klienta za zaporą. Do kontrolowanego pomiaru między dwoma endpointami lepiej nadaje się iPerf za Sophos Firewall; wartości z datasheetu i wpływ włączonych funkcji bezpieczeństwa wyjaśnia artykuł o parametrach wydajności Sophos Firewall.

Przed testem prędkości

Test wymaga dostępu SSH, działającego DNS i niekrytycznego momentu. Do szybkiej kontroli dostępny jest plik 100 MB; na szybkich łączach plik 1 GB zwykle zapewnia stabilniejszą średnią. Oba pobrania mogą na krótko całkowicie obciążyć łącze i nie należy ich uruchamiać podczas backupów, szczytowego ruchu VoIP, testów failover ani innych prac konserwacyjnych.

Dostęp SSH włącza się w Administration > Device access za pomocą Local service ACL lub bardziej precyzyjnie przez Local service ACL exception rule. Powinien być dozwolony wyłącznie z zaufanej sieci administracyjnej, a po zakończeniu prac ponownie ograniczony do niezbędnego minimum. Logowanie opisano w artykule Łączenie z Sophos Firewall przez SSH. Sophos Firewall kończy nieaktywne sesje SSH po 15 minutach.

⚠️ Nie rozpoczynać testu, jeśli aktywna ścieżka WAN lub wpływ na działanie nie są jasne. W przypadku nieoczekiwanie wysokiego obciążenia CPU, zakłóceń lub niewłaściwej bramy przerwać pobieranie za pomocą Ctrl+C. Użyta niżej ścieżka wyjściowa /dev/null nie zapisuje pliku testowego na zaporze.

Sprawdzanie ścieżki WAN przy wielu łączach

Pobieranie jest ruchem generowanym przez system. Trasa SD-WAN dla klientów nie określa więc automatycznie jego ścieżki. W 4 Device Console to polecenie tylko do odczytu pokazuje, czy odpowiednie trasy SD-WAN mogą również obejmować ruch generowany przez system:

show routing sd-wan-policy-route system-generate-traffic

Jeśli opcja jest włączona, odpowiednia trasa SD-WAN może wpływać na ścieżkę pobierania. Jeśli jest wyłączona, zapora korzysta ze standardowych decyzji routingu i WAN. Polecenie nie dowodzi jeszcze, której bramy faktycznie używa konkretne pobieranie. Należy dodatkowo sprawdzić aktywne bramy w Network > WAN link manager oraz stan i pasujące trasy w Routing > SD-WAN routes.

Również ping z interface lub sourceip stanowi jedynie wskazówkę dla tego testu ICMP; późniejsze pobieranie HTTPS może mimo to zostać poprowadzone inną trasą. Zależności te wyjaśnia artykuł SD-WAN Routing, Reply Packet i System Traffic. Na potrzeby testu prędkości nie należy specjalnie zmieniać żadnej opcji routingu.

Przeprowadzanie testu prędkości Internetu przez SSH

1. Sprawdzanie powłoki i narzędzia do pobierania

Po zalogowaniu przez SSH jako admin otworzyć 5 Device Management > 3 Advanced Shell w głównym menu CLI. Sophos dokumentuje dostęp do tej powłoki, ale nie gwarantuje curl jako interfejsu SFOS. Najpierw, bez pobierania danych, sprawdzić dostępność narzędzia w zainstalowanym firmware:

curl --version

Jeśli wynik pokazuje wersję i obsługiwane protokoły, można kontynuować. Jeśli powłoka zgłasza curl: not found lub błąd opcji, nie należy instalować pakietów ani zmieniać systemu plików zapory. Zamiast tego użyć testu na kliencie lub podlinkowanej procedury iPerf, a w razie potrzeby skontaktować się z Sophos Support.

Właściwe wywołanie curl sprawdza DNS i HTTPS. Opcja --fail powoduje, że błąd HTTP zwraca niezerowy status wyjścia; sam wskaźnik postępu nie jest wtedy prawidłowym wynikiem pomiaru.

2. Pomiar pobierania bez zapisywania pliku

Advanced Shell to powłoka Linux z głębokim dostępem do systemu. Poniższe polecenie pobiera dane, ale odrzuca je przez /dev/null. Zapis dużego pliku nie wpływa więc na wynik i nie jest potrzebne czyszczenie pamięci masowej.

Do krótkiego testu pobrać plik 100 MB:

curl --location --fail --output /dev/null \
  --write-out '\nHTTP %{http_code} | %{size_download} bytes | %{speed_download} bytes/s\n' \
  https://www.avanet.io/100MB.bin

Na szybkich łączach należy w tym samym poleceniu zastąpić wyłącznie URL adresem https://www.avanet.io/1GB.bin. --location obsługuje przekierowania, --fail traktuje błędy HTTP jako niepowodzenia, a --output /dev/null zapobiega utworzeniu lokalnego pliku. W momencie publikacji endpointy zwracają 104857600 bajtów dla 100 MB i 1048576000 bajtów dla 1 GB.

Plik jest dostarczany przez Avanet i Cloudflare. Cel testu, stan cache, peering, routing i obciążenie CPU mogą wpływać na wynik. Wartość jest więc praktycznym pomiarem porównawczym, a nie gwarantowaną wydajnością operatora lub zapory.

3. Kontrola statusu i liczby przesłanych bajtów

Oceniać tylko przebieg zakończony bez błędu curl, z HTTP 200 i wartością size_download zgodną z podaną wyżej. Mniejsza wartość oznacza przerwanie transferu; HTTP 000 zwykle wskazuje problem z DNS, połączeniem lub TLS. Inny kod HTTP oznacza, że endpoint testowy jest w danym momencie niedostępny. Plik testowy nie powstaje. Na zakończenie wyjść z Advanced Shell poleceniem exit i usunąć wyjątek ACL SSH utworzony wyłącznie na potrzeby testu.

Prawidłowa interpretacja wyniku

speed_download podaje średnią prędkość pobierania w bajtach na sekundę. Aby uzyskać Mbit/s, należy pomnożyć wartość przez osiem i podzielić przez milion. Zwykły wskaźnik postępu pokazuje też Average Speed; na istniejącym zrzucie widnieje 107M.

M w tym wskaźniku postępu jest oparte na 1024 i odpowiada MiB/s. Łącza internetowe są natomiast podawane w dziesiętnych Mbit/s. Dla przykładu:

107 x 1048576 x 8 / 1000000 = 897.6 Mbit/s

107M odpowiada zatem około 898 Mbit/s, a nie 856 Mbit/s. Narzut, zachowanie TCP, endpoint zdalny, routing i bieżące obciążenie zazwyczaj uniemożliwiają w praktyce dokładną zgodność z wartością pakietu internetowego.

Pojedyncze uruchomienie nie stanowi wiarygodnej diagnozy. Kolejne pomiary powinny w miarę możliwości odbywać się względem tego samego celu, tą samą ścieżką WAN i w porównywalnych warunkach. Dla supportu lub dokumentacji wewnętrznej przydatny jest następujący zestaw danych:

• Czas: na przykład 2026-06-21 10:15
• Zapora i firmware: na przykład XGS 2100, SFOS 22.0 MR1
• Plik testowy: 100MB.bin lub 1GB.bin
• Zmierzona prędkość: na przykład 107M, około 898 Mbit/s
• Aktywne łącze WAN: na przykład WAN1 Fiber
• Nieprawidłowości: równoległy backup, failover, wysokie użycie CPU lub aktywny Packet Capture

Co oznacza wynik

Pobieranie przez zaporę pomaga rozgraniczyć przyczynę, ale nie stanowi ostatecznego dowodu. Połączenie tego pomiaru z testem klienta wskazuje, gdzie szukać dalej:

• Zapora szybka, klient wolny: sprawdzić klienta, WLAN, port przełącznika, DNS, regułę zapory, NAT, IPS, Web Protection, Application Control i TLS Inspection. Pomagają w tym Log Viewer, Policy Test i Packet Capture oraz w razie potrzeby ukierunkowany Packet Capture.
• Zapora i klient działają wolno: porównać stan WAN, Link Speed, duplex, błędy i dropy interfejsu, aktywną bramę, awarię operatora, obciążenie CPU oraz drugi cel testu.
• Wolne są tylko poszczególne aplikacje: porównać DNS, Web Protection, Application Control, proxy, TLS Inspection i endpoint zdalny.
• Wolny jest tylko VPN: sprawdzić protokół VPN, routing oraz MTU i MSS.
• Wolny jest tylko upload: ta procedura curl mierzy wyłącznie download. Do uploadu lub obu kierunków lepiej nadaje się kontrolowany test iPerf.
• Wartości zmieniają się przez dłuższy czas: powtórzyć porównywalne pomiary i w razie potrzeby monitorować ruch interfejsu za pomocą sFlow Monitoring.

Jeśli przyczyna nadal jest niejasna, najpierw należy sprawdzić przepływ danego klienta i regułę, która faktycznie została dopasowana. Do głębszych analiz artykuł Rozwiązywanie problemów z Sophos Firewall: usługi i logi wskazuje, który plik logu należy do danej usługi.

FAQ