Hoppa till innehållet
Avanet

Utföra ett internet-hastighetstest på Sophos Firewall via SSH

Ett internet-hastighetstest i webbläsaren visar inte alltid vad internetanslutningen verkligen kan prestera. Webbläsare, klient, WLAN, proxy, IPS, webbfilter, TLS-inspektion, VPN, NAT och brandväggsregler kan påverka resultatet. Ibland är det därför användbart med ett test direkt på Sophos Firewall för att avgränsa brandväggens WAN-anslutning från klient- eller regelproblem.

Artikeln beskriver ett enkelt nedladdningstest via SSH på Sophos Firewall, rätt tolkning av resultatet och gränserna jämfört med iPerf, Log Viewer eller Packet Capture. Särskilt viktigt är avgränsningen vid flera WAN-anslutningar: Testet mäter brandväggens egen nedladdningstrafik, inte automatiskt samma väg som en klient bakom brandväggen.

Vilket prestandatest passar?

En nedladdning direkt på brandväggen är bara ett verktyg. Beroende på frågeställningen kan ett annat test vara mer meningsfullt:

Denna uppdelning förhindrar feltolkningar. En snabb brandväggsnedladdning bevisar inte att en klientväg, en VPN-sträcka eller en TLS-inspektionsregel också måste vara snabb.

Vad ett hastighetstest på brandväggen bevisar

Ett hastighetstest direkt på brandväggen besvarar en konkret fråga: Kan brandväggen själv ladda ner en fil från internet med förväntad hastighet över sin aktuella routingväg?

Detta är användbart om man vill veta:

  • om WAN-linjen i grunden är tillräckligt snabb
  • om leverantörsanslutningen ungefär levererar den förväntade nedladdningshastigheten
  • om ett problem ligger före eller bakom brandväggen
  • om klient, WLAN, switch, webbfilter, TLS-inspektion eller VPN behöver inkluderas i analysen

Testet bevisar dock inte automatiskt att klienter bakom brandväggen måste uppnå samma hastighet. Klienttrafik går genom brandväggsregler, NAT, säkerhetspolicyer och beroende på konfiguration genom IPS, webbskydd, applikationskontroll eller TLS-inspektion. Den lokala nedladdningen på brandväggen kringgår delar av denna bearbetning och är därför lämplig som avgränsning, inte som ett fullständigt end-to-end-test.

För att tolka databladsvärden, säkerhetsfunktioner och verklig prestanda passar Förstå Sophos Firewalls prestandadata korrekt som ett komplement.

Beakta flera WAN-anslutningar och SD-WAN

För brandväggar med flera WAN-länkar bör man innan testet klargöra vilken väg brandväggen själv använder för att ansluta till internet. Nedladdningen genereras av Sophos Firewall. Det är därmed systemegen trafik och följer inte nödvändigtvis samma beslut som en klientflöde som bearbetas av en brandväggsregel, NAT-regel eller SD-WAN-rutt.

Typiska missuppfattningar:

  • Flera WAN-gateways: Brandväggsnedladdningen kan gå via en annan gateway än den berörda klienttrafiken
  • SD-WAN-routing för klienter: Klient-SD-WAN-regler bevisar inte automatiskt vägen för systemegen trafik
  • Failover eller backup-WAN aktiv: Testet mäter eventuellt just nu reservvägen
  • Policy-baserad routing eller speciell NAT: En klientväg kan behandlas annorlunda än den lokala brandväggsnedladdningen

Vid sådana uppsättningar bör man alltid dokumentera resultatet med tidpunkt, aktiv WAN-länk och observerad gateway. Om systemegen trafik, svarspaket eller SD-WAN-beslut är oklara, passar Förstå Sophos Firewall SD-WAN Routing, Reply Packet och System Traffic som ett komplement.

Förutsättningar

Innan testet bör dessa punkter vara uppfyllda:

  • SSH eller Advanced Shell-åtkomst är medvetet tillåten, helst endast från ett betrott administrationsnät.
  • Brandväggen har internetåtkomst och DNS fungerar.
  • Det finns ett underhållsfönster eller åtminstone en okritisk tidpunkt.
  • Det är klart över vilket WAN-gränssnitt brandväggen utför nedladdningen.
  • Tillräckligt med ledigt diskutrymme för testfilen finns.
  • Testfilen tas bort efter testet.

För säker SSH-åtkomst passar Anslut till Sophos Firewall via SSH. I SFOS tillåts SSH under Administration > Device access via Local service ACL eller mer exakt via en Local service ACL exception rule. SSH bör inte tillåtas brett från WAN- eller Wi-Fi-zoner och bör efter felsökningsuppgifter begränsas till det nödvändiga minimum. Sophos Firewall stänger inaktiva SSH-sessioner efter 15 minuter.

⚠️ Ett nedladdningstest genererar verklig trafik och kan tillfälligt belasta linjen. På produktiva brandväggar bör sådana tester inte utföras under kritiska arbetstider eller parallellt med backup-, VoIP- eller underhållsfönster.

Kontrollera DNS och routing före nedladdningen

Innan man laddar ner en stor testfil bör man kort kontrollera om namnupplösning och nåbarhet fungerar i grunden. Annars förväxlas DNS-, routing- eller leverantörsproblem lätt med ett speedtest-resultat.

Öppna först 4 Device Console i CLI-huvudmenyn och kör enkla kontroller:

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

dnslookup kontrollerar namnupplösningen, ping ger ett snabbt nåbarhetstest och traceroute visar den grova vägen till målet. Sophos stöder i Device Console ytterligare ping-parametrar som interface eller sourceip. Det är användbart vid flera WAN-anslutningar när en viss källa eller ett visst gränssnitt ska kontrolleras.

Om DNS redan misslyckas är det efterföljande curl-testet inte meningsfullt. Kontrollera då först DNS, default route, WAN-gateway, SD-WAN-beslut eller leverantörstillgänglighet.

Utföra hastighetstest via SSH

Logga in på Sophos Firewall via SSH som admin. Välj 5 Device Management i CLI-huvudmenyn och öppna därefter 3 Advanced Shell. Advanced Shell är ett Linux-shell med djup åtkomst till systemkomponenter. I den här artikeln används det endast för att ladda ner en fil till /tmp och sedan ta bort den igen.

Ladda sedan ner testfilen till en temporär katalog så att den inte av misstag hamnar i en olämplig arbetskatalog.

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

Testservern finns i Schweiz och är avsedd för en grov linjemätning. För mindre tester kan istället för 1GB.bin även 100MB.bin användas:

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

Om DNS inte fungerar misslyckas testet redan vid namnupplösningen. Då bör man inte analysera linjehastigheten utan först DNS, routing och WAN-tillgänglighet.

För brandväggar med flera WAN-länkar bör testet inte betraktas isolerat. Parallellt bör man i WebAdmin kontrollera vilken WAN-länk som är aktiv och om det just nu finns ett failover, en SD-WAN-ändring eller en leverantörsstörning.

Ta bort testfilen

Efter testet bör filen tas bort:

rm /tmp/1GB.bin

Vid ett test med den mindre filen:

rm /tmp/100MB.bin

Om testet avbröts, kontrollera ändå om en delvis nedladdad fil finns:

ls -lh /tmp/*GB.bin

Stora testfiler bör inte lämnas kvar på brandväggen. Särskilt på små enheter eller redan fyllda partitioner kan onödig minnesanvändning senare leda till svårbegripliga problem.

Utvärdera hastighetstestet

Under och efter nedladdningen visar curl bland annat den genomsnittliga nedladdningshastigheten. I exemplet ligger värdet på cirka 107 MB/s.

Sophos Firewall hastighetstest av internetanslutningen
Sophos Firewall hastighetstest av internetanslutningen

Viktigt är enheten:

  • MB/s betyder megabyte per sekund.
  • Mbit/s eller Mbps betyder megabit per sekund.
  • 1 byte motsvarar 8 bitar.

Som grov omvandling gäller:

MB/s x 8 = Mbit/s

107 MB/s motsvarar alltså ungefär 856 Mbit/s. Overhead, TCP-beteende, motpart, routing och belastning kan påverka värdet. Därför bör man inte använda en enskild mätning som slutgiltigt bevis.

Omvandla nedladdningshastighet
Omvandla nedladdningshastighet

Det är meningsfullt med flera tester vid olika tidpunkter på dagen. Om värdena varierar kraftigt bör man kontrollera leverantör, WAN-länk, SD-WAN-routing, gränssnittsfel och belastning.

För support eller intern dokumentation bör man inte bara notera siffran. En kort mätdatauppsättning hjälper senare betydligt:

  • Tidpunkt: 2026-06-21 10:15
  • Brandvägg och firmware: XGS 2100, SFOS 22.0 MR1
  • Testfil: 1GB.bin
  • Uppmätt hastighet: 107 MB/s, ungefär 856 Mbit/s
  • Aktiv WAN-länk: WAN1 Fiber
  • Avvikelser: parallell backup, failover, hög CPU, Packet Capture aktiv

När flera mätningar jämförs bör testfil, mål, tidpunkt och WAN-väg helst förbli desamma. Annars jämför man snabbt tidpunkt på dagen, leverantörsväg eller motpart istället för den faktiska brandväggsprestandan.

Jämför med klienttester

Nästa steg är att jämföra med en klient bakom brandväggen. Detta gör det möjligt att avgränsa var prestanda går förlorad.

  • Nedladdning direkt på brandväggen är snabb: Brandväggens WAN-anslutning är troligen inte den huvudsakliga flaskhalsen
  • Nedladdning direkt på brandväggen är långsam: Kontrollera leverantör, WAN-länk, routing, DNS eller brandväggs-uppkoppling
  • Brandvägg snabb, klient långsam: Kontrollera klient, WLAN, switch, brandväggsregel, NAT, säkerhetspolicy eller TLS-inspektion
  • Endast enskilda applikationer långsamma: Kontrollera webbfilter, applikationskontroll, DNS, proxy eller målserver
  • Endast VPN långsamt: Kontrollera VPN-protokoll, MTU/MSS, routing, brandväggsregler och klientnät

För riktade sträcktester är iPerf ofta bättre än en offentlig nedladdning. Med iPerf kan man definiera var server och klient står, om TCP eller UDP testas och vilken bandbredd som förväntas.

Typiska feltolkningar

Brandväggshastighetstest är snabbt, användare rapporterar ändå långsamt internet

Då är WAN-linjen inte automatiskt oskyldig, men fokus förskjuts. Man bör kontrollera klientnät, WLAN, switchport, DNS, brandväggsregel, NAT, IPS, webbskydd, applikationskontroll och TLS-inspektion. Särskilt TLS-inspektion eller aggressiva säkerhetsprofiler kan behandla klienttrafik betydligt annorlunda än en nedladdning direkt på brandväggen.

Webbläsarhastighetstest är långsamt, brandväggshastighetstest är snabbt

Detta talar ofta för ett problem bakom brandväggen eller i klientvägen. Ändå bör man testa flera webbläsare, en trådbunden klient och ett andra mål innan man antar en fast orsak.

Brandväggshastighetstest är långsamt

Då bör man först kontrollera WAN-status, länkhastighet, duplex, SD-WAN-routing, DNS, leverantörsstörning och belastning. Vid flera WAN-anslutningar bör det vara klart över vilket gateway nedladdningen går.

Endast uppladdning är långsam

Den här beskrivna curl-nedladdningen testar främst nedladdningsriktningen. För uppladdnings- eller bidirektionella tester är iPerf eller en annan definierad testuppsättning bättre lämpad.

Felsökning efter testet

Om det efter hastighetstestet fortfarande är oklart var problemet ligger bör man fortsätta strukturerat:

  1. Device Console: använd dnslookup, ping och traceroute innan nedladdningsvärden tolkas.
  2. Log Viewer: Vilken brandväggsregel träffar klienttrafiken?
  3. Policy Test: Kontrollera förväntad källa, destination, tjänst och användare.
  4. Packet Capture: Ser man paket, svarspaket och NAT?
  5. Gränssnittsstatus: Utvärdera länkhastighet, fel, droppar och belastning.
  6. Säkerhetsfunktioner: IPS, webbfilter, TLS-inspektion, applikationskontroll.
  7. Motkontroll med iPerf: Testa sträcka, TCP/UDP och riktning målmedvetet.

För regel- och paketflödesanalyser passar Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture. För de djupare loggfilerna hjälper Sophos Firewall Troubleshooting: Services och Logs.

Checklista

Före testet

  • SSH eller Advanced Shell-åtkomst medvetet tillåten.
  • Device Access eller Local Service ACL exception rule för SSH tydligt begränsad.
  • DNS och nåbarhet kontrollerade via Device Console.
  • Testtidpunkt vald.
  • WAN-väg känd.
  • Tillräckligt med lagringsutrymme tillgängligt.
  • Mål för mätningen definierat: WAN-test, klientjämförelse eller VPN-avgränsning.

Under testet

  • Ladda ner testfil till /tmp.
  • Notera nedladdningshastighet och enhet.
  • Vid fel, förväxla inte DNS, routing eller tillgänglighet med hastighet.
  • Utför inga parallella stora ändringar av brandväggsregler eller SD-WAN.

Efter testet

  • Ta bort testfil.
  • Omvandla resultat till Mbit/s.
  • Jämför med klient- eller iPerf-test.
  • Vid avvikelser, använd Log Viewer, Policy Test och Packet Capture.
  • Dokumentera resultat med tidpunkt, WAN-länk och testmål.

FAQ

Kan man med detta test mäta den verkliga internethastigheten?

Man mäter brandväggens nedladdningshastighet till ett specifikt testmål. Det är en bra indikation på WAN-anslutningen, men inget fullständigt end-to-end-test för klienter bakom brandväggen.

Varför är ett webbläsarhastighetstest bakom brandväggen annorlunda?

Klienttrafik kan påverkas av WLAN, switchar, brandväggsregler, NAT, IPS, webbskydd, TLS-inspektion eller applikationskontroll. En nedladdning direkt på brandväggen använder inte samma bearbetningsväg.

Bör man testa 100 MB eller 1 GB?

För snabba linjer är 1 GB mer meningsfullt eftersom testet pågår längre. För korta kontroller eller mindre anslutningar räcker ofta 100 MB. På små brandväggar eller vid begränsat minne bör man testa försiktigt och sedan ta bort filen.

Är iPerf bättre än curl?

För riktade prestandaanalyser oftast ja. curl är snabbt och enkelt för ett WAN-nedladdningstest. iPerf är bättre om man vill kontrollera riktning, mål, TCP/UDP, varaktighet och bandbredd.

Är curl-testet ett officiellt Sophos-speedtest?

Nej. Sophos dokumenterar CLI-åtkomst, Device Console och Advanced Shell, men inget eget officiellt internethastighetstest via curl. Testet är en praktisk Avanet-metod för att avgränsa WAN-anslutningen och måste kompletteras med klienttester, loggar eller iPerf.

Varför måste testfilen tas bort?

Brandväggen är ingen filserver. Stora testfiler förbrukar lagringsutrymme och kan på små enheter eller fulla partitioner senare orsaka problem.

Varför kan brandväggshastighetstestet vid flera WAN vara annorlunda än ett klienttest?

Testet genereras av brandväggen själv. Det kan därmed använda en annan routingväg än klienttrafik som går genom brandväggsregler, NAT eller SD-WAN-rutter. Vid flera WAN-länkar bör den aktiva vägen därför alltid dokumenteras.