Sophos Firewall-logboeken opslaan voor support en analyse

Bij verstoringen, VPN-problemen of onduidelijke firewallgebeurtenissen zijn individuele screenshots van de webinterface vaak niet voldoende. Voor een goed onderbouwde analyse heeft een supportaanvraag begrijpelijke tijdsinformatie, passende logbestanden en soms ook een pakketregistratie nodig.

De officiële download- en diagnoseprocedure geldt voor SFOS 22 en SFOS 23. De aanvullende handmatige archieven blijven een aparte analysemethode, geen bevestigde standaardexport voor beide versies. Deze handleiding beschrijft de officiële route via Diagnostics > Tools en onderscheidt die van de aanvullende route voor ruwe logs via Advanced Shell. Voor Sophos Support is het Consolidated Troubleshooting Report (CTR) doorgaans het beste vertrekpunt, omdat het logbestanden en een momentopname van het systeem bundelt in een versleuteld archief. Een handmatig aangemaakt /log-archief blijft nuttig voor volledige ruwe logs, aanvullende IPsec-gegevens of interne analyse. Het is echter geen versleuteld CTR en ook niet de door Sophos gedocumenteerde standaardexport.

Deze procedure vervangt de eerste probleemanalyse in Log Viewer niet. Als het nog steeds onduidelijk is om welke module het gaat, kan het overzicht Sophos Firewall Probleemoplossing: Services en Logboeken eerst helpen.

Baken eerst de supportcase af

Een groot archief is niet automatisch een goed supportpakket. Bepaal eerst welke test mislukte, wanneer deze werd uitgevoerd en welk onderdeel waarschijnlijk betrokken is.

Eerst analyseren of meteen gegevens verzamelen?

Afhankelijk van het foutpatroon is een andere aanpak sneller:

• Controleer specifieke verbindingspoging: Test firewallregel met Log Viewer, Policy Test en Packet Capture, als regel, NAT-regel of route onduidelijk zijn.
• Lokale logbestanden toewijzen: Sophos Firewall Problemen oplossen: Services en logs, als eerst moet worden verduidelijkt welk log bij VPN, web, IPS, GUI of systeemdiensten hoort.
• Het probleem is bekend en de gegevens moeten worden overgedragen: Volg dit artikel om een CTR, gerichte logs of een onbewerkt logarchief te maken.

Gebruik Central Firewall Reporting voor historische rapporten of terugkerende gebeurtenissen. Langdurige bewaring en correlatie vereisen Syslog of SIEM. Een tijdelijk supportarchief vervangt geen van beide.

Kies het gegevenspakket op basis van het probleem

Niet elk probleem heeft onmiddellijk een compleet logarchief nodig. Hoe duidelijker de fout wordt geïsoleerd, hoe kleiner en bruikbaarder de gegevens worden.

• Firewallregel of NAT-regel wordt onverwacht van kracht: Tijd, bron-IP, bestemmings-IP, regel-ID, NAT ID, Log Viewer-export en, indien nodig, Packet Capture.
• Service start niet of WebAdmin geeft een fout weer: Geconsolideerd probleemoplossingsrapport, getroffen service, tijd en laatste configuratiestap.
• IPsec-tunnel komt niet tot stand of mislukt: normaal logarchief, diagnostische IPsec-gegevens, peer-IP, lokale en externe netwerken, tijdstip van verbindingspoging.
• Verkeer bereikt de bestemming niet: Log Viewer, Packet Capture of voor langere analyses tcpdump-PCAP.
• Probleem na configuratiewijziging: Audittrail, geschatte wijzigingstijd, betrokken beheerder, betrokken objecten en CTR indien nodig.

Voor veel tickets is de combinatie van het tijdstip van het probleem, een korte foutbeschrijving, logarchief en gericht aanvullend bewijsmateriaal beter dan een zeer breed datapakket zonder context. Als er een officieel Sophos-ticket wordt aangemaakt, is Open een Sophos-supportticket: voorbereiding en portal ook van toepassing.

Vereisten

Voor deze handleiding heb je nodig:

• Administratieve toegang tot de Sophos Firewall
• Toegang tot Diagnostics > Tools in WebAdmin
• Voor onbewerkte logarchieven extra toegang tot de Advanced Shell
• Een doelserver, ondersteuningsportal of een andere veilige manier om archieven over te dragen
• Voldoende vrije ruimte op de firewall voor tijdelijke archieven

De CLI-opdrachten worden rechtstreeks op de firewall uitgevoerd. Ga daarom zorgvuldig te werk en verwijder geen bestanden als niet duidelijk is waarvoor ze worden gebruikt.

Als de toegang tot de shell nog niet is ingesteld, leggen de instructies Sophos Firewall verbinden via SSH uit hoe u een SSH-verbinding met de firewall tot stand brengt.

⚠️ Logarchieven en PCAP-bestanden kunnen gevoelige informatie bevatten. Dergelijke bestanden mogen slechts korte tijd op de firewall staan, veilig worden overgedragen en na een succesvolle overdracht weer worden verwijderd.

Verzamel logboeken

Afhankelijk van de supportaanvraag is een gerichte WebAdmin-download, een CTR of een onbewerkt logarchief van de Advanced Shell voldoende. Het proces moet beginnen met de kleinste dataset die de fout duidelijk verklaart.

De lokale bewaartijd van logs wordt beperkt door de opslagruimte per subsysteem en het firewallmodel. Wanneer een logbestand zijn maximale grootte bereikt, wordt het met gzip gecomprimeerd; wanneer het subsysteem zijn opslaglimiet bereikt, worden de oudste .gz-rotaties als eerste verwijderd. Als de firewall niet meer reageert, kunnen ook loggegevens verloren gaan die nog in het RAM staan en nog niet naar het bestandssysteem zijn geschreven. Verzamel relevante logs daarom zo snel mogelijk: een export bevat alleen gegevens die nog beschikbaar zijn en kan verloren vermeldingen niet terughalen.

Troubleshooting-logs worden opgeslagen op de partitie /var en gelezen via /log. Kritieke componenten krijgen meer ruimte; afhankelijk van het subsysteem worden twee of meer gecomprimeerde rotaties bewaard. Na rotatie schrijft de firewall verder onder de oorspronkelijke bestandsnaam. Op een XGS Appliance hangt de beschikbare geschiedenis dus ook af van model en service, niet van één vaste bewaartermijn.

Standaardmanier: CTR aanmaken in WebAdmin

Voor veel supportaanvragen maakt u eerst het Consolidated Troubleshooting Report. De CTR bevat een momentopname van het systeem en logbestanden in een versleuteld archief. Sophos Support kan dit archief rechtstreeks in de supportcase analyseren.

Zo creëert u de CTR:

1. Reproduceer indien mogelijk de fout en noteer het exacte tijdstip.
2. Open in WebAdmin Diagnostics > Tools.
3. Selecteer de vereiste opties onder Consolidated troubleshooting report.
4. Activeer voor een brede supportaanvraag System snapshot en All log files.
5. Voer een korte reden in, bijvoorbeeld ticketnummer, foutpatroon en tijdvenster.
6. Selecteer Generate.
7. Selecteer na het maken Download.
8. Stel het bestand beschikbaar via het supportportaal, de afgesproken beveiligde upload of het interne analysekanaal.

System snapshot vereist geen debugmodus en legt de huidige systeemstatus vast, waaronder actieve processen en resourcegebruik. De gedocumenteerde bestandsnaam is CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY is het serienummer van de firewall; de overige velden geven de aanmaakdatum als maand/dag/jaar en de tijd als uur/minuut/seconde. Ook de bestandsnaam is dus vertrouwelijk. Dit is handig wanneer meerdere firewalls of meerdere pogingen in één ticket terechtkomen.

De regellimiet geldt alleen voor Service subsystem logs; Default subsystem logs worden volledig opgenomen, voor zover de gegevens nog beschikbaar zijn. Controleer een versleutelde CTR niet met de verderop getoonde opdracht tar -tzf: controleer downloadvoltooiing, een plausibele bestandsgrootte, apparaat en testtijdstip, en voeg het bestand beveiligd toe aan de supportcase. Als genereren of downloaden mislukt, leg dan de fout vast en verzamel eerst de betrokken afzonderlijke logs in plaats van logs te verwijderen.

⚠️ De CTR is geen volledige dump van onbewerkte gegevens. Logboeken van servicesubsystemen bevatten standaard maximaal 10.000 regels; deze limiet geldt alleen voor de CTR. Download de betrokken Troubleshooting Logs afzonderlijk of sla de bestanden via de Advanced Shell op als oudere of volledige logs nodig zijn.

De CTR-regellimiet controleren in Device Console

De regellimiet voor logs van servicesubsystemen in de CTR kan onafhankelijk van de ruwe logs worden bekeken en ingesteld. Open in het hoofdmenu van de CLI 4. Device Console. SFOS 22 en SFOS 23 staan 250 tot 10000 regels toe en gebruiken standaard 10000:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Normaal hoeft de standaardwaarde niet te worden gewijzigd. 5000 toont alleen de syntaxis voor een bewust kleinere CTR: het bereik staat vast, maar de gekozen waarde hangt af van de supportaanvraag. Noteer vóór een wijziging de huidige waarde met show; herstel die na het genereren van de CTR met dezelfde instelopdracht. De instelling geldt alleen voor toekomstige CTR-bestanden, niet voor de volledige ruwe logs, en haalt geen verwijderde of overschreven gegevens terug.

Download individuele probleemoplossingslogboeken

Als de module al bekend is, is een gerichte log-export vaak beter dan een zeer brede dataset.

1. Diagnostics > Tools openen.
2. Selecteer de relevante logbestanden onder Troubleshooting logs.
3. Selecteer Download.
4. Geef het gegenereerde gecomprimeerde bestand door, samen met het tijdstip van de fout, de testcase en de getroffen firewall.

Dit pad is geschikt als bijvoorbeeld alleen strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log of een andere duidelijk betrokken dienst nodig is. In tegenstelling tot de CTR geldt de regellimiet niet voor deze afzonderlijke downloads. Welk bestand bij welke module hoort, staat in Sophos Firewall Probleemoplossing: Services en Logboeken.

Open Advanced Shell

Log in op Sophos Firewall en open de Advanced Shell:

1. Selecteer 5. Device Management in het hoofdmenu van de CLI.
2. Open daarna 3. Advanced Shell.
3. Bevestig de toegang als de firewall een extra vraag weergeeft.

Na het inloggen bevindt u zich in de firewallshell. Van daaruit kunnen de logbestanden worden gearchiveerd.

Een kort live-logfragment opslaan

Volg in de Advanced Shell nieuwe vermeldingen tijdens een afgebakende test:

cd /log
tail -f /log/charon.log

charon.log is een concreet IPsec-voorbeeld; kies bij andere problemen het passende bestaande bestand uit het overzicht van servicelogs. Noteer begin, einde en tijdzone van de test, reproduceer de fout en kopieer de uitvoer naar een beveiligd tekstbestand op de beheercomputer. Ctrl+C stopt de weergave, niet de firewallservice. tail -f toont de laatste bestaande regels en nieuwe vermeldingen, geen volledige export. Ontbreken vermeldingen, controleer dan eerst knooppunt, bestandsnaam, tijd en service; download zo nodig het volledige afzonderlijke bestand. Upload het fragment met de context naar de supportcase.

Verzamel specifieke logboeken voordat u een back-up maakt

Als een probleem reproduceerbaar is, reproduceer het dan zo mogelijk nogmaals vlak voordat u de logs archiveert. Dit betekent dat de betreffende vermeldingen zo recent mogelijk in de logbestanden terechtkomen.

Voor complexere problemen zijn de normale logs soms niet voldoende. In dit geval kan het zinvol zijn om vóór archivering een foutopsporingslogboek voor de betreffende service te activeren. Debuggen mag alleen specifiek en kortstondig worden uitgevoerd en na het verzamelen weer worden gedeactiveerd, omdat de logbestanden anders snel kunnen groeien. Hoe dit werkt wordt beschreven in de sectie Debug log specifiek activeren.

Welk logbestand bij welke firewallmodule hoort, wordt samengevat in Sophos Firewall Problemen oplossen: Services en logboeken. Dit overzicht is handig als u specifiek wilt controleren of VPN-, IPS-, web-, mail-, GUI- of systeemlogboeken relevanter zijn voor een probleem.

Als het geen serviceprobleem is, maar de pakketstroom zelf onduidelijk is, is een logarchief alleen vaak niet voldoende. Voor korte tests is Packet Capture in WebAdmin geschikt. Voor PCAP-bestanden, langere opnames of supportanalyses is tcpdump op de Sophos Firewall het juiste hulpmiddel.

Debug verzamelen met een gecontroleerde terugweg

Debug staat standaard uit. Stem vóór een wijziging toch met beheerders en support af of er al een verzameling loopt; leg knooppunt, vrije ruimte en een kort testvenster vast. Werk aan één ondersteund subsysteem tegelijk. Debuggegevens zijn beschikbaar via afzonderlijke downloads, CTR en CLI. Voer voor het gedocumenteerde servicevoorbeeld in 4. Device Console uit:

Voor andere ondersteunde services is de syntaxis system diagnostics subsystems <subsystem> debug on en system diagnostics subsystems <subsystem> debug off. Vervang <subsystem> door een CLI-naam die op de gebruikte build is bevestigd, niet door een logbestandsnaam. Als er al debuggegevens voor een andere supportcase worden verzameld, wijzig die status dan niet zonder afstemming.

system diagnostics subsystems Pktcapd debug on

Voer alleen de geplande test uit, download het log of de voltooide CTR en schakel debug daarna uit in dezelfde Device Console:

system diagnostics subsystems Pktcapd debug off

Leg de on/off-uitvoer en tijdstippen vast; controleer met een korte vervolgtest of er geen nieuwe debugvermeldingen ontstaan en loggroei en opslaggebruik weer normaal zijn. Wordt de opdracht geweigerd, gok dan niet naar namen: controleer de buildsyntaxis en neem contact op met support. Uitschakelen verwijdert geen verzamelde bestanden.

Voor de systeemcontroller noemt de loghandleiding dezelfde opdracht, system diagnostics subsystems CSC debug, voor in- en uitschakelen, zonder on of off. Gebruik deze schakelopdracht niet als statusvraag en voer haar niet blind tweemaal uit. Als de beginstatus of terugweg onduidelijk is, wijzig CSC-debug dan niet; volg de gecontroleerde CSC-procedure met support. Logbestandsnamen zijn geen CLI-subsysteemnamen.

Het SFOS 22/23-diagnoseoverzicht noemt de volgende Default logs voor debug; deze groep is ook uitgezonderd van de CTR-regellimiet:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

De genoemde Service logs zijn:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

Deze lijst beschrijft bestanden die debug ondersteunen, niet alle logs of gegarandeerde aanwezigheid op ieder platform. Controleer NPU- en XGS-bestanden in de context van de betreffende XGS Appliance. Behoud hoofdletters en kleine letters: pktcapd.log is niet de opdrachtparameter Pktcapd.

Bewijsmateriaal veiligstellen voordat logs worden gewist

Een purge is niet nodig voor CTR of afzonderlijke downloads. De diagnosehandleiding noemt het leegmaken van een subsysteem vóór het reproduceren alleen als optioneel. Stel eerst bewijs-, support- en bewaareisen vast en sla benodigde bestanden buiten de firewall op. Anders dan het later verwijderen van eigen archieven wist een purge diagnostische geschiedenis; er is geen terugweg.

De globale Device Console-opdrachten zijn system diagnostics purge-old-logs voor alle gecomprimeerde .gz-logs en system diagnostics purge-all-logs voor alle loginhoud. Volgens de CLI-help blijven na een volledige purge lege bestanden achter. Globale acties raken ook andere subsystemen en lopende supportcases.

Syntaxisconflict voor één subsysteem: De SFOS 22/23-beheerdershelp noemt system diagnostics <subsystem> purge-log en system diagnostics <subsystem> purge-old-log; de CLI-help documenteert daarentegen system diagnostics subsystems <subsystem> purge-log en system diagnostics subsystems <subsystem> purge-old-log. Controleer vóór een goedgekeurde purge in 4. Device Console de volledige syntaxis en namen met CLI-help of Tab-aanvulling en bespreek het conflict met support. Probeer niet beide varianten uit.

Stop bij onduidelijke syntaxis, bestandsherkomst of lopende gegevensverzameling en gebruik de procedure voor opslaganalyse en gecontroleerde opschoning. Controleer na een afgesproken actie vrije ruimte, nieuwe normale logvermeldingen en servicestatus; minder opslaggebruik bewijst niet dat de oorzaak is opgelost. Verwijder systeemlogs niet handmatig met rm of wildcards.

Ruwe logs archiveren via de Advanced Shell

Als de CTR niet volstaat of alle momenteel beschikbare ruwe logs nodig zijn voor interne analyse, kunt u de map /log handmatig archiveren. Deze shellmethode vervangt de officiële CTR of de afzonderlijke download onder Troubleshooting logs niet. Controleer vóór het archiveren of er voldoende vrije ruimte is onder /var:

Controleer vóór deze aanvullende shellmethode de aanwezige mappen en vrije ruimte. Als /log een symbolische koppeling is, kan de onderstaande tar-opdracht alleen de koppeling archiveren in plaats van de logbestanden: ga niet verder met een schijnbaar voltooid archief; gebruik de officiële afzonderlijke download of stem de archiefmethode af met support. Een map waarin nog wordt geschreven is evenmin een consistente back-up. Los ontbrekende paden, leesfouten of opslagproblemen eerst op; verwijder geen systeemlogs om ruimte vrij te maken.

ls -ld /log
df -h /var

Maak vervolgens een gecomprimeerd archief met de bestanden uit de map /log:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

Met de opdracht wordt het bestand gemaakt:

/var/Sophos-Firewall-Logs.tar.gz

De belangrijkste onderdelen van de opdracht:

• tar creëert een archief.
• -c maakt een nieuw archief aan.
• -v geeft de verwerkte bestanden weer.
• -z comprimeert het archief met gzip.
• -f specificeert de bestandsnaam van het archief.
• -C / schakelt naar de hoofdmap voor de archiefbewerking.
• log is de directory met de logbestanden van Sophos Firewall.

Het voordeel van -C / is dat de opdracht ongeacht de huidige werkmap werkt. Een voorafgaande cd / is dus niet nodig. Als het bestand al bestaat, zal de opdracht het overschrijven.

Afhankelijk van de grootte en belasting van de firewall kan het archiveringsproces enige tijd duren. Ondertussen laat de uitvoer van tar zien welke bestanden naar het archief worden geschreven.

De archiefgrootte kan vervolgens worden gecontroleerd:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Daarnaast moet u kort controleren of het archief leesbaar is en daadwerkelijk de logdirectory bevat:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

De uitvoer moet paden onder log/ tonen. Als de opdracht een fout meldt of als het archief ongewoon klein is, mag het archief niet worden gedistribueerd. Controleer eerst de vrije opslagruimte, schrijfrechten en het resultaat van de eerdere tar-opdracht.

Kopieer logarchief naar een Linux-server

Als een Linux-server via SSH bereikbaar is, kan het archief met scp worden overgedragen.

Voorbeeld:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

Het IP-adres, de gebruiker en het doelpad moeten worden aangepast aan uw eigen omgeving.

Na de overdracht bevindt het archief zich op de doelserver op:

/root/Sophos-Firewall-Logs.tar.gz

Van daaruit kan het intern worden doorgegeven of beschikbaar worden gesteld aan Sophos Support of Avanet.

IPsec Diagnostische gegevens afzonderlijk opslaan

Bij VPN- of IPsec-problemen kunnen ook de verbindingsgegevens uit /tmp/ipsec/connections/ nuttig zijn. De onderzochte SFOS 22/23-handleidingen beschrijven deze handmatige archiefmethode niet als standaardexport. Gebruik haar alleen voor interne analyse of op uitdrukkelijk verzoek van support en controleer eerst of de map bestaat.

Maak hiervoor een apart archief aan:

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Ook hier kan het gegenereerde bestand kort worden gecontroleerd:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Dit archief kan ook naar een doelserver worden gekopieerd met scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Vooral bij IPsec-fouten is het zinvol om dit archief samen met de normale firewall-logs ter beschikking te stellen, zodat de tunnelstatus, verbindingsinformatie en loggegevens samen kunnen worden geëvalueerd.

Wat een supportarchief niet vervangt

Een CTR en een /log-archief zijn momentopnamen van de lokale firewall. Ze helpen bij service- en systeemfouten, maar bieden niet automatisch een lange geschiedenis en bewijzen niet dat een specifiek pakket de firewall passeerde. Gebruik Central Firewall Reporting of Syslog en SIEM voor geschiedenis en zoeken. Configuratiewijzigingen zijn gerichter te volgen via Audit Trail Logs.

Behandel pakketopnamen afzonderlijk

Logarchieven en pakketopnamen zijn verschillende vormen van bewijs. Het logarchief toont serviceberichten, fouten, VPN-statussen en systeemgebeurtenissen. Een Packet Capture of tcpdump laat daarentegen zien of pakketten daadwerkelijk aankomen, worden doorgestuurd of dat er antwoorden ontbreken.

Voor ondersteuningsgevallen mag u pakketopnamen niet ongefilterd verzenden. Het is beter:

1. Noteer de testcase met bron-IP, bestemmings-IP, poort, protocol en tijd.
2. Controleer eerst Log Viewer en WebAdmin Packet Capture of dat voldoende is.
3. Maak alleen indien nodig een nauw gefilterde tcpdump-opname als PCAP.
4. Breng het PCAP-bestand veilig over.
5. Verwijder het PCAP-bestand uit de firewall na een succesvolle overdracht.

Het PCAP-bestand hoort niet thuis in het /log-archief, maar wordt afzonderlijk aangemaakt en overgedragen. Hierdoor blijft duidelijk welk bestand servicelogboeken bevat en welk bestand netwerkpakketten bevat.

Beveiliging, privacy en opruimen

Logbestanden kunnen gevoelige informatie bevatten, bijvoorbeeld:

• Openbare en interne IP-adressen
• Gebruikersnamen
• Hostnamen
• VPN informatie
• Foutmeldingen met technische details
• Verwijzingen naar interne netwerkstructuren

Logarchieven mogen daarom alleen via beveiligde kanalen worden overgedragen en alleen beschikbaar worden gesteld aan mensen of organisaties die bij de analyse betrokken zijn. Als logbestanden naar een externe partner worden verzonden, moet vooraf intern worden verduidelijkt of de overdracht is toegestaan ​​in overeenstemming met uw eigen richtlijnen voor gegevensbescherming en beveiliging.

Bij HA-clusters worden logs en rapporten niet automatisch gesynchroniseerd tussen de Primary- en Auxiliary-appliance. Elke appliance bevat de logs en rapporten van het verkeer dat ze verwerkt. Noteer bij HA-problemen of failoverperioden van welk knooppunt het archief afkomstig is en of ook logs van het tweede knooppunt nodig zijn.

Tijdelijke archieven verwijderen

Controleer het archief na de overdracht op het doelsysteem en verwijder het daarna van de firewall om de tijdelijke ruimte vrij te maken. De volgende opdrachten verwijderen alleen de vaste archiefnamen die in deze handleiding zijn aangemaakt:

rm /var/Sophos-Firewall-Logs.tar.gz

Als er ook een apart IPsec-archief is aangemaakt, moet dit ook worden verwijderd:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Voordat u de bestanden verwijdert, moet u controleren of de bestanden met succes op het doelsysteem zijn aangekomen.

Checklist voor ondersteuningsgevallen

• Probleem kort beschreven: Wat werkt niet, sinds wanneer, hoe vaak?
• Exacte tijd genoteerd met tijdzone.
• Betrokken bron-IP, bestemmings-IP, gebruiker, service of tunnelnaam genoteerd.
• Relevante module gecontroleerd in Log Viewer.
• Indien nodig: Debug slechts kort geactiveerd en weer gedeactiveerd.
• CTR aangemaakt op Diagnostics > Tools wanneer Sophos-ondersteuning of een systeemmomentopname vereist is.
• Indien nodig worden individuele probleemoplossingslogboeken of volledige /log-archieven aangemaakt.
• In het geval van IPsec-problemen wordt er een back-up gemaakt van aanvullende IPsec-diagnosegegevens.
• Voor pakketstroomproblemen wordt Packet Capture of tcpdump afzonderlijk aangemaakt.
• Alleen handmatige gzip-archieven met tar -tzf gecontroleerd op echte logbestanden; bij de versleutelde CTR download, apparaat en tijd gecontroleerd.
• Bij HA gecontroleerd van welk knooppunt de logs afkomstig zijn.
• Archief en PCAP alleen overgedragen via beveiligde kanalen.
• Tijdelijke bestanden op de firewall verwijderd na succesvolle overdracht.

Veelgestelde vragen