Przejdz do tresci
Avanet

Wdrożenie i routing Sophos Firewall w Azure

Sophos Firewall

Sophos Firewall można wdrożyć z Azure Marketplace jako jedną appliance albo przez template Load Balancer z dwiema firewallami. Sophos nazywa drugi projekt active-active, ale nie jest to natywny klaster HA SFOS. Konfiguracja, sesje i status nie synchronizują się jak między dwiema appliance HA.

⚠️ Routing Azure jest częścią konfiguracji firewalla. Prawidłowa reguła SFOS nie wystarcza bez User Defined Route, Network Security Group albo drogi powrotnej przez Load Balancer. Każde udostępnienie wymaga walidacji całej drogi w obie strony.

Wybór modelu i licencji

ModelLicencjaWażna granica
StandaloneBYOL lub PAYGJedna appliance bez redundancji, dla kontrolowanych workloadów z zaakceptowanym oknem serwisowym.
Active-active z Load BalancerJedna licencja BYOL na firewall lub PAYGDwie niezależne firewalle za Standard Load Balancer z HA Ports; template nie obsługuje active-passive.

Dla standalone Sophos zaleca co najmniej Standard_F2s_v2, dwa vCPU i 4 GB RAM. Publiczny IP używa Standard SKU ze statycznym przypisaniem. Basic SKU jest wycofana i nie należy do nowych wdrożeń.

Wdrożenie standalone z Marketplace

Utworzenie i zabezpieczenie appliance

  1. Wybrać Sophos Firewall w Azure Marketplace oraz BYOL lub PAYG.
  2. Określić Resource Group, region i rozmiar. VNet, subnety i sieci zdalne nie mogą się nakładać.
  3. Przypisać PortA do LAN, a PortB do WAN. NSG początkowo otworzyć tylko dla wymaganych źródeł administracyjnych.
  4. Zakończyć wdrożenie i otworzyć WebAdmin pod https://<dns-name>:4444.
  5. W kontrolowany sposób ukończyć kreator, rejestrację, licencjonowanie i aktualizację firmware.
  6. Ustawić prywatny adres NIC LAN jako Static. Dodać do każdej subnet workload UDR 0.0.0.0/0, Virtual appliance, z tym IP LAN jako Next Hop.
  7. Przetestować IP Forwarding, NSG, reguły SFOS i drogę powrotną ze zdefiniowanego klienta.

UDR wymusza ruch wychodzący LAN przez firewall. Bez niej Azure używa trasy domyślnej. Połączenie route-based z Azure VPN Gateway korzysta dodatkowo z interfejsu XFRM oraz tras statycznych, SD-WAN lub BGP.

Przygotowanie planu adresacji

Dla nowego wdrożenia najpierw utworzyć publiczny adres IP w Public IP addresses > Create z IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static i Routing preference: Microsoft network. Ustawić unikalny DNS name label i wybrać Domain name label scope: None. Sophos wskazuje dla tej procedury również DDoS protection > Protection type: Network. Opcja wymaga odpowiedniego planu Azure DDoS i może generować dodatkowe koszty, dlatego przed utworzeniem adresu należy uzgodnić plan z administratorem Azure. Następnie wybrać adres w Public IP name. W tej procedurze Sophos wyraźnie obsługuje tylko strefę 1. Dawna opcja dynamiczna Basic nie nadaje się już do nowych wdrożeń po jej wycofaniu przez Azure.

Przykład do adaptacji używa VNet 10.20.0.0/16, LAN 10.20.10.0/24 na PortA, WAN 10.20.20.0/24 na PortB i statycznego IP LAN 10.20.10.4. Te wartości RFC 1918 należy zastąpić wolnymi zakresami bez nakładania się z peeringiem, VPN i sieciami on-premises.

Utworzenie UDR LAN z dokładnymi polami Azure

Sophos wymaga zatrzymania VM przed ustawieniem statycznego IP LAN: Virtual machines > > Stop, następnie NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static. Po uruchomieniu utworzyć tabelę w Route tables > Create. W Subnets > Associate powiązać każdą podsieć klientów lub workloadów, której ruch ma przechodzić przez appliance. Jeśli klienci znajdują się bezpośrednio w podsieci LAN PortA, powiązać właśnie tę podsieć LAN, jak w podstawowym przykładzie Sophos. Nie powiązywać podsieci WAN firewalla. W Routes > Add ustawić Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance i Next hop address: 10.20.10.4. Sprawdzić Enable IP forwarding na obu NIC. Propagate gateway routes: Yes pozostawić tylko zgodnie z projektem VPN/ExpressRoute. Na końcu utworzyć ograniczoną, logowaną regułę LAN-WAN w Rules and policies > Firewall rules.

Obsługa active-active z Load Balancer

Template Sophos tworzy dwie firewalle oraz zewnętrzny i wewnętrzny Standard Load Balancer z HA Ports. Wymaga VNet /16 oraz subnetów LAN i WAN /24; przed użyciem innych rozmiarów Sophos wymaga konsultacji z przedstawicielem.

Health probes docierają do WebAdmin na 4444 i proxy na 3128. Probe wewnętrzne zależą również od specjalnych tras do adresu platformowego 168.63.129.16, które Automation Runbook wstrzykuje do tabeli routingu kernela. Trasy te nie przetrwają firmware upgrade; dostarczony runbook należy potem uruchomić ponownie i sprawdzić.

Podczas wdrożenia Trusted network musi początkowo mieć wartość *, ponieważ Azure Automation Runbook łączy się z publicznych IP Azure. Po sukcesie natychmiast ograniczyć NSG do udokumentowanych CIDR admina. Pierwsza firewall używa WebAdmin 4444 i SSH 2222, druga 4445 i 2223. Obie appliance rejestruje się osobno i utrzymuje identyczne reguły firewall, NAT i routing.

Konfiguracja probe i egress

Na obu firewallach skonfigurować gateway w Routing > Gateways i trasy probe w Routing > SD-WAN routes; trasa zewnętrzna musi być wyżej niż wewnętrzna. UDR workload 0.0.0.0/0 używa Next hop type: Virtual appliance oraz frontend IP wewnętrznego Load Balancer. W appliance probe TCP 4444 i 3128 są widoczne ze źródłem 168.63.129.16. Po zmianie portów probe wewnętrzna i zewnętrzna muszą pozostać różne. W NSG zezwolić na ścieżkę probe przez Source Service Tag AzureLoadBalancer; listenery SFOS i specjalne trasy Sophos również muszą być zgodne. Ani Service Tag, ani adres platformowy nie są ogólnie zaufanym źródłem internetowym. Oba backendy sprawdzić w Load balancer > Monitoring > Insights lub Health Probe Status; zdrowa probe nie potwierdza aplikacji ani drogi powrotnej.

DNAT i droga powrotna

Zewnętrzny Load Balancer wybiera firewall. HA Ports przenoszą przepływy NVA między protokołami i portami, ale nie zastępują publikacji właściwej dla usługi. Dla publikowanej usługi TCP utworzyć na zewnętrznym Load Balancer odpowiednią health probe oraz powiązaną z nią regułę Load Balancing. Następnie reguła NAT SFOS tłumaczy ruch do serwera. W Rules and policies > NAT rules ustawienie Translated source (SNAT): MASQ powoduje odpowiedź serwera do IP LAN tej samej firewall. Bez MASQ powrót może przejść przez drugą firewall i zerwać sesję.

Bezpośrednie publikowanie RDP nie jest zalecane. Preferowane są VPN lub ZTNA. Jeśli publikacja jest konieczna, ograniczyć źródło, usługę i cel w Azure i SFOS, włączyć logging i IPS oraz wykonać test negatywny.

Walidacja, diagnostyka i wycofanie

Testy odbiorcze

  1. W Effective routes testowej VM sprawdzić, czy 0.0.0.0/0 wskazuje IP LAN SFOS, a dla active-active IP wewnętrznego Load Balancer.
  2. Przetestować DNS, HTTPS i aplikację, a w Log viewer > Firewall potwierdzić Rule ID, źródło i cel. Dla publikacji wykonać dozwolony test pozytywny i niedozwolony test negatywny.
  3. Dla active-active sprawdzić Health Probe Status i Backend Pool. Tylko w oknie serwisowym usunąć jeden firewall, przetestować nowe połączenia przez drugi i przywrócić zdrowy backend przed drugim testem. Istniejące sesje nie są synchronizowane i mogą zostać przerwane.

Typowe błędy

Przy braku egress sprawdzić kolejno Effective Routes, powiązanie subnet workload, statyczny IP LAN, IP forwarding, NSG i Rule ID SFOS. Dla unhealthy probe sprawdzić protokół/port TCP, listener, NSG i trasy SD-WAN do 168.63.129.16. Po firmware upgrade wstrzyknięte trasy nie są trwałe: ponownie uruchomić runbook Sophos dla obu VM, sprawdzić probe i od razu przywrócić CIDR admina w NSG SSH. Przy niestabilnym DNAT porównać reguły obu appliance, MASQ, Backend Pool i trasę powrotną serwera.

Przed wycofaniem egress zapisać wcześniej zatwierdzony Next Hop. Ponownie przypisać poprzednią Route Table albo odizolować subnet workload na czas zmiany. Samo odłączenie nowej tabeli może aktywować trasę systemową Azure 0.0.0.0/0 -> Internet i ominąć firewall; wolno to zrobić tylko po jawnym sprawdzeniu i zaakceptowaniu tej ścieżki. UDR i reguły tymczasowe usunąć dopiero po walidacji przywróconej drogi powrotnej. Dla DNAT najpierw wyłączyć regułę zewnętrznego Load Balancer. Snapshoty Azure nie zastępują eksportowanego backupu SFOS.

Oficjalne źródła