Distribuera och routa Sophos Firewall på Azure

Sophos Firewall kan distribueras från Azure Marketplace som en appliance eller via en Load Balancer-mall med två brandväggar. Sophos kallar det andra upplägget active-active, men det är inte ett inbyggt SFOS-HA-kluster. Konfiguration, sessioner och status synkroniseras inte som mellan två HA-appliances.

⚠️ Azure-routing är en del av brandväggskonfigurationen. En korrekt SFOS-regel räcker inte om en User Defined Route, Network Security Group eller returvägen via Load Balancer saknas. Validera varje publicering som komplett fram- och returväg.

Välj driftmodell och licens

Azure-infrastruktur och Sophos-programvara har separata kostnader. PAYG debiteras per timme utan minimiåtagande i den dokumenterade modellen och inkluderar Xstream; separata abonnemang och Enhanced Plus Support kan inte läggas till. Kontrollera faktureringsland mot Microsofts remitteringsländer och det faktiska erbjudandet; välj BYOL om PAYG saknas. BYOL via auktoriserad återförsäljare ger val av paket, separata abonnemang (Network Protection, Web Protection, Zero-Day Protection) och support inklusive Enhanced Plus Support. Dokumenterade löptider är ett, två eller tre år: bekräfta erbjudande och rättigheter utan pris- eller supportlöften. Stoppad programvara tar inte bort debiterbara Azure-resurser.

Sophos anger Standard_F2s_v2 med två vCPU, 4 GB RAM och minst två NIC:ar som minsta storlek. Dimensionera dessutom efter genomströmning, aktiverade skyddsfunktioner och Azure-kvoter. Publikt IP använder Standard SKU med statisk tilldelning. Basic SKU är avvecklad och ska inte användas i nya distributioner.

Distribuera standalone från Marketplace

Skapa och säkra appliance-enheten

1. Välj Sophos Firewall i Azure Marketplace och välj BYOL eller PAYG.
2. Ange Subscription, Resource Group, region, VM-namn, ett starkt initialt admin-lösenord och den kontrollerade VM-storleken. VNet, subnet och fjärrnät får inte överlappa; ange även den förberedda publika IP-adressen och ett Storage Account.
3. Koppla PortA till LAN och PortB till WAN. Öppna NSG initialt endast för nödvändiga adminkällor.
4. Slutför distributionen och öppna WebAdmin på https://<dns-name>:4444.
5. Slutför setup, registrering, licens och firmware kontrollerat.
6. Följ underhållsproceduren nedan och stoppa VM:n innan LAN-NIC:ens privata adress sätts till Static. Lägg till UDR 0.0.0.0/0, Virtual appliance, med denna LAN-adress som Next Hop på varje workload-subnet.
7. Testa IP Forwarding, NSG, SFOS-regler och returväg med en definierad klient.

Default-UDR:n leder internettrafik från det kopplade workload-subnätet genom brandväggen. Mer specifika Azure-rutter har fortfarande företräde. Utan denna UDR använder Azure standardvägen. En route-based anslutning till Azure VPN Gateway använder dessutom XFRM-gränssnittet med statiska routes, SD-WAN eller BGP.

Förbered adressplanen

För en ny distribution skapar du först en publik IP under Public IP addresses > Create med IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static och Routing preference: Microsoft network. Ange ett unikt DNS name label och välj Domain name label scope: None. Sophos anger även DDoS protection > Protection type: Network för den här proceduren. Alternativet kräver en lämplig Azure DDoS-plan och kan medföra extra kostnader; stäm därför av planen med Azure-ansvarig innan adressen skapas. Välj sedan adressen i Public IP name. Availability zone: 1 är valet i det dokumenterade exemplet. Begränsningen till en tillgänglighetszon är separat; den bevisar inte exklusivt stöd för zon 1 och validerar inte andra zoner eller flerzonsdesign. Det tidigare dynamiska Basic-alternativet är inte längre aktuellt efter att Azure avvecklat SKU:n.

Ett anpassningsbart exempel använder VNet 10.20.0.0/16, LAN 10.20.10.0/24 på PortA, WAN 10.20.20.0/24 på PortB och statisk LAN-IP 10.20.10.4. Ersätt dessa RFC 1918-värden med lediga intervall utan överlappning mot peering, VPN eller lokala nät.

Skapa LAN-UDR med exakta Azure-fält

Sophos kräver att VM:n stoppas innan LAN-IP:n görs statisk: Virtual machines > > Stop, därefter LAN-NIC, Settings > IP configurations > ipconfig, Allocation: Static. Behåll den nuvarande LAN-adressen eller ange den reserverade adressen och spara innan VM:n startas igen. Skapa sedan tabellen under Route tables > Create med rätt Subscription, samma Resource Group och region samt till exempel namnet rt-workloads-via-sfos. Koppla under Subnets > Associate varje klient- eller workload-subnet vars trafik ska gå genom appliance-enheten. Om klienterna ligger direkt i PortA:s LAN-subnet kopplar du detta LAN-subnet, som i Sophos grundexempel. Koppla inte brandväggens WAN-subnet. Under Routes > Add anger du Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance och Next hop address: 10.20.10.4. Kontrollera Enable IP forwarding på båda NIC:arna. Behåll endast Propagate gateway routes: Yes om det passar VPN-/ExpressRoute-designen. Skapa till sist en begränsad, loggad LAN-till-WAN-regel under Rules and policies > Firewall rules.

Driv active-active med Load Balancer

Sophos-mallen skapar två brandväggar och en extern och intern Standard Load Balancer med HA Ports. Den kräver ett /16 VNet och /24 LAN- och WAN-subnet; Sophos kräver kontakt med Sophos-representanten innan andra subnetstorlekar används.

Health probes når WebAdmin på 4444 och proxyn på 3128. Interna probes är också beroende av särskilda routes till plattformsadressen 168.63.129.16 som Automation Runbook injicerar i kärnans routingtabell. Dessa routes består inte efter en firmwareuppgradering; kör och verifiera då medföljande runbook igen.

Under distributionen måste Trusted network först vara *, eftersom Azure Automation Runbook ansluter från publika Azure-IP:n. Begränsa NSG:n till dokumenterade admin-CIDR:er direkt efter ett lyckat körresultat. Första brandväggen använder WebAdmin 4444 och SSH 2222, den andra 4445 och 2223. Registrera dem separat och håll brandväggs-, NAT- och routingregler identiska.

Konfigurera probes och egress

På båda brandväggarna konfigureras gateways under Routing > Gateways och proberoutes under Routing > SD-WAN routes; extern route måste ligga över intern. Workload-UDR 0.0.0.0/0 använder Next hop type: Virtual appliance och frontend-IP:n för intern Load Balancer. I appliance visas TCP-probes 4444 och 3128 med källan 168.63.129.16. Vid portbyte ska intern och extern probe förbli olika. Tillåt probevägen i NSG med Source Service Tag AzureLoadBalancer; SFOS-listeners och Sophos särskilda routes måste också stämma. Varken Service Tag eller plattformsadressen är en generellt betrodd internetkälla. Kontrollera båda backends under Load balancer > Monitoring > Insights eller Health Probe Status; en frisk probe validerar inte applikation och returväg.

Kontrollera templatedistributionen

Öppna distributionsresursen för active-active, kontrollera och dokumentera revisionen, välj sedan Deploy to Azure. Kontrollera före Next > Create:

• Subscription, Resource group, Region, Location och tillgång till Automation accounts i abonnemang/region.
• Granskad Base URL, VM name, säkert förvarat Admin password, Image SKU (BYOL/PAYG-new), VM size med minst två NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), ledig Loadbalancer Int IP i LAN.
• Ny/befintlig, grupper och namn för Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Kontrollera befintliga resurser och unik DNS-etikett.
• Spara ursprungliga NSG-regler och godkänd tidsgräns för Trusted network: *. Begränsa administrationen igen även om automationen misslyckas; avbryt utan godkänt tillfälligt undantag i stället för obegränsad publik administration.

Inventera därefter verkliga NIC/subnät, gateways, LB-frontends, probes och administrationsportmappningar; kopiera inte standaloneexemplet.

Gateways och proberutter på båda appliances

Skapa och spara under Routing > Gateways > Add:

Det bevarade exemplet använder 10.54.11.1/10.54.22.1 och WAN för båda gateways, men binder sedan interna/externa rutter till #PortA/#PortB. Den ovanliga mappningen är distributionsspecifik. Kontrollera NIC, SFOS-interface och subnätsnåbarhet; avbryt vid motsägelse och lös med ägaren, utan blind IP-kopiering eller påhittad universell mappning.

Under Routing > SD-WAN routes > Add, först intern, sedan extern, båda Top:

Kontrollera objekt och tjänstdefinition mot verkligt flöde: HTTP betyder inte ändring av TCP-probes 4444/3128 till 80. Gör inte den ospecificerade interna tjänsten till en bred rutt; källa/mål förblir begränsade. Spara, håll extern över intern och upprepa kontrollerad mappning på appliance 2. Kontrollera Load balancers > Monitoring > Metrics > Health probe status, aggregering Avg, filter Backend IP address, per backend/LB; testa verklig egress och retur.

Återställ injicerade rutter efter firmware

Planera underhåll: den dokumenterade runbooken startar om VM och kan bryta sessioner. Exportera SFOS-backup, spara runbook/NSG och kontrollera andra backend före arbete på en VM. Om båda är osunda, planera avbrott i stället för att lova återställning utan driftstopp.

1. Network security groups > [firewall-NSG] > Inbound security rules > allow_ssh: identifiera runnerns åtkomst till verklig SSH-mappning. Källan använder Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, ett riskfyllt tillfälligt undantag, aldrig permanent råd. Föredra verifierad snävare väg; annars uttryckligt godkännande, kort tidsgräns och endast nödvändig SSH-mappning. Gissa inte Azure-CIDR eller öppna andra portar.
2. Resursgrupp > Automation account > Runbooks > [distribuerad runbook] > Edit > Edit in portal. Bevarad revision anger bortkommentering av rader 20–24: identifiera avsett block i verkligt script och spara original; överför inte radnummer mellan revisioner. Avbryt vid oklart syfte. Save > Publish, granska diff, Start.
3. Ange värden för denna VM:

4. Kontrollera jobbets utdata, fel och status. Completed bekräftar endast jobbslut: vänta på omstart/åtkomst, kontrollera rutten 168.63.129.16, båda probes och verklig applikation/egress. Återställ först därefter VM 2 med egna värden.
5. Återställ sparade NSG-begränsningar direkt, även vid fel, och verifiera effektiv åtkomst. Behåll frisk backend, spara fel, återställ script vid felaktig ändring och eskalera före ny körning eller arbete på den andra. Completed bevisar inte 100 % hälsa eller internet. Planera återställning och rollback för den aktuella moln- och appliance-konfigurationen före ändringen.

DNAT och returväg

Extern Load Balancer väljer en brandvägg. HA Ports transporterar NVA-flöden över protokoll och portar men ersätter inte en tjänstespecifik publicering. Skapa en matchande health probe och en Load Balancing-regel kopplad till den för den publicerade TCP-tjänsten på extern Load Balancer. SFOS-NAT-regeln översätter sedan till servern. I Rules and policies > NAT rules gör Translated source (SNAT): MASQ att servern svarar till LAN-IP:n på samma brandvägg. Utan MASQ kan returen passera den andra brandväggen och bryta sessionen.

Direkt publicering av RDP rekommenderas inte. Föredra VPN eller ZTNA. Om tjänsten måste publiceras begränsas källa, tjänst och mål i Azure och SFOS, logging och IPS aktiveras och ett negativt test utförs.

Validera, felsök och återställ

Acceptanstester

1. Kontrollera i Effective routes på en test-VM att 0.0.0.0/0 pekar på SFOS LAN-IP eller, för active-active, intern Load Balancer-IP.
2. Testa DNS, HTTPS och applikationen och bekräfta Rule ID, källa och mål i Log viewer > Firewall. Kör ett tillåtet positivt och ett otillåtet negativt test för en publicerad tjänst.
3. Kontrollera Health Probe Status och Backend Pool för active-active. Ta endast under ett underhållsfönster bort en brandvägg, testa nya anslutningar via den andra och återställ en frisk backend före det andra testet. Befintliga sessioner synkroniseras inte och kan brytas.

Typiska fel

Vid utebliven egress kontrolleras Effective Routes, koppling till workload-subnet, statisk LAN-IP, IP forwarding, NSG och SFOS Rule ID. För unhealthy probe kontrolleras TCP-protokoll/port, listener, NSG och SD-WAN-routes till 168.63.129.16. Injicerade routes består inte efter firmwareuppgradering: kör Sophos-runbook på båda VM:arna igen, kontrollera probes och återställ omedelbart admin-CIDR:erna i SSH-NSG:n. Vid sporadisk DNAT jämförs regler på båda appliances, MASQ, Backend Pool och serverns returroute.

Dokumentera tidigare godkänd Next Hop före en egressåterställning. Återanslut föregående Route Table eller isolera workload-subnet under ändringen. Att enbart koppla bort den nya tabellen kan aktivera Azures systemroute 0.0.0.0/0 -> Internet och kringgå brandväggen; gör detta endast om vägen uttryckligen har granskats och godkänts. Ta bort UDR och tillfälliga regler först när den återställda returvägen har validerats. För DNAT inaktiveras först extern Load Balancer-regel. Azure-snapshots ersätter inte en exporterad SFOS-backup. Dokumentera backup, återuppbyggnad, licenskoppling, ansvarig och kostnadslarm separat.

Fortsätt med den interna Azure VPN Gateway-runbooken eller Entra Domain Services-konfigurationen i AD-runbooken.