Przejdz do tresci
Avanet

Połączenie Sophos Firewall z Azure VPN Gateway

Sophos Firewall

Azure VPN Gateway łączy lokalną sieć z Azure Virtual Network przez Site-to-Site IPsec. Na Sophos Firewall zwykle buduje się to jako route-based IPsec VPN. W większych lub bardziej dynamicznych środowiskach dochodzi BGP.

Artykuł opisuje praktyczny przepływ między Sophos Firewall i Microsoft Azure: wymagane obiekty Azure, konfigurację po stronie Sophos, świadome dopasowanie parametrów IPsec/IKE i sprawdzenie, czy po zapisie ruch naprawdę działa. Dla ogólnych podstaw IPsec najpierw pasuje konfiguracja Sophos Firewall Site-to-Site IPsec VPN. Jeśli istniejący tunel jest zielony, ale nie przenosi ruchu, pasuje Sophos Firewall IPsec VPN Troubleshooting.

Kiedy ten artykuł pasuje

Artykuł pasuje, gdy lokalna sieć za Sophos Firewall ma zostać połączona z Azure Virtual Network. Chodzi o tunel Site-to-Site między Azure VPN Gateway i lokalnym firewallem, nie o Point-to-Site VPN dla pojedynczych użytkowników ani Sophos Firewall jako appliance w Azure.

Typowe scenariusze:

  • lokalna sieć serwerowa do Azure VMs
  • oddział lub główna lokalizacja do Azure Virtual Network
  • scenariusz hybrydowy z AD, DNS, backupem, monitoringiem lub managementem w Azure
  • migracja z policy-based design do route-based IPsec
  • opcjonalne BGP dla dynamicznego routingu między siecią lokalną i Azure

Azure i Sophos nie zawsze używają tych samych nazw. W Azure są to Virtual network, Gateway subnet, Virtual network gateway, Local network gateway i Connection. Na Sophos Firewall: połączenie IPsec, interfejs XFRM, trasy, reguły firewall i opcjonalnie BGP.

Zaplanować przed konfiguracją

Tunelu Azure nie należy traktować jak samego kreatora kliknięć. Większość błędów wynika z nakładających się sieci, złej SKU gateway, niezgodnych parametrów IPsec/IKE, brakujących tras albo reguł firewall bez logowania.

Sieci i przestrzenie adresowe

Sieci lokalne i Azure address spaces nie mogą się nakładać. Azure kieruje lokalne prefiksy wpisane w Local network gateway do Sophos Firewall. Sophos Firewall kieruje prefiksy Azure przez interfejs XFRM albo BGP.

Wcześniej udokumentować:

  • Azure Virtual Network Address Space, na przykład 10.50.0.0/16
  • subnety Azure, zwłaszcza workload subnets
  • lokalna sieć za Sophos Firewall, na przykład 172.16.10.0/24
  • publiczny IP Sophos Firewall lub routera upstream
  • Azure Public IP Virtual Network Gateway
  • BGP tak lub nie
  • wspólny Preshared Key
  • planowane systemy testowe po obu stronach

Jeśli sieci lokalne i Azure się nakładają, najpierw poprawić design. NAT over IPsec jest możliwy, ale utrudnia eksploatację i troubleshooting.

Route-based zamiast policy-based

Dla Azure route-based IPsec jest zwykle właściwym wyborem. Azure VPN Gateway działa typowo route-based, szczególnie przy wielu prefiksach, BGP, active-active lub późniejszych rozszerzeniach.

Na Sophos Firewall oznacza to:

  • zaplanować połączenie IPsec jako route-based tunnel interface;
  • sprawdzić interfejs XFRM po zapisie;
  • ustawić trasy lub BGP dla prefiksów Azure;
  • utworzyć reguły firewall między lokalnymi strefami i strefą VPN;
  • sprawdzić ruch w Log Viewer i status Azure connection.

Zielony status tunelu to tylko część odbioru. Tunel jest naprawdę sprawdzony dopiero, gdy określony klient osiąga określony cel Azure i obie strony pokazują logi lub liczniki.

Nie zgadywać parametrów IPsec/IKE

Azure VPN Gateway obsługuje określone parametry IPsec/IKE i przy odpowiednich SKU także custom IPsec/IKE policies. Microsoft wskazuje, że custom policy musi być podana kompletnie; częściowe wartości nie wystarczają.

Dla eksploatacji:

  • świadomie wybrać wersję IKE, zwykle IKEv2;
  • udokumentować encryption, integrity, DH group, PFS i lifetimes;
  • porównać Azure Custom Policy i Sophos IPsec Profile;
  • nie przenosić bez kontroli defaultów Sophos-to-Sophos na Azure;
  • planować okno serwisowe i rollback po każdej zmianie policy.

Bez Custom Policy profil Sophos musi pasować do Azure defaults. Z Custom Policy wszystkie wartości muszą być poprawnie utrzymane po obu stronach.

Przygotować stronę Azure

Konfiguracja Azure składa się z kilku obiektów. Nazwy powinny być jednoznaczne, bo późniejszy troubleshooting szybko robi się nieczytelny.

Virtual Network i Gateway subnet

Azure Virtual Network potrzebuje dedykowanego GatewaySubnet. Ten subnet jest używany przez Azure VPN Gateway i nie może służyć dla normalnych VM.

Sprawdzić:

  1. Azure Virtual Network istnieje.
  2. Address Space nie nakłada się na sieci lokalne.
  3. GatewaySubnet istnieje i ma wystarczający rozmiar.
  4. Workload subnets i Network Security Groups pozwalają na wymagany ruch.

Utworzyć Virtual Network Gateway

Virtual network gateway to właściwy Azure VPN Gateway. Ważne:

  • Gateway type: VPN
  • VPN type: Route-based
  • SKU pasująca do przepustowości, SLA, Availability Zone i wymagań BGP
  • Public IP dla gateway
  • Active-active tylko jeśli strona lokalna jest do tego zaprojektowana
  • BGP tylko jeśli ASN, peer IP i koncepcja routingu są ustalone

Tworzenie gateway w Azure często trwa znacznie dłużej niż zwykły dialog firewalla.

Utworzyć Local Network Gateway

Local network gateway opisuje stronę lokalną z perspektywy Azure.

Wpisać:

  1. Nazwę, na przykład lng-sophos-hq.
  2. Endpoint jako publiczny IP lub FQDN strony Sophos.
  3. Local Address spaces przy pracy bez BGP.
  4. BGP settings przy routingu dynamicznym.

Jeśli Sophos Firewall stoi za NAT, trzeba dokładnie sprawdzić, jaki publiczny IP widzi Azure i jak lokalnie działają NAT-T, port forwarding oraz IDs. Prosty standard to Sophos Firewall z własnym publicznym IP.

Utworzyć Connection

Connection łączy Virtual Network Gateway i Local Network Gateway.

Ważne wartości:

  • Connection type: Site-to-site (IPsec)
  • Shared key: identyczny z Sophos Preshared Key
  • IKE Protocol: zgodny z konfiguracją Sophos
  • BGP: tylko jeśli obie strony używają BGP
  • Custom IPsec/IKE policy: tylko jeśli wartości zostały świadomie zaplanowane

Po utworzeniu Connection strona Azure jest gotowa, ale nie automatycznie produkcyjna. Strona Sophos musi znać ten sam tunel, te same parametry i drogę powrotną.

Skonfigurować Sophos Firewall

Na Sophos Firewall tunel tworzy się w Site-to-site VPN > IPsec.

Przygotować IPsec profile

W Profiles > IPsec profiles użyć lub utworzyć profil pasujący do Azure. Wartości muszą odpowiadać Azure default policy albo custom IPsec/IKE policy danej Connection.

Udokumentować:

  • IKE version
  • Phase 1 encryption i authentication
  • DH group
  • Phase 2 encryption i authentication
  • PFS
  • Key lifetime

Jeśli Azure używa Custom Policy, nazwa profilu powinna to pokazywać, na przykład Azure_IKEv2_AES256_G14.

Utworzyć route-based IPsec connection

Ścieżka:

Site-to-site VPN > IPsec

Kroki:

  1. Otworzyć Add.
  2. Wybrać Route-based albo tunnel interface jako typ połączenia.
  3. Ustawić nazwę, na przykład azure-vnet-prod.
  4. Gateway type po stronie Sophos zwykle ustawić na Initiate the connection.
  5. Azure Public IP Virtual Network Gateway wpisać jako Remote Gateway.
  6. Ustawić Preshared Key identyczny z Azure Connection.
  7. Sprawdzić Local ID i Remote ID, zwłaszcza przy NAT lub wielu tunelach.
  8. Wybrać IPsec profile.
  9. Zapisać i aktywować połączenie.

Po zapisie sprawdzić interfejs XFRM w Network > Interfaces. Pozostaje przypisany do strefy VPN. Zależnie od designu używa się go ze statyczną trasą, SD-WAN route albo BGP.

Skonfigurować trasę lub BGP

Bez BGP Sophos Firewall potrzebuje trasy do prefiksów Azure. Zwykle jest to statyczna trasa lub SD-WAN route przez interfejs XFRM.

Z BGP obie strony muszą być zaplanowane:

  • lokalny ASN Sophos Firewall
  • Azure ASN
  • BGP peer IPs
  • dozwolone i ogłaszane prefiksy
  • route advertisement w Azure
  • reguły firewall dla rzeczywistego ruchu

BGP nie zastępuje reguł firewall. Rozsyła tylko trasy. Dostępność serwera w Azure nadal zależy od routingu, NSG, reguł firewall i systemu docelowego.

Utworzyć reguły firewall

Ruch przez tunel wymaga pasujących reguł, zwykle między strefą wewnętrzną i strefą VPN.

Zalecenia przy wdrożeniu:

  • ustawić konkretne sieci lub hosty jako source i destination;
  • wybrać konkretne usługi do pierwszego testu, na przykład ICMP, RDP, HTTPS lub DNS;
  • aktywować Log firewall traffic;
  • po pierwszym teście nie zostawiać reguł na Any;
  • osobno sprawdzić kierunek odwrotny, jeśli Azure ma osiągać systemy lokalne.

Jeśli reguła nie pasuje, użyć Sophos Firewall: sprawdzanie, dlaczego reguła nie pasuje.

Sprawdzić połączenie

Odbiór powinien zawsze sprawdzać dwa poziomy: status tunelu i rzeczywisty ruch.

Sprawdzić Azure

W Azure:

  1. Otworzyć Connection VPN Gateway.
  2. Sprawdzić status połączenia.
  3. Obserwować liczniki danych.
  4. Sprawdzić effective routes właściwej Azure VM.
  5. Sprawdzić Network Security Group docelowych subnetów.

Sam status Azure nie wystarcza. VM może być niedostępna mimo działającej Connection przez NSG, lokalny Windows Firewall, złą trasę lub brak drogi powrotnej.

Sprawdzić Sophos Firewall

Na Sophos Firewall:

  1. Sprawdzić status w Site-to-site VPN > IPsec.
  2. Skontrolować interfejs XFRM w Network > Interfaces.
  3. Sprawdzić trasę do prefiksów Azure.
  4. Filtrować Log Viewer według ruchu testowego.
  5. W razie potrzeby użyć Packet Capture lub strongswan.log.

Dla logów IPsec i analizy CLI pasuje Sophos Firewall IPsec VPN Troubleshooting.

Użyć realistycznego ruchu testowego

ICMP jest dobrym początkiem, ale nie pełnym testem. Następnie testować usługę produkcyjną:

  • DNS do Azure DNS lub domain controller
  • RDP albo SSH do testowej VM
  • HTTPS do aplikacji wewnętrznej
  • ruch backup, monitoring lub management

Źródło jest ważne. Ping bezpośrednio z firewalla nie dowodzi tego samego co test z klienta za firewallem.

Typowe błędy

Tunel pozostaje down

Najczęściej nie pasują gateway IP, wersja IKE, Preshared Key, IDs albo parametry IPsec/IKE. Na Sophos Firewall najpierw sprawdzić strongswan.log i porównać Azure Connection Settings z Sophos IPsec Profile.

Tunel jest połączony, ale ruch nie płynie

Często brakuje tras, reguł firewall, reguł Azure NSG albo drogi powrotnej. Po stronie Sophos sprawdzić Log Viewer i trasę. Po stronie Azure Effective Routes i NSG.

Działa tylko jeden kierunek

To często wskazuje na routing asymetryczny, NSG, host firewall albo brak reguły odwrotnej. Testować oba kierunki osobno i dokumentować źródło ruchu testowego.

BGP nie uczy się tras

Sprawdzić ASN, peer IP, aktywację BGP, adres XFRM i konfigurację Azure BGP. Następnie sprawdzić, które prefiksy są naprawdę ogłaszane i uczone. Działający tunel IPsec nie oznacza automatycznie poprawnego routingu BGP.

Po zmianie policy tunel nie wraca

Custom IPsec/IKE Policies muszą być kompletne i kompatybilne. Jeśli Azure i Sophos inaczej interpretują jeden parametr, połączenie może się nie zestawić. Przed zmianami dokumentować aktualny profil, Azure Policy i działający stan.

FAQ

Czy Sophos Firewall do Azure powinien być policy-based czy route-based?

Dla Azure route-based IPsec jest zwykle lepszym wyborem, szczególnie przy wielu sieciach, BGP lub przyszłych rozszerzeniach. Designy policy-based są dla Azure zwykle mniej elastyczne.

Czy Azure VPN Gateway wymaga BGP?

Nie. Dla prostych połączeń wystarczą statyczne trasy albo Address Spaces w Local Network Gateway. BGP ma sens, gdy prefiksy mają być uczone dynamicznie albo planowanych jest kilka ścieżek.

Dlaczego tunel Azure jest zielony, ale VM niedostępna?

IPsec prawdopodobnie jest zestawiony, ale routing, reguła firewall, Azure NSG, lokalny Windows Firewall albo droga powrotna nie pasują. Dlatego status tunelu i rzeczywisty ruch aplikacyjny trzeba testować osobno.

Czy Sophos Firewall może być za NAT?

Może działać, ale nie jest to prosty standard. Publiczny IP, NAT-T, port forwarding, Local ID, Remote ID i Azure Local Network Gateway muszą być bardzo dokładnie zaplanowane i przetestowane.

Czy parametry Azure IPsec trzeba ustawić jawnie?

Nie zawsze. Bez Custom IPsec/IKE Policy profil Sophos musi pasować do Azure defaults. Z Custom Policy wszystkie parametry muszą być ustawione kompletnie i kompatybilnie po obu stronach.