Tolka Sophos Firewall Live Connections korrekt

Live Connections visar vilka anslutningar som för närvarande är aktiva på Sophos Firewall. Vyn ger snabbt svar på vilken klient, användare eller applikation som genererar trafik, vilka gränssnitt som används och vilken brandväggs- eller NAT-regel som hanterar sessionen. För en enskild anslutning ger Diagnostics > Connection list ännu fler tekniska detaljer.

Båda vyerna är ögonblicksbilder. De ersätter varken Log Viewer för loggade beslut eller Packet Capture för det faktiska paketflödet. Rätt kombinerade sparar de däremot mycket tid: hitta först den aktiva sessionen och kontrollera sedan loggar och paket vid behov.

Live Connections i sju steg

1. Definiera testflödet: käll-IP, destinations-IP, protokoll, källport om den är känd, destinationsport och exakt tidpunkt.
2. Skapa en ny anslutning från testklienten, till exempel HTTPS från 192.0.2.25 till 198.51.100.50 via TCP 443.
3. Öppna Current activities > Live connections och gruppera efter Source IP address.
4. Filtrera på 192.0.2.25 och öppna de enskilda anslutningarna via Total.
5. Anteckna Start time, In interface, Out interface, Source, Destination, portar, Firewall Rule ID och NAT Rule ID.
6. Filtrera samma flöde så exakt som möjligt under Diagnostics > Connection list > Display filter och jämför Translated source, Translated destination, Gateway ID, Policy IDs samt RX/TX.
7. Vid avvikelser ska flödet korreleras i Log Viewer och Packet Capture innan regler, NAT eller routing ändras.

Adresserna 192.0.2.25 och 198.51.100.50 kommer från dokumentationsnät. I ett verkligt test ska de ersättas med klientens och målets faktiska adresser. TCP 443 passar endast när en HTTPS-anslutning verkligen testas.

⚠️ Vyerna innehåller interna IP-adresser, användarnamn, applikationer och kommunikationsrelationer. Begränsa därför filter och skärmbilder och dela endast supportdata med behöriga mottagare.

Skilj mellan Live Connections och Connection List

De två vyerna använder aktuell anslutningsstatus men är avsedda för olika frågor.

Live Connections för överblicken

Under Current activities > Live connections kan aktiva anslutningar grupperas efter:

• Application
• Source IP address
• Username

Vyn visar upload, download, genomsnittligt utnyttjad bandbredd, egenskaper och antalet sessioner. Den hjälper vid frågor som: vilken klient genererar mycket trafik just nu? Vilken applikation är aktiv? Vilken användare har flera öppna anslutningar?

De visade överföringsvärdena gäller tiden sedan anslutningen upprättades. Upstream bandwidth och Downstream bandwidth beräknas utifrån överförda byte och den hittillsvarande anslutningstiden. De är därför inget linjetest sekund för sekund. För ett prestandatest passar korrekt användning av iPerf3 med Sophos Firewall bättre.

Endast ett filter kan vara aktivt åt gången i Live Connections. Käll-IP är vanligtvis den tydligaste startpunkten. Username eller Application är användbart när klienten redan är korrekt autentiserad eller applikationen har identifierats.

Connection List för den enskilda sessionen

Under Diagnostics > Connection list visas varje aktuell anslutning på en egen rad. Den här vyn är mer teknisk och visar bland annat:

• In interface och Out interface
• Source och Destination med portar
• Protocol och Application
• Rule ID och NAT ID
• User och User group
• Policy IDs för Web, Application, IPS, Traffic Shaping och Remote Access
• Gateway ID
• Translated source och Translated destination
• Expiry, RX/TX bytes och RX/TX packets
• Connection served by

Display filter kan innehålla flera kända egenskaper för testflödet. På så sätt begränsas en lång lista till ett litet antal matchande sessioner.

Vad ingen av vyerna bevisar

En synlig session bevisar att det finns en aktuell connection-tracking-post. Den bevisar inte automatiskt:

• att varje begäran och varje svar överfördes fullständigt
• att målservern behandlade applikationen korrekt
• att ett tidigare fel i samma flöde fortfarande finns tillgängligt historiskt
• att den valda brandväggs- eller NAT-regeln är funktionellt korrekt
• att en grön post inte innehåller paketförlust, omsändning eller MTU-problem

Historiska beslut kräver loggning. Ingress, egress, svar och drops kräver Packet Capture. För själva applikationen är server-, klient- eller SaaS-loggar fortfarande relevanta.

Förbered ett kontrollerat testflöde

Ett användbart test börjar inte med en slumpmässig omladdning av webbläsaren. Definiera först femtuplen:

• käll-IP
• destinations-IP
• protokoll
• källport
• destinationsport

Källporten är ofta dynamisk för klientanslutningar. Om den ännu inte är känd räcker käll-IP, destinations-IP, protokoll och destinationsport för det första filtret. Efter träffen kan den konkreta källporten hämtas från sessionen.

Definiera också vad som förväntas:

• In interface och Out interface
• Firewall Rule ID och i förekommande fall NAT Rule ID
• användare eller användargrupp om regeln använder identitet
• Gateway eller SD-WAN-sökväg
• förväntad Source och Destination efter NAT
• exakt testtid med tidszon

Skapa alltid en ny anslutning efter ändringar

Befintliga sessioner behåller sitt etablerade tillstånd. Särskilt NAT-beslut omprövas inte för varje efterföljande paket. Avsluta därför applikationssessionen och skapa ett nytt flöde efter en ändring av regel, NAT, routing eller SD-WAN.

En omladdning av webbläsaren kan fortsätta använda samma TCP-, HTTP/2- eller HTTP/3-anslutning. Ett nytt privat webbläsarfönster, en omstartad klientprocess eller ett annat kontrollerat test som säkert öppnar en ny anslutning hjälper till vid tillförlitlig verifiering. Den exakta metoden ska passa applikationen och får inte oavsiktligt avbryta en produktionssession.

Använd Live Connections för att hitta den första posten

1. Öppna Current activities > Live connections.
2. Välj ett Automatic refresh interval som passar testet eller uppdatera manuellt med Refresh.
3. Välj Source IP address för en känd klient.
4. Öppna filtret, välj en lämplig modifierare och ange käll-IP.
5. Kontrollera Transfer, Bandwidth och Total på raden.
6. Klicka på siffran under Total för att öppna de enskilda anslutningarna på en ny flik.
7. Identifiera det matchande flödet med hjälp av Start time, gränssnitt, IP-adresser, portar och Protocol.

En mycket kort DNS-, ICMP- eller webbförfrågan kan redan ha försvunnit innan sidan uppdateras. Ställ då först in filtret, förbered Refresh och utlös testet exakt en gång till.

Tolka Other applications och DNS korrekt

Other applications innehåller oidentifierade applikationer och systemgenererad trafik, exempelvis signaturnedladdningar, konsolåtkomst eller DNS-förfrågningar från själva brandväggen. Det är inte automatiskt en felkategori.

DNS kräver extra uppmärksamhet: trafik mellan en intern klient och en extern DNS-server omfattas av normala brandväggsregler och visas som DNS. Systemgenererad DNS-trafik från brandväggen kan däremot visas både under DNS och Other applications.

Om en applikation inte identifieras och Security Heartbeat är aktivt kan Connection List erbjuda upplösning av Application Information för anslutna endpoints. Utan en ansluten Sophos Endpoint eller utan Heartbeat kan No information available fortfarande visas. Ett okänt namn innebär därför inte automatiskt skadlig trafik.

Firewall Rule ID 0 beror på sammanhanget

Systemgenererad trafik har Firewall Rule ID 0 i Live Connections eftersom normala brandväggsregler inte styr den trafiken. Åtkomst till lokala brandväggstjänster styrs i stället bland annat av Administration > Device access och Local Service ACL. Device Access och Local Service ACL förklarar den säkra konfigurationen.

Denna 0 får inte läsas utan sammanhang som en implicit dropregel. Rule #0 i en brandväggslogg eller Packet Capture kan ha ett annat diagnostiskt sammanhang. Avgörande är vyn, Status, Reason och om det gäller systemtrafik eller vidarebefordrad klienttrafik.

Begränsa Connection List till ett flöde

1. Öppna Diagnostics > Connection list.
2. Välj Display filter.
3. Ställ in Network protocol på IPv4 eller IPv6 i enlighet med testet.
4. Ange käll-IP och destinations-IP.
5. Lägg till Packet type och käll- eller destinationsport om de är kända.
6. Ange förväntad Rule ID när sökningen specifikt gäller aktiva sessioner för den regeln.
7. Använd filtret med OK och jämför träffarna med testtiden.

Ett tomt resultat bevisar inte att brandväggen blockerar trafiken. Sessionen kan redan ha avslutats, klienten kan använda en annan destinationsadress från DNS eller CDN, NAT kan ändra den synliga adressen eller testet kan ha behandlats av den andra HA-noden. Kontrollera först testflödet och observationsriktningen i stället för att bredda brandväggsregeln.

Läs de viktigaste fälten tillsammans

• Time: anslutningens starttid. Den ska motsvara det kontrollerade testet.
• In interface / Out interface: visar den in- och utgående väg som sessionen använder.
• Source / Destination / Ports: definierar det synliga flödet före detaljtolkningen.
• Rule ID: visar den brandväggsregel som tillåter sessionen.
• NAT ID: visar den berörda NAT-regeln.
• Translated source / Translated destination: gör SNAT, MASQ, DNAT eller PAT synligt.
• Gateway ID: kopplar sessionen till en gateway och är särskilt viktig vid WAN- eller SD-WAN-frågor.
• Username / User group: visar om den förväntade användarkontexten är kopplad till sessionen.
• Policy IDs: visar vilken Web-, Application-, IPS-, Traffic Shaping- eller Remote Access-policy som tilldelats.
• Expiry: visar efter hur många sekunder en inaktiv session upphör.
• RX/TX bytes och packets: hjälper till att se om bara en riktning överför data eller om båda är aktiva.
• Connection served by: visar vilken brandvägg som behandlar anslutningen i en HA-miljö.

Läs alltid Rule ID och NAT ID tillsammans med gränssnitt, adresser och portar. En förväntad Rule ID med en oväntad NAT ID innebär ett NAT-matchningsproblem. Om båda ID-numren stämmer men Out interface eller Gateway inte gör det, ska routing eller SD-WAN kontrolleras härnäst. NAT på Sophos Firewall förklarar grunderna.

Övertolka inte Related Connections

Ett klick på Connection ID kan visa beroende anslutningar, exempelvis för Web Proxy, FTP, SIP eller andra protokoll med relaterade sessioner. Om inget beroende flöde finns förblir vyn tom. En tom Related Connections-vy är därför inget bevis på ett fel.

Korrelera aktiv session, Log Viewer och Packet Capture

De tre verktygen besvarar tre olika frågor i tur och ordning:

1. Live Connections eller Connection List: vilken session finns just nu och vilka ID-nummer, gränssnitt, adresser, policyer och gatewaytilldelningar har den?
2. Log Viewer: vilket brandväggs-, NAT- eller säkerhetsbeslut loggades?
3. Packet Capture: anländer paketen, vidarebefordras de och kommer svaren tillbaka?

För en tillförlitlig jämförelse:

1. Anteckna testtid och femtupel.
2. Anteckna den aktiva sessionen och Connection ID.
3. Dokumentera Rule ID, NAT ID, In/Out interface, Gateway och översatta adresser.
4. Filtrera Log Viewer efter källa, destination, port och tid.
5. Starta Packet Capture med ett snävt BPF-filter om svaret saknas eller vägen är oklar.
6. Dokumentera resultatet innan konfigurationen ändras.

Om Live Connections visar en session men ingen matchande brandväggshändelse finns i Log Viewer ska först Log firewall traffic, Local reporting och filtren kontrolleras. Arbetsgången finns i Log Viewer visar inga nya loggar.

Device Console erbjuder dessutom system diagnostics utilities connections. Den aktuella offentliga hjälpen dokumenterar verktyget men inte alla buildberoende alternativ. Kontrollera därför den tillgängliga syntaxen med ? före användning och använd utdata skrivskyddat. Sophos Firewall CLI-felsökning beskriver den säkra ramen.

Typiska symptom

Den förväntade sessionen visas inte

Kontrollera först om flödet fortfarande är aktivt och om källa, destination och IP-version är korrekta. Med DNS, CDN, proxy, NAT eller IPv6 kan den faktiska destinationsadressen skilja sig från antagandet. Skapa ett nytt test och starta Packet Capture parallellt om det är oklart om brandväggen över huvud taget tar emot paket.

Fel Rule ID eller NAT ID visas

En mer generell regel högre upp i listan kan vinna. Jämför ordningen för brandväggs- och NAT-regler, zoner, källa, destination, tjänst, användare och schema. Flytta inte flera regler samtidigt. Den guidade arbetsgången finns i Testa en Sophos Firewall-regel korrekt.

Endast en riktning räknar RX eller TX

Det kan tyda på en saknad returväg, felaktig NAT-översättning, problem i målsystemet eller serverns lokala brandvägg. Kontrollera gränssnitt, översatta adresser och gateway och sök därefter efter båda riktningarna i Packet Capture. En räknare ensam bevisar inte orsaken.

Värdena ändras inte efter en konfigurationsändring

Vyn visar förmodligen fortfarande den befintliga sessionen. Avsluta klientanslutningen kontrollerat, skapa ett nytt flöde och kontrollera Start time och Connection ID igen. Använd inte en global sessionsrensning eller tjänsteomstart som normalt första test.

Sessionen eller motsvarande loggpost saknas i HA

Anteckna Connection served by och ta hänsyn till den nod som behandlade trafiken vid händelsetidpunkten. Loggar lagras lokalt på varje HA-nod och synkroniseras inte fullständigt mellan noderna. Dra ingen slutsats om oavbruten sessionsfortsättning från en synlig Connection List. Konfigurera Sophos Firewall HA förklarar begränsningarna.

Other applications är ovanligt stort

Gruppera först efter käll-IP och öppna de enskilda sessionerna. Oidentifierade applikationer, systemtrafik och flera olika orsaker kan samlas i denna grupp. Kontrollera Rule ID, destinationer, portar, användare och applikationskontext innan detta bedöms som en säkerhetsincident.

Checklista

• Källa, destination, protokoll, portar och testtid är kända.
• En ny anslutning skapades för testet.
• Live Connections grupperades på ett meningsfullt sätt efter käll-IP, användare eller applikation.
• Start time, In/Out interface, Rule ID och NAT ID motsvarar förväntningarna.
• Translated source/destination och Gateway ID stämmer med den planerade vägen.
• User och Policy IDs förväntades endast när motsvarande identifiering var aktiv.
• Rule ID 0 tolkades i rätt sammanhang för systemtrafik.
• Vid HA dokumenterades Connection served by.
• Log Viewer och vid behov Packet Capture bekräftar sessionen.
• Ingen global sessionsrensning eller tjänsteomstart användes som första diagnosförsök.

Vanliga frågor