Hoppa till innehållet
Avanet

Distribuera och routa Sophos Firewall på Azure

Sophos Firewall

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

ModellLicensViktig gräns
StandaloneBYOL eller PAYGEn appliance utan redundans, för kontrollerade workloads med ett accepterat underhållsfönster.
Active-active med Load BalancerEn BYOL-licens per brandvägg eller PAYGTvå fristående brandväggar bakom Standard Load Balancers med HA Ports; mallen stöder inte active-passive.

För standalone rekommenderar Sophos minst Standard_F2s_v2, två vCPU och 4 GB RAM. 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. Definiera Resource Group, region och storlek. VNet, subnet och fjärrnät får inte överlappa.
  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. Sätt LAN-NIC:ens privata adress 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.

UDR tvingar utgående LAN-trafik genom brandväggen. Utan den 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. Sophos stöder uttryckligen endast zon 1. 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. Efter start skapar du tabellen under Route tables > Create. 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.

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.

Officiella källor