Verouderde bridge-VLAN-tagging vóór SFOS 22 MR2 vervangen

Bridge-interfaces op Sophos Firewall zijn nuttig om een bestaand Layer 2-netwerk transparant te houden of een migratie uit te voeren zonder de IP-adressen direct te wijzigen. Zijn VLAN-tags eerder met system vlan-tag op een bridge ingesteld, vervang die configuratie dan vóór een upgrade naar SFOS 22.0 MR2 of later door VLAN-interfaces in WebAdmin. Dit is geen cosmetische wijziging: in GA en MR1 kan verkeer van of naar de firewall uitvallen en vanaf MR2 blokkeert de verouderde configuratie de upgrade.

Probleem NC-181672 treft bridge-interfaces met CLI-VLAN-tagconfiguraties in SFOS 22.0 GA en MR1: VLAN-getagd verkeer dat afkomstig is van de Sophos Firewall of op de firewall eindigt, wordt niet correct verwerkt. Dit kan bijvoorbeeld Active Directory, DNS, Device Access, STAS, LDAP, RADIUS of beheertoegang beïnvloeden, terwijl de bridge normaal verkeer wel blijft doorsturen.

Verouderde CLI-VLAN-tagging is achterhaald: de configuratie blokkeert een upgrade naar SFOS 22.0 MR2 of later en een back-up die haar bevat kan niet op SFOS 22.0 GA of later worden teruggezet. Voer deze controle daarom uit vóór de upgrade en vóór het maken van de daarvoor bestemde back-up. De SFOS 22-upgradecontrole documenteert de gecontroleerde doelrelease MR2 Build 546, het upgradepad en andere versiespecifieke blokkades. Is een andere doelbuild gepland, controleer dan vóór de wijziging afzonderlijk het upgradepad en de toepasselijke blokkades voor die build; neem de MR2-gegevens niet ongecontroleerd over.

Dit artikel is geen algemeen hoofdstuk over VLAN’s. Begin voor het plannen van zones, interfaces, VLAN’s, Bridges en LAG’s met Zones en interfaces op Sophos Firewall configureren. De normale configuratie, beveiliging en controle staan in Een Bridge-interface op Sophos Firewall configureren. Hier gaat het specifiek om het bijzondere geval van VLAN’s op Bridges na SFOS 22.

Wanneer dit onderwerp relevant is

De controle is zinvol als verschillende punten samenkomen:

• De firewall draait op SFOS 22.0 GA of SFOS 22.0 MR1.
• Er is een bridge-interface, bijvoorbeeld br0.
• VLAN’s werden historisch gebouwd met behulp van CLI VLAN tagconfiguratie zoals system vlan-tag of werden overgenomen van een oude configuratie.
• Firewallservices zelf moeten een getagd VLAN bereiken.
• Na een upgrade werken AD, DNS, authenticatie, monitoring of beheertoegang slechts gedeeltelijk.
• Een upgrade naar SFOS 22.0 MR2 of later is gepland of wordt geblokkeerd door legacy CLI VLAN tagging.
• Het normale clientverkeer via de brug lijkt nog steeds actief te zijn.

Het laatste punt is belangrijk: als de brug verkeer tussen netwerken blijft doorsturen, zal het probleem in eerste instantie niet lijken op een brugstoring. In de praktijk kijk je vaak op de verkeerde plek, zoals bij firewallregels, DNS, STAS of de domeincontroller.

Begrijp de getroffen verkeersrichting

Er zijn drie soorten verkeer te onderscheiden:

• Verkeer dat door de bridge gaat: Een client in VLAN 100 praat met een server in VLAN 100. Dit werkt mogelijk nog steeds, maar bewijst niet dat het verkeer naar de firewall werkt.
• Verkeer naar firewall: Een client gebruikt de firewall als DNS-server of WebAdmin-bestemming. Juist dit verkeer kan hinder ondervinden omdat het bij de firewall eindigt.
• Verkeer van de firewall: De firewall vraagt ​​AD, DNS, LDAP, RADIUS, NTP of Syslog bestemmingen op. Dit is ook van cruciaal belang omdat de firewall zelf de afzender is.

Als er slechts één applicatie tussen twee hosts wordt getest, kan de fout niet met zekerheid worden geïdentificeerd. De test moet opzettelijk een service bevatten die eindigt op de Sophos Firewall of wordt gemaakt door de firewall.

Typische symptomen

Mogelijke tekenen zijn:

• Op gebruikers gebaseerde regels werken niet langer betrouwbaar omdat AD, STAS of LDAP niet op een stabiele manier kunnen worden bereikt.
• DNS-query’s naar de firewall mislukken vanaf individuele VLAN’s.
• Ping of HTTPS op lokale firewallservices werkt niet vanaf een VLAN, ook al zien de firewallregels er plausibel uit.
• Monitoring of Syslog lijkt onvolledig als de firewall een doel moet bereiken in een getagd VLAN.
• Packet Capture laat zien dat verkeer tussen eindsystemen zichtbaar is, maar firewallservices zelf reageren niet zoals verwacht.
• Na een SFOS-22 upgrade treden de symptomen op zonder dat er bewust iets aan de switch- of firewallregels is gewijzigd.

Dergelijke symptomen mogen niet onmiddellijk worden aangepakt met brede Allow-regels of Device Access-vrijgaven. Ten eerste moet duidelijk zijn of het interfaceontwerp zelf wordt beïnvloed.

Snelle afbakening vóór conversie

Voordat u een bridge IP verplaatst of nieuwe VLAN interfaces op de bridge maakt, moet u de oorzaak achterhalen. Niet elk probleem na een upgrade is automatisch het geval van SFOS-22-Bridge-VLAN.

Praktische classificatie:

• Slechts één applicatie tussen twee hosts werkt niet: Waarschijnlijker zijn firewallregel, NAT, doelsysteem of retourpad. Test eerst de firewallregel en analyseer bij drops de verworpen pakketten.
• WebAdmin, DNS of ping naar de firewall vanaf een VLAN werkt niet: Controleer Device Access, de zone, de lokale service of het specifieke bridge-VLAN-probleem. Test vervolgens het verkeer naar de firewall afzonderlijk.
• Firewall bereikt AD, LDAP, RADIUS, DNS of Syslog niet in VLAN: Controleer verkeer van de firewall, routing, DNS of het specifieke bridge-VLAN-probleem. Gebruik tests rechtstreeks vanuit de firewallconfiguratie en de juiste servicelogboeken.
• Er is normaal clientverkeer actief, maar de services van de firewall zelf niet: Een speciaal geval van Bridge VLAN wordt waarschijnlijker. Controleer het bridge-ontwerp, de oude CLI VLAN-tagconfiguratie en VLAN-interface voor bridge.
• Er zijn helemaal geen overeenkomende loggegevens: Controleer logging, filters, de lokale service of een niet-gelogd bridge-/NAT-probleem. Combineer Log Viewer, Packet Capture en relevante Sophos Firewall servicelogboeken.

Voor DNS-problemen is het ook van belang of clients de firewall als resolver gebruiken of dat de firewall zelf DNS-verzoekroutes naar interne servers gebruikt. Het tweede geval betreft verkeer van de firewall en kan bij problemen met Bridge VLAN er anders uitzien dan normaal clientverkeer. De basisbeginselen vindt u in DNS-verzoekroutes instellen op Sophos Firewall.

Als de snelle afbakening duidelijk verwijst naar lokale firewalldiensten of verkeer gegenereerd door de firewall, moet de conversie toch worden gepland. Een brugcorrectie zonder back-up, onderhoudsvenster en alternatief toegangspad is te riskant voor productieve netwerken.

Bestaand ontwerp opnemen

Voordat u wijzigingen aanbrengt, moet u de huidige status documenteren. Bijzonder belangrijk zijn:

• Naam van de bridge-interface, bijvoorbeeld br0.
• Bridge-leden, d.w.z. deelnemende fysieke interfaces, VLAN’s, RED interfaces of LAG’s.
• IP adres van de bridge, indien beschikbaar.
• VLAN ID’s die over de brug gaan.
• Switchpoortprofiel: Tagged VLAN’s, Native VLAN, Trunk of Access Port.
• Services die eindigen op de firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Services die de firewall moet bereiken: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Als de structuur uit een oude migratie komt, moet u ook controleren of VLAN’s via CLI-configuratie zijn ingesteld. Juist deze erfenis wordt vaak niet meer in gedachten gehouden als de firewall in de loop der jaren alleen maar is bijgewerkt.

⚠️ Tijdens de dagelijkse werkzaamheden moet je niet spontaan experimenteren met bridge-interfaces en VLAN’s. Een onjuiste wijziging kan van invloed zijn op de beheertoegang, DNS, authenticatie of volledige clientnetwerken. Vóór de correctie zijn een back-up, een onderhoudsvenster en een alternatief toegangspad vereist.

Bridge-specifieke valkuilen vóór de correctie

Vóór de wijziging moeten drie bridge-beperkingen zorgvuldig worden gecontroleerd.

Ten eerste: een bridge zonder IP-adres kan verkeer laten vallen als het verkeer overeenkomt met een firewallregel met web proxy filtering of met een NAT-regel. Deze drops worden niet gelogd. Als een NAT-regel toch nodig is, moet die zo worden afgebakend dat source translation voor de bridge zonder IP-adres op Original blijft. Anders zoekt men in Log Viewer naar een drop die daar nooit verschijnt.

Ten tweede: VLAN filtering op de bridge geldt alleen voor gebridged verkeer, niet voor gerouted verkeer. Als Filter VLANs is ingeschakeld, maar er geen toegestane VLAN IDs zijn ingevoerd, wordt tagged verkeer van alle VLANs gedropt; untagged verkeer blijft uitgezonderd. Tijdens tests kan dit lijken op een inconsistent VLAN-probleem.

Ten derde: bridge-interfaces zijn geen vervanging voor elk ontwerp. Er gelden beperkingen voor Dynamic DNS, DHCP client, PPPoE en IPsec VPN. Als een van deze functies deel uitmaakt van het doelontwerp, moet de bridge-workaround niet geïsoleerd worden toegepast; het interfaceontwerp moet opnieuw worden beoordeeld.

Ondersteunde VLAN-interfaces maken

De ondersteunde workaround is VLAN-interfaces onder Network > Interfaces te maken met de bridge als parent. Fysieke, RED-, bridge- en LAG-interfaces zijn geldige parents.

Vóór SFOS 18.0 was system vlan-tag nodig om VLAN-getagde communicatie via bridge-interfaces mogelijk te maken. Sinds SFOS 18.0 is VLAN-over-bridge volledig beschikbaar in WebAdmin. Voor de inventarisatie en opschoning geldt echter een belangrijke beperking: de VLAN-tagdocumentatie voor SFOS 22 en 23 beschrijft een reset met interfaceargumenten tegelijkertijd als het weergeven van de configuratie. Daaruit kan niet worden afgeleid dat een op zichzelf staand system vlan-tag show een niet-wijzigende query is, noch dat system vlan-tag reset zonder argumenten een opschoningsopdracht met een bekend toepassingsbereik is. Ook de beschikbaarheid van een opdracht in een CLI-context bevestigt deze eigenschappen niet.

Vóór elke CLI-actie voor inventarisatie of opschoning moet aan de hand van eenduidige documentatie voor de geïnstalleerde build of door Sophos Support zijn bevestigd welke exacte methode de bestaande configuratie zonder configuratiewijziging inventariseert en welke opschoningssyntaxis geldt. Dit omvat de exacte CLI-context, vereiste rechten en argumenten, de betrokken interfaces of knooppunten, en de effecten en het toepassingsbereik van de opschoning. Zijn deze punten niet opgehelderd, documenteer dan alleen de in Network > Interfaces zichtbare WebAdmin-configuratie en stop vóór opschoning of upgrade. Ontbrekende WebAdmin-vermeldingen bewijzen niet dat er geen legacy-CLI-tags bestaan; bespreek de openstaande inventarisatievraag met Sophos Support in plaats van een vermeende weergave- of resetopdracht uit te proberen.

Nieuwe of opgeschoonde ontwerpen mogen niet meer op system vlan-tag steunen. Als zulke CLI-tags nog bestaan, moeten ze worden gedocumenteerd, naar VLAN-interfaces in WebAdmin worden gemigreerd en pas daarna mag de firmware-upgrade worden voortgezet. Dit vermindert zowel het SFOS 22 bridge-speciale geval als latere upgradeblokkades.

Voorbeelden:

• VLAN 100: br0.100
• VLAN 200: br0.200

Bij het aanmaken in WebAdmin zijn drie velden doorslaggevend: Interface moet de bridge zijn, Zone moet passen bij het beveiligingsdoel van het VLAN en VLAN ID moet uniek zijn. WebAdmin accepteert VLAN IDs van 1 tot 4094; dezelfde VLAN ID mag niet meerdere keren op dezelfde parent interface worden gepland.

Het proces is afhankelijk van het feit of de bridge zelf al een IP-adres heeft.

Als de bridge geen IP adres nodig heeft

Als de brug alleen transparant moet doorsturen, kan deze zonder eigen IP-adres worden gebruikt. Het IP-adres voor het betreffende VLAN bevindt zich dan op de VLAN-interface, bijvoorbeeld br0.100.

Praktisch proces:

1. Exporteer een back-up als documentatie, maar reken er niet op dat deze op SFOS 22 als terugval kan worden hersteld.
2. Documenteer de huidige brug en VLAN-configuratie.
3. Kies onder Network > Interfaces voor Add interface > Add VLAN.
4. Selecteer de bridge als bovenliggende interface, bijvoorbeeld br0.
5. Voer VLAN ID in.
6. Kies bewust je zone.
7. Stel het IP-adres in op de VLAN-interface als de firewall in dit VLAN als gateway of lokale service moet functioneren.
8. Controleer Device Access voor de zone.
9. Controleer de firewallregels en NAT-regels.
10. Valideer de wijziging met een testclient en maak pas na geslaagde tests een nieuwe back-up.

De zone dient niet alleen om WebAdmin overzichtelijk te houden. Deze beslissing is van invloed op de firewallregels, Device Access, logboeken en veel latere stappen voor probleemoplossing. Indien een VLAN bedoeld is als beheer-, server- of clientnetwerk, dient dit zichtbaar te zijn in de zone.

Als de bridge voorheen het productieve IP adres had

Als de bridge momenteel het IP-adres gebruikt dat straks via het VLAN bereikbaar moet zijn, moet u bijzonder voorzichtig zijn. Er zijn twee schone varianten voor de conversie: De bridge krijgt een ander IP adres, of de bridge blijft zonder IP adres. Het vorige productieve adres wordt vervolgens toegewezen aan de VLAN-interface.

Dit is een wijziging met risico op uitval. Het moet vooraf worden verduidelijkt:

• Welk adres wordt gebruikt om WebAdmin te bereiken?
• Welke clients gebruiken de firewall als standaardgateway?
• Welke DNS- of DHCP-instellingen verwijzen naar dit adres?
• Welke toegangsregels voor apparaten zijn van toepassing op de vorige zone?
• Is er een tweede beheertoegang vanaf een niet-getroffen netwerk?

Voor afgelegen locaties mag deze wijziging niet worden gepland zonder een lokaal herstelpad. Als WebAdmin en SSH precies over de betrokken bridge IP lopen, kan een fout de beheerderstoegang onderbreken.

Legacy-configuratie verwijderen en de upgrade voorbereiden

De volgorde is essentieel: maak na de hierboven beschreven verduidelijking eerst alle benodigde VLAN-interfaces in Network > Interfaces met de bridge als Parent Interface, verplaats zo nodig het bestaande IP-adres van de bridge naar de juiste VLAN-interface en controleer het nieuwe data- en beheerpad. Controleer in een HA-omgeving vooraf via de ondersteunde statusweergave of de peer en synchronisatie foutloos functioneren en maak een back-up van elk knooppunt, voor zover het platform en de supportprocedure daarin voorzien. Is de peer-/synchronisatiestatus onjuist of onduidelijk, stop dan vóór opschoning of upgrade en escaleer. Verzin geen HA- of synchronisatieopdracht.

Pas wanneer de toewijzing is gedocumenteerd, alternatieve toegang actief is en aan alle HA-voorwaarden is voldaan, mag de legacy-instelling worden verwijderd met de procedure die voor de geïnstalleerde build via documentatie of door Sophos Support is bevestigd. De bevestiging van de exacte syntaxis, de CLI-context, de effecten en het toepassingsbereik voor interfaces en knooppunten moet vóór de uitvoering beschikbaar zijn; dit artikel geeft geen onvoorwaardelijke toestemming om een resetopdracht uit te voeren. Ontbreekt de bevestiging, beperk u dan tot de WebAdmin-inventarisatie en stop vóór opschoning of upgrade.

Controleer vervolgens met de eerder als niet-wijzigend bevestigde inventarisatiemethode gericht of de legacy-instelling binnen het beoogde toepassingsbereik is verwijderd. Verkeerstests alleen bewijzen dat niet. Blijft een legacy-configuratie zichtbaar, mislukt de opschoning of is de bestaande configuratie niet eenduidig vast te stellen, stop dan de procedure: start nog geen upgrade en keur de nieuwe back-up niet goed als opgeschoond herstelpunt. Bewaar de beschikbare inventarisatiegegevens, eventuele opdrachtuitvoer, de upgrade-precheck en de actuele configuratie en escaleer naar Sophos Support; probeer geen ongedocumenteerde CLI-opdrachten uit.

Uit de tegenstrijdige resetbeschrijving kan evenmin een betrouwbare terugvalprocedure op opdrachtniveau worden afgeleid. Geslaagde inventarisatiecontroles en verkeerstests bevestigen de opschoning, niet de terugvalprocedure. Maak de legacy-instelling na de opschoning niet opnieuw aan met een gegokte opdracht. Moet de wijziging worden teruggedraaid, stop dan en betrek Sophos Support bij een door de leverancier goedgekeurd herstel op de oorspronkelijke ondersteunde firmware; draai WebAdmin-wijzigingen alleen terug binnen dat goedgekeurde plan.

Als de acceptatietests en de herhaalde inventarisatiecontrole slagen, maak dan een nieuwe back-up, herhaal de upgrade-precheck en upgrade pas daarna naar SFOS 22.0 MR2 of later. Voor een configuratie die in de toekomst kan worden hersteld, geldt dezelfde bevestigde opschoningsprocedure: verwijder de legacy-instelling op de bronfirewall, maak zo nodig een VLAN-interface met de bridge als Parent aan, controleer de configuratie en maak pas daarna een nieuwe back-up. Een oude back-up met system vlan-tag wordt hierdoor niet gerepareerd.

Device Access en firewallregels daarna controleren

Nadat u de VLAN-interface hebt gemaakt, is het niet voldoende om alleen het IP-adres te testen. Device Access en firewallregels moeten overeenkomen met het nieuwe interface- en zoneontwerp.

Om te controleren:

• Administration > Device access: Zijn Ping/Ping6, DNS, HTTPS, SSH, User Portal of VPN portal alleen toegestaan in de juiste zones?
• Rules and policies > Firewall rules: Zijn er regels voor de nieuwe zone?
• Rules and policies > NAT rules: wordt verkeer onverwacht vertaald?
• Network > DNS of DNS-aanvraagroutes: bereikt de firewall de juiste DNS- of AD-servers?
• Authentication > Servers: Zijn AD, LDAP of RADIUS toegankelijk na de wijziging? Voor lokale firewallservices is Device Access op Sophos Firewall veilig configureren het juiste diepgaande artikel. Een Sophos Firewall-regel testen met Log Viewer en Packet Capture helpt bij regelanalyse.

Validatie na correctie

Een schone test moet meer dan één ping bevatten.

Test vanuit het betrokken VLAN

Controleer vanaf een client in het betrokken VLAN:

1. Test de bereikbaarheid van de standaardgateway.
2. Test de firewall IP op de nieuwe VLAN interface via ping, indien toegestaan.
3. Test DNS tegen de firewall als de firewall als DNS-resolver fungeert.
4. Test WebAdmin of portal alleen vanuit toegestane beheernetwerken.
5. Controleer een typische applicatie- of serververbinding.
6. Controleer Log Viewer voor overeenkomende regel-ID en zone.

Test vanuit de firewall

Voor verkeer dat de firewall zelf genereert zijn aparte tests nodig:

• Test AD- of LDAP-servers in Authentication > Servers.
• Controleer de DNS-resolutie via de firewall.
• Controleer NTP, Syslog of monitoringdoel als deze services zich in VLAN bevinden.
• Controleer onder Diagnostics > Packet capture de VLAN-interface. Generated markeert pakketten die de firewall maakt en Consumed pakketten die voor de firewall bestemd zijn; vergelijk ook In interface, Out interface, Rule ID, Status en Reason.

Als STAS of gebruikersgebaseerde regels worden beïnvloed, moet ook STAS op Sophos Firewall instellen worden gecontroleerd. Voor SFOS-22 upgrades hoort dit punt ook thuis in de SFOS 22 Upgrade Check.

Terugval en afronding

Noteer vóór de wijziging het bestaande IP-adres van de bridge, de zone, VLAN IDs, de switchpoortconfiguratie en de afhankelijke regels en services. Daarnaast zijn alternatieve of lokale beheertoegang en een door de leverancier goedgekeurd herstelplan nodig. Zolang de bevestigde CLI-opschoning nog niet is uitgevoerd, kunnen geplande WebAdmin-wijzigingen in de gedocumenteerde volgorde worden teruggedraaid: verwijder een verplaatst IP-adres eerst van de nieuwe VLAN-interface en wijs het pas daarna weer toe aan de bridge; herstel vervolgens de zone, regels, Device Access en het switchpoortprofiel en controleer de bereikbaarheid van het beheer en de gateway. Hiermee wordt een CLI-opschoning niet ongedaan gemaakt.

De tegenstrijdige resetbeschrijving bewijst niet dat er een omkering op opdrachtniveau mogelijk is. Mislukt de acceptatie na de bevestigde opschoning, stop dan en maak de legacy-instelling niet opnieuw aan. Escaleer voor een door de leverancier goedgekeurd herstel op de oorspronkelijke ondersteunde firmware. Schoon bij HA geen knooppunten op en upgrade ze niet zolang de peer- of synchronisatiestatus onjuist of onduidelijk is; bewaar de vereiste back-up van elk knooppunt. Zonder de vooraf vereiste bevestiging van de inventarisatiemethode, opschoningssyntaxis, context, effecten en het toepassingsbereik blijft het bij de WebAdmin-inventarisatie en moet vóór opschoning of upgrade worden gestopt.

Na geslaagde acceptatie wordt een nieuwe back-up gemaakt. De oude back-up met Legacy CLI VLAN tagging is geen terugvaloptie voor SFOS 22.0 GA of later. Blijft de verouderde configuratie ondanks de WebAdmin-migratie aanwezig of meldt de upgrade-precheck deze nog steeds, experimenteer dan niet met verdere CLI-wijzigingen, maar bewaar de configuratie en de melding en betrek Sophos Support.

Veelvoorkomende fouten

Typische valkuilen:

• Test alleen client-naar-server-verkeer: De bridge lijkt in orde, hoewel lokale firewallservices worden beïnvloed. Test ook het verkeer van en naar de firewall.
• Bridge-IP zonder plan verplaatsen: WebAdmin, DNS of de gateway kan uitvallen. Bereid een back-up, onderhoudsvenster en alternatieve toegang voor.
• Selecteer de zone verkeerd voor de nieuwe VLAN interface: Regels, Device Access en logs passen niet. Kies een zone op basis van veiligheidsdoeleinden, niet op basis van gewoonte.
• Device Access te wijd open: Het probleem lijkt opgelost, maar de beheerservices zijn onnodig toegankelijk. Plan de Local Service ACL gericht.
• Controleer de switchpoort niet: Het VLAN komt onjuist of ongetagd aan. Valideer Tagged/Untagged, Native VLAN en Trunk profiel.
• Negeer oude CLI-configuratie: Fout blijft onverklaard na upgrade. Documenteer het oude ontwerp en migreer naar WebAdmin-VLAN interfaces.

Controlelijst

• SFOS versie en relevantie van bekend probleem gecontroleerd.
• Bridge-interface, bridge-leden en VLAN ID’s gedocumenteerd.
• Verduidelijkt of de oude CLI VLAN-tagconfiguratie werd gebruikt.
• Bridge-specifieke NAT/web proxy drops en VLAN filtering gecontroleerd.
• Geplande upgrade naar SFOS 22.0 MR2 of later gecontroleerd op legacy CLI VLAN tags.
• Getroffen services van en naar de firewall geïdentificeerd.
• Back-up van elk toepasselijk knooppunt en alternatieve beheertoegang beschikbaar; HA-peer en synchronisatie gezond.
• VLAN interface gepland met bridge als bovenliggende interface.
• Zone, Device Access, firewallregels en NAT-regels gecontroleerd.
• Tests uitgevoerd vanuit het VLAN en vanaf de firewall.
• Niet-wijzigende inventarisatiemethode en exacte opschoningssyntaxis, CLI-context, effecten en toepassingsbereik vóór elke CLI-actie voor de geïnstalleerde build via documentatie of door Sophos Support bevestigd; anders alleen WebAdmin-inventarisatie en stoppen vóór opschoning of upgrade.
• Herstelgrens gedocumenteerd: geen terugvalprocedure op opdrachtniveau af te leiden uit de tegenstrijdige resetbeschrijving; na bevestigde opschoning en geslaagde acceptatie een nieuwe back-up gemaakt.
• Resultaat vastgelegd in het wijzigingslogboek of in de netwerkdocumentatie.

Veelgestelde vragen