Planowanie, wdrażanie i obsługa bramy Sophos ZTNA Gateway

Brama Sophos ZTNA Gateway łączy uprawnionych użytkowników z aplikacjami wewnętrznymi. Dostępne są trzy obsługiwane sposoby wdrożenia: lokalna maszyna wirtualna bramy na VMware ESXi lub Microsoft Hyper-V, maszyna wirtualna Sophos Cloud Gateway na jednym z tych hipernadzorców albo Sophos Cloud Gateway na centralnie zarządzanej Sophos Firewall. Ta instrukcja prowadzi od wyboru wariantu przez odbiór po bezpieczne wycofanie. Przy wcześniejszym wyborze między ZTNA a klasycznym dostępem zdalnym pomocne są Sophos Connect czy SSL VPN: które rozwiązanie dostępu zdalnego wybrać? oraz Zero Trust w prostych słowach: ZTNA zamiast klasycznej sieci VPN.

Obecny interfejs nosi nazwę Sophos Fusion; starsze teksty pomocy i niektóre ilustracje nadal używają nazwy Sophos Central. Jeśli ilustracja różni się od opisanych tutaj aktualnych ścieżek i nazw pól, kieruj się opisem tekstowym.

Cel i krótka odpowiedź

Wybierz typ bramy według ścieżki przepływu danych i odpowiedzialności za utrzymanie, a nie liczby kliknięć:

Brama lokalna

• Obsługiwana platforma: ESXi lub Hyper-V
• Ścieżka danych i ekspozycja: Brama i płaszczyzna danych działają w centrum danych klienta; brama jest dostępna z internetu.
• Główne wymaganie sieciowe: Na interfejsach zewnętrznych zezwól na ruch przychodzący tylko na TCP 80 i 443, przekieruj oba porty przez DNAT i zablokuj wszystkie pozostałe porty przychodzące. Nie umieszczaj przed bramą serwera reverse proxy.

Sophos Cloud Gateway jako maszyna wirtualna

• Obsługiwana platforma: ESXi lub Hyper-V
• Ścieżka danych i ekspozycja: Sophos zarządza punktem wejścia w chmurze; maszyna wirtualna łączy Sophos Cloud z zasobami wewnętrznymi i nie jest publikowana jako osobny punkt wejścia z internetu.
• Główne wymaganie sieciowe: Na zewnętrznym interfejsie bramy zezwól tylko na ruch wychodzący TCP 443; zapewnij publiczne rekordy CNAME i prywatne rozwiązywanie nazw DNS.

Sophos Cloud Gateway na Sophos Firewall

• Obsługiwana platforma: centralnie zarządzana zapora sprzętowa, chmurowa, wirtualna lub programowa z SFOS 19.5 MR3 lub nowszym
• Ścieżka danych i ekspozycja: Nie wymaga osobnej maszyny wirtualnej bramy; uwierzytelnianie i autoryzacja odbywają się w Sophos Cloud.
• Główne wymaganie sieciowe: Zapora musi być zarządzana przez Sophos Fusion; uwzględnij region, dostawcę tożsamości, certyfikat i specjalny adres URL przekierowania.

Maszynę wirtualną można wdrożyć w trybie jednointerfejsowym lub dwuinterfejsowym. Tryb jednointerfejsowy używa interfejsu zewnętrznego do ruchu przychodzącego i wychodzącego oraz ogranicza zmiany w infrastrukturze. Tryb dwuinterfejsowy rozdziela interfejs zewnętrzny i wewnętrzny, wymaga dwóch kart sieciowych i ewentualnie tras statycznych; według producenta zapewnia najwyższy poziom bezpieczeństwa i najlepszą przepustowość. Osobna instrukcja Publikowanie serwera przez DNAT na Sophos Firewall wyjaśnia działanie odpowiedniej funkcji zapory; wymagania dotyczące portów ZTNA podano niżej.

Wymagania wstępne, licencja i role

Licencja i role administracyjne

• Funkcje ZTNA wymagają odpowiedniej licencji. Informacje o wydaniach bramy wyraźnie oznaczają funkcje zależne od licencji.
• Sophos Fusion Firewall Management wymaga płatnej subskrypcji oprócz podstawowej licencji zapory.
• Do zarejestrowania zapory w Sophos Fusion potrzebny jest Central Super Admin. Alternatywnie taki administrator może wygenerować kod OTP na podstawie numeru seryjnego zapory i przekazać go administratorowi zapory; kod OTP jest ważny przez 14 dni.
• Przypisane grupy użytkowników muszą być zsynchronizowane z Sophos Fusion. Jako usługi katalogowe obsługiwane są Microsoft Entra ID i Active Directory. Jako dostawcy tożsamości udokumentowani są Microsoft Entra ID, Okta i lokalne Active Directory.
• Grupy Entra ID muszą mieć włączone zabezpieczenia. W przypadku grup utworzonych bezpośrednio w Entra ID dzieje się to automatycznie; grupy importowane z AD lub utworzone w portalu Microsoft 365 mogą różnić się pod tym względem.

Przeanalizowana dokumentacja bramy nie wskazuje bardziej szczegółowej roli administratora ZTNA. Jeśli konto nie widzi opisanych menu lub działań, nie rozszerzaj uprawnień metodą prób i błędów. Poproś uprawnionego administratora Sophos Fusion o sprawdzenie ról przypisanych w danym tenancie.

Certyfikat

Brama wymaga certyfikatu typu wildcard. Obsługiwane są certyfikaty od Let’s Encrypt lub zaufanego urzędu certyfikacji:

• RSA z kluczem o długości co najmniej 2048 bitów;
• ECDSA, ale nie z krzywymi P-384 ani P-521.

Przy wdrażaniu maszyny wirtualnej obsługiwany jest jeden certyfikat wildcard. Przygotuj certyfikat i klucz prywatny. Można je przesłać w szczegółach bramy w sekcji Certificate; Sophos Fusion może też wygenerować tam certyfikat Let’s Encrypt.

Praktyczny sposób uzyskania certyfikatu opisuje Tworzenie certyfikatu wildcard Let’s Encrypt. Dla certyfikatów zarządzanych bezpośrednio na Sophos Firewall osobną procedurą jest Zarządzanie certyfikatami Let’s Encrypt na Sophos Firewall.

Host, czas i zasoby

Dyski SSD są zalecane ze względu na bardziej równomierną wydajność operacji dyskowych I/O. Data i godzina hosta muszą być poprawne, a strefa czasowa ustawiona na UTC. Brama przejmuje czas hosta i może działać nieprawidłowo, jeśli jest on błędny.

W zakresie skalowania maszyn wirtualnych bramy Sophos podaje 10 000 połączeń agentów na węzeł i do 90 000 połączeń agentów w klastrze złożonym z maksymalnie dziewięciu węzłów. Te dane producenta nie gwarantują określonej przepustowości i nie stanowią liczby użytkowników ani licencji. Nie należy ich automatycznie odnosić do bramy na Sophos Firewall ani do sesji przeglądarkowych bez agenta. Przy planowaniu nadal trzeba osobno ocenić zasoby hosta, obciążenie aplikacji i pożądaną rezerwę na wypadek awarii węzła; opisane poniżej reguły tworzenia klastra i testy pilotażowe pozostają obowiązujące.

Sieć, IPv4 i dozwolone cele

• Nie używaj dla bramy sieci 10.42.0.0/16, 10.43.0.0/16 ani 10.108.0.0/16. Są zarezerwowane dla usług wewnętrznych.
• Bramy nie obsługują IPv6. W tym scenariuszu nie przydzielaj bramie ani urządzeniom końcowym adresów IPv6 przez DHCP. Na już skonfigurowanych urządzeniach końcowych trzeba ręcznie wyłączyć IPv6.
• Użyj statycznego adresu IPv4 lub rezerwacji DHCP. Brama nie potrafi obsłużyć późniejszej zmiany swojego adresu IP.
• Jeśli użytkownicy korzystają z zasobów ZTNA z tej samej sieci co brama, reguła SNAT typu MASQ zapobiega trasowaniu asymetrycznemu.
• Jeśli brama ma kilka węzłów, wszystkie muszą znajdować się w tej samej podsieci i mieć między sobą bardzo małe opóźnienia.

Brama lokalna umieszczona za zaporą musi mieć dostęp do poniższych celów, zwykle przez TCP 443:

• sophos.jfrog.io
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com
• *.amazonaws.com
• production.cloudflare.docker.com
• *.docker.io
• *.sophos.com
• login.microsoftonline.com
• graph.microsoft.com
• sentry.io
• *.okta.com, jeśli dostawcą tożsamości jest Okta
• wsserver-<Gateway-FQDN>
• nazwa FQDN bramy skonfigurowana w jej ustawieniach

Ponadto ztna.apu.sophos.com wymaga TCP 22. Jeśli zapora przed bramą odszyfrowuje ruch TLS, wyłącz wsserver-<Gateway-FQDN> z odszyfrowywania.

ZTNA kontroluje dostęp do aplikacji webowych i lokalnych. Opisany tutaj natywny dostęp do aplikacji korzysta z agenta ZTNA. Dostęp do RDP/SSH bez agenta przez pełny Protected Browser jest osobną ścieżką z własnymi zasobami i zasadami; rozszerzenie przeglądarki nie wystarcza, a ten wariant nie zapewnia ogólnej obsługi dowolnych protokołów lokalnych. Aplikacje z dynamicznym przydzielaniem portów lub bardzo dużą liczbą portów, na przykład starsze produkty VoIP, nie są obsługiwane. Agent jest udokumentowany dla Windows 10 1803 lub nowszego i macOS Big Sur 11 lub nowszego.

Konfiguracja z przykładowymi wartościami do dostosowania

Użyj własnych wartości. Poniższe nazwy służą tylko wyjaśnieniu przyporządkowania:

Aktualne ścieżki w interfejsie

Poniższe ścieżki i działania używają angielskich etykiet interfejsu potwierdzonych w aktualnej pomocy producenta. Nazwa, FQDN bramy i domena zasobów są opisane jako techniczne wartości do wprowadzenia, a nie jako niepotwierdzone etykiety pól:

• My Products > ZTNA > Gateways, a następnie Add gateway
• My Products > ZTNA > Settings > Domains
• Devices > Installers

1. Przygotowanie obrazu maszyny wirtualnej

W przypadku ESXi:

1. Otwórz Devices > Installers, znajdź Zero Trust Network Access i pobierz obraz bramy.
2. Zaakceptuj umowę licencyjną i, jeśli są wymagane, formularze zgodności eksportowej.
3. Wdróż plik OVA w vSphere przez kreator wdrażania.
4. Wyłącz automatyczne uruchamianie. Maszyna wirtualna nie może wystartować bez pliku ISO utworzonego w dalszej części procedury.

W przypadku Hyper-V:

1. Otwórz Devices > Installers i w sekcji Zero Trust Network Access kliknij Download Gateway VM image for Hyper-V.
2. Rozpakuj plik VHDX. Jednego pliku VHDX używaj tylko dla jednej maszyny wirtualnej; dla kolejnych maszyn wykonaj kopie.
3. Utwórz maszynę wirtualną generacji 1 z co najmniej 4096 MB pamięci początkowej i dwoma procesorami wirtualnymi. Podłącz istniejący plik VHDX.
4. Do wdrożenia dwuinterfejsowego dodaj drugą kartę sieciową. Jeśli używasz VLAN-ów, przypisz odpowiednie identyfikatory VLAN.

2A. Tworzenie bramy lokalnej

1. Otwórz My Products > ZTNA > Gateways > Add gateway.
2. W polu Gateway Mode wybierz On-premises.
3. Wprowadź nazwę bramy, FQDN bramy oraz domenę zasobów.
4. W polu Platform type wybierz VMware ESXi lub Hyper-V zgodnie z hostem.
5. Wybierz Deployment mode: One-arm lub Two-arm.
6. Skonfiguruj interfejsy. Przy opcji DHCP rezerwacja adresu jest obowiązkowa. Przy opcji Static IP podaj adres IP, podsieć i serwer DNS. Jeśli wdrożenie dwuinterfejsowe ma sięgać do aplikacji w kilku sieciach wewnętrznych, dodaj Static routes.
7. Prześlij certyfikat wildcard.
8. Kliknij Save and generate file. Początkowo stan to Waiting for Deployment; zostanie utworzony indywidualny startowy plik ISO.
9. Na zaporze zezwól na ruch przychodzący tylko na TCP 80 i 443, utwórz DNAT dla obu portów na zewnętrzny adres IP bramy lub wirtualny adres IP klastra i zablokuj wszystkie pozostałe porty przychodzące. Nie używaj serwera reverse proxy.

2B. Tworzenie Sophos Cloud Gateway jako maszyny wirtualnej

1. Najpierw zweryfikuj domenę pod My Products > ZTNA > Settings > Domains > Add domain.
2. Sophos Fusion wygeneruje CNAME, na przykład 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Opublikuj u dostawcy DNS dokładnie wartość wygenerowaną dla swojego tenanta.
3. Poczekaj na propagację DNS i kliknij Validate pod Settings > Domains. Kontynuuj dopiero, gdy stan będzie wynosił Validated.
4. Kliknij Add gateway, w polu Gateway Mode wybierz Sophos Cloud i wprowadź nazwę bramy oraz FQDN bramy. FQDN bramy musi odpowiadać wartości podanej podczas rejestrowania aplikacji ZTNA.
5. Wybierz zweryfikowaną Domain, właściwy Platform type, Identity provider i region najbliższy centrum danych w sekcji Points of Presence.
6. Wybierz One-arm lub Two-arm, skonfiguruj interfejsy z adresami zarezerwowanymi lub statycznymi oraz, w razie potrzeby, trasy statyczne. Prześlij certyfikat wildcard.
7. Kliknij Save and generate file. Skopiuj domenę aliasową wygenerowaną w oknie Gateway added i opublikuj ją w publicznym DNS jako CNAME nazwy FQDN bramy.
8. Na zewnętrznym interfejsie zezwól tylko na ruch wychodzący TCP 443. W tym modelu nie konfiguruje się publikowania maszyny wirtualnej przez przychodzący DNAT.

Od wersji ZTNA 2.1 domyślnie skonfigurowany jest dodatkowy punkt dostępu sąsiadujący z głównym PoP. Można go wyłączyć w sekcji Settings. Mimo to wybierz główny PoP blisko centrum danych.

2C. Tworzenie Sophos Cloud Gateway na Sophos Firewall

Ta opcja nadaje się również do zasobów w Azure: najpierw wdróż Sophos Firewall jako wirtualne urządzenie SFOS na obsługiwanej platformie, zarządzaj nim centralnie, a następnie skonfiguruj bramę ZTNA na tej zaporze. Nie jest to oddzielna maszyna wirtualna bramy z punktów 2A lub 2B; jej wymagania ESXi/Hyper-V nie stanowią instrukcji wdrożenia w Azure.

1. Sprawdź, czy zapora działa z SFOS 19.5 MR3 lub nowszym i jest centralnie zarządzana przez Sophos Fusion. Jeśli nie została jeszcze zarejestrowana, użyj w zaporze opcji Register z danymi logowania superadministratora lub kodem OTP wygenerowanym przez Super Admina.
2. Zweryfikuj domenę zgodnie z punktem 2B.
3. Otwórz My Products > ZTNA > Gateways > Add gateway i wybierz Gateway Mode: Sophos Cloud.
4. Wprowadź nazwę bramy i FQDN bramy, wybierz zweryfikowaną Domain i ustaw Platform type na Firewall.
5. W polu Firewall wybierz urządzenie SFOS. Lista zawiera tylko centralnie zarządzane zapory od wersji 19.5 MR3. Z pary HA można wybrać aktywną zaporę; dzięki temu po przełączeniu awaryjnym druga zapora może przejąć ruch i usługi.
6. Wybierz Identity provider i Points of Presence, prześlij certyfikat i kliknij Save. Brama powinna stać się aktywna po około pięciu minutach.
7. Dodaj u dostawcy tożsamości odrębny adres URL przekierowania https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

Do dostępu administracyjnego Sophos zaleca portal administracyjny jako zasób ZTNA zamiast bezpośredniego dostępu przez WAN. Zanim ograniczysz istniejący dostęp WAN, sprawdź dostęp ZTNA z uprawnionym administratorem i zachowaj zatwierdzoną alternatywną drogę zarządzania. Nadal obowiązują poniższe ograniczenia HA i portali.

Na centralnie zarządzanych zaporach Control Center pokazuje stan ZTNA: Active po skonfigurowaniu, Not configured bez konfiguracji. To informacja o integracji, a nie dowód działania dostępu do zasobów; nadal wymagane są kontrole DNS, certyfikatu i dostępu pilotażowego z sekcji walidacji.

Ograniczenia tego wariantu:

• Przy wdrożeniu HA w trybie aktywny-aktywny portal administracyjny zapory nie jest dostępny przez ZTNA.
• Portal użytkownika i portal VPN zapory nie są obsługiwane przez bramę ZTNA.
• Portal administracyjny można w pozostałych przypadkach utworzyć jako zasób typu Web Admin Portal. Przy dostępie bez agenta wygenerowaną domenę aliasową publikuje się jako publiczny CNAME; przy dostępie z agentem agent przechwytuje zewnętrzny FQDN.

3. Opcjonalne utworzenie klastra maszyn wirtualnych

Utwórz klaster, zanim pobierzesz startowe pliki ISO:

1. Otwórz nową bramę i kliknij Add/Edit instances > Add another instance. Klastrowanie włączy się automatycznie.
2. Wprowadź jeszcze nieużywany wirtualny adres IP klastra z tego samego zakresu adresów IP co instancje. Przy wdrożeniu dwuinterfejsowym z zewnętrznym modułem równoważenia obciążenia pozostaw zewnętrzny adres VIP klastra pusty.
3. Wprowadź nazwę maszyny wirtualnej i adres IP interfejsu; przy wdrożeniu dwuinterfejsowym podaj adres wewnętrzny i zewnętrzny.
4. Powtórz to dla co najmniej trzech instancji. Obsługiwanych jest od trzech do dziewięciu instancji, zawsze w nieparzystej liczbie.
5. Skieruj DNAT bramy lokalnej na zewnętrzny adres VIP klastra. Co najmniej połowa węzłów musi pozostać aktywna.

4. Podłączenie startowego ISO i zatwierdzenie rejestracji

Każdy plik ISO jest jednoznacznie przypisany do bramy lub instancji i nie wolno go używać ponownie.

• ESXi: Podłącz ISO do napędu CD/DVD, wybierz Connect i Connect at Power on. Istniejące urządzenie szeregowe można usunąć.
• Hyper-V: W ustawieniach maszyny wirtualnej wybierz dla napędu DVD IDE Controller 1 > Image file i podłącz ISO.
• Dopiero wtedy uruchom maszynę wirtualną. ISO musi pozostać podłączone również po udanym uruchomieniu.
• Otwórz szczegóły bramy. Stan zmieni się z Waiting for Deployment na Awaiting Approval lub Waiting for gateway approval.
• Kliknij Approve. W klastrze zatwierdź tylko pierwszą instancję; pozostałe instancje będą następnie zarządzane automatycznie.
• Zatwierdzenie może potrwać do dziesięciu minut. Sprawdź stan końcowy właściwy dla platformy: lokalnie na ESXi Connected, lokalnie na Hyper-V Active, Sophos Cloud na ESXi Active i Connected, Sophos Cloud na Hyper-V Active.

Weryfikacja DNS i ścieżki danych

Publiczne i prywatne serwery DNS pełnią różne funkcje:

Brama lokalna

• Z agentem: Agent przechwytuje żądanie dotyczące prywatnej aplikacji i przydziela jej adres z zakresu 100.64.x.x. Aby zestawić tunel, rozwiązuje FQDN bramy przez publiczny rekord A na adres IP bramy. Następnie brama rozwiązuje FQDN aplikacji przez prywatny serwer DNS.
• Bez agenta: Publiczny rekord CNAME aplikacji wskazuje na FQDN bramy, a jego publiczny rekord A na adres IP bramy. Brama pyta prywatny serwer DNS o wewnętrzny adres docelowy aplikacji.

Sophos Cloud Gateway

• Z agentem: Publiczny DNS rozwiązuje nazwę prywatnej aplikacji na przypisaną domenę aliasową. Prowadzi ona przez PoP Sophos Cloud do bramy. Następnie brama rozwiązuje wewnętrzny adres docelowy przez prywatny DNS.
• Bez agenta: Publiczny rekord CNAME zasobu wskazuje na domenę aliasową wygenerowaną przez Sophos. Dla każdego nowego zasobu bez agenta brama inicjuje nowy tunel do PoP na TCP 443. PoP przyporządkowuje żądanie do bramy na podstawie aliasu.

Połączenie agenta z bramą lub PoP używa wzajemnego uwierzytelniania TLS. Udokumentowane są TLS 1.2 i nowsze oraz protokoły szyfrowania z kluczami o długości do 256 bitów.

Agent ZTNA zmienia domyślną kartę TAP. Dlatego nslookup może pozornie nie rozwiązywać nazw spoza ZTNA. Podaj jawnie serwer DNS faktycznie odpowiedzialny za daną nazwę:

nslookup <FQDN> <DNS-Server>

Walidacja i oczekiwany wynik

Nie poprzestawaj na zielonym stanie bramy. Użyj użytkownika testowego z ograniczonymi uprawnieniami i dokładnie jednego zasobu testowego.

1. Zarządzanie: Pod My Products > ZTNA > Gateways brama ma stan Active lub Connected. W Gateway Details wersja oprogramowania jest prawidłowa, a w klastrach prawidłowy jest stan wszystkich węzłów.
2. Publiczny DNS: Dla bramy lokalnej rekord A bramy i ewentualny CNAME zasobu zwracają zaplanowany publiczny adres IP. Dla Cloud Gateway rekordy CNAME służące do walidacji domeny, bramy i zasobów są dokładnie takie, jak wygenerował Sophos.
3. Prywatny DNS: Brama potrafi rozwiązać wewnętrzny FQDN zasobu na wewnętrzny adres IP serwera.
4. Certyfikat: FQDN, zakres certyfikatu wildcard, łańcuch, okres ważności i klucz prywatny są zgodne. Przeglądarka ani agent nie pokazują ostrzeżenia o zaufaniu.
5. Sieć: Dla bramy lokalnej ruch TCP 80 i 443 trafia na przewidziane reguły DNAT, a inne porty przychodzące są zablokowane. Dla Cloud Gateway działa tunel wychodzący TCP 443 bez publikowania ruchu przychodzącego.
6. Dostęp: Uprawniony użytkownik pilotażowy ma dostęp tylko do przypisanej aplikacji. Nieuprawniony użytkownik testowy nie uzyskuje dostępu.
7. Aplikacja: Sprawdź nie tylko logowanie, lecz także rzeczywistą, ograniczoną transakcję. Ścieżka powrotna działa, a aplikacja widzi oczekiwane źródło połączenia.
8. Stabilność: Przetestuj dostęp z zewnątrz oraz, jeśli jest przewidziany, z tej samej sieci co brama. Drugi test potwierdza w szczególności działanie MASQ i ścieżki powrotnej.
9. Klaster: Nie zatrzymuj żadnego węzła poza zatwierdzonym testem konserwacyjnym i przełączenia awaryjnego. W zaplanowanym teście co najmniej połowa instancji pozostaje aktywna, a żądania przechodzą przez pozostałe węzły.

Jeśli wynik odbiega od oczekiwanego, przejdź do odpowiedniej kategorii objawów poniżej. Nie zmieniaj jednocześnie DNS, certyfikatu, NAT i zasad dostępu.

Do osobnej analizy warstwy zapory służą Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture oraz Zrozumienie NAT na Sophos Firewall.

Rozwiązywanie problemów według objawów

Brama pozostaje w stanie „Waiting for Deployment” lub nie łączy się z Sophos Fusion

1. Sprawdź, czy unikatowe ISO jest podłączone dokładnie do właściwej maszyny wirtualnej i czy włączono Connect at Power on.
2. Sprawdź czas hosta i strefę czasową UTC.
3. Sprawdź statyczny adres IP lub rezerwację DHCP, DNS i dozwolone cele; ztna.apu.sophos.com wymaga TCP 22.
4. Sprawdź wyjątek od odszyfrowywania TLS dla wsserver-<Gateway-FQDN>.
5. Uruchom diagnostykę maszyny wirtualnej w vSphere lub Hyper-V Manager.

Stan oczekiwania na zatwierdzenie

Otwórz szczegóły bramy i kliknij Approve. Poczekaj do dziesięciu minut. W klastrze zatwierdź tylko pierwszą instancję. Jeśli stan się nie zmieni, najpierw sprawdź łączność i czas, zamiast tworzyć od nowa kolejne instancje.

Brama przestaje działać po zmianie DHCP lub sieci

Brama nie obsługuje zmiany własnego adresu IP. Przywróć pierwotne przypisanie adresu i ustaw rezerwację DHCP lub adres statyczny. Następnie sprawdź DNS, DNAT, a w klastrach także adresy docelowe VIP. Planowaną zmianę adresu IP trzeba traktować jako nowe wdrożenie, a nie prostą zmianę w działającym systemie.

Logowanie działa, ale zasób jest niedostępny

1. Rozwiąż FQDN zasobu bezpośrednio na prywatnym serwerze DNS.
2. Sprawdź trasę i regułę zapory zezwalającą na ruch z bramy do udokumentowanego portu docelowego.
3. Przy wdrożeniu dwuinterfejsowym sprawdź trasy statyczne do pozostałych sieci wewnętrznych.
4. Przy dostępie z tej samej sieci co brama sprawdź regułę MASQ i trasowanie asymetryczne.
5. Sprawdź, czy aplikacja korzysta z portów dynamicznych lub bardzo wielu portów; takie aplikacje nie są obsługiwane.

Zewnętrzny dostęp do bramy lokalnej nie działa

Sprawdź publiczny rekord A, porty TCP 80 i 443, obie reguły DNAT i ich docelowy adres IP lub adres VIP klastra. Upewnij się, że przed bramą nie stoi serwer reverse proxy. Pozostałe porty przychodzące muszą być zablokowane.

Cloud Gateway lub zasób bez agenta jest niedostępny

Sprawdź kolejno:

1. stan domeny Validated;
2. CNAME bramy i CNAME zasobu względem domen aliasowych wygenerowanych w Sophos Fusion;
3. wychodzący ruch TCP 443 z bramy do PoP;
4. prywatne rozwiązywanie nazwy aplikacji przez bramę;
5. właściwy region PoP oraz, w przypadku bram na zaporze, specjalny adres URL przekierowania OAuth2.

nslookup zwraca błędne wyniki po zainstalowaniu agenta

Agent ustawia kartę ZTNA TAP jako domyślną. Ponów zapytanie, jawnie podając serwer DNS. Niepowodzenie zapytania przez kartę TAP nie dowodzi, że zwykły serwer DNS nie zna danej nazwy.

Błąd certyfikatu

Sprawdź zakres certyfikatu wildcard, pełny łańcuch, klucz prywatny i algorytm. P-384/P-521 w przypadku ECDSA oraz RSA z kluczem krótszym niż 2048 bitów nie są obsługiwane. Porównaj FQDN bramy, domenę zasobów i nazwy w certyfikacie, zanim prześlesz nowy certyfikat.

Pakiet diagnostyczny dla pomocy technicznej Sophos

Dla bram wirtualnych na ESXi lub Hyper-V:

1. Otwórz Gateway Details > Troubleshooting logs.
2. Kliknij Generate logs. Tworzenie może potrwać kilka minut.
3. Pobierz nowy wpis z kolumny Troubleshooting log. Wygaśnie po godzinie.
4. W razie potrzeby włącz w szczegółach bramy ograniczony czasowo dostęp pomocy technicznej i przekaż wyświetlony token wyłącznie pomocy technicznej Sophos.

Ta funkcja dzienników nie dotyczy bramy zintegrowanej z Sophos Firewall.

Bezpieczny powrót do poprzedniego stanu lub wycofanie z eksploatacji

Rozróżniaj zmianę konfiguracji, aktualizację bramy wirtualnej, zmianę oprogramowania układowego zapory i trwałe usunięcie. Nie obowiązuje dla nich ta sama procedura wycofania zmian.

Przed każdą zmianą

• Zapisz tryb bramy, FQDN, adresy IP, adres VIP klastra, platformę, wersję, certyfikat, publiczne rekordy CNAME/A, DNAT/SNAT, trasy statyczne, przypisane zasoby i grupę pilotażową.
• Sprawdź, które zasoby i osoby zależą od bramy, i uzgodnij okno serwisowe.
• W pilotażu zmieniaj tylko jedną warstwę w każdym kroku. Zachowaj ostatnie działające wartości DNS i zapory.

Przenoszenie zasobów na bramę na zaporze

W przypadku udokumentowanej migracji z istniejącej bramy na bramę na zaporze:

1. W pełni skonfiguruj bramę na zaporze.
2. Dodaj jej nowy adres URL przekierowania OAuth2 u dostawcy tożsamości.
3. Otwórz Resources & access, wybierz zasób i ustaw Gateway na bramę na zaporze.
4. Przy dostępie bez agenta opublikuj nową domenę aliasową zapory jako publiczny CNAME.
5. Przeprowadź walidację z użytkownikiem o ograniczonych uprawnieniach. Usuń stary rekord DNS lub starą bramę dopiero po udanym teście aplikacji.

Usuwanie bramy

W szczegółach bramy dostępna jest opcja Delete. Powiązane źródła nie opisują jednak ani przywracania usuniętej bramy, ani automatycznego, bezpiecznego transakcyjnie wycofywania zmian w DNS, NAT, zasobach i certyfikatach. Dlatego:

1. Nie usuwaj bramy jako pierwszego kroku wycofywania zmian.
2. Najpierw przenieś lub wyłącz zależne zasoby w uzgodnionym oknie zmian i upewnij się, że brama nie obsługuje już ruchu produkcyjnego.
3. Następnie usuń zbędne publiczne rekordy DNS i reguły zapory na podstawie wcześniej sporządzonej listy.
4. Usuń bramę dopiero po uzyskaniu zgody osób odpowiedzialnych za aplikację i sieć.
5. Jeśli zależności lub sposób przywrócenia działania są niejasne, zatrzymaj się przed kliknięciem Delete i przekaż sprawę pomocy technicznej Sophos.

Powrót do poprzedniego stanu po aktualizacji

Przeanalizowane instrukcje nie opisują obniżenia wersji bramy wirtualnej. Po nieudanej aktualizacji nie próbuj nieudokumentowanego przywracania obrazu; wygeneruj dzienniki, utrzymaj dostęp przez niezmienioną instancję lub klaster i przekaż sprawę pomocy technicznej Sophos.

W przypadku bramy zintegrowanej z Sophos Firewall obowiązuje udokumentowana procedura powrotu do poprzedniej wersji oprogramowania układowego:

1. Sprawdź ważność subskrypcji pomocy technicznej i wykonaj kopię zapasową konfiguracji zapory.
2. Przed zmianą sprawdź, czy wersja docelowa obsługuje skonfigurowaną liczbę bram; nadmiarowe bramy trzeba usunąć przed zmianą oprogramowania układowego.
3. Zaplanuj zmianę poza godzinami największego obciążenia. Zapora zakończy sesje i uruchomi się ponownie.
4. W Backup and firmware > Firmware można przesłać zgodną wersję i uruchomić ją przez Upload and boot albo uruchomić istniejący nieaktywny obraz przez Boot firmware image.
5. Aktywne i poprzednie oprogramowanie układowe wraz ze swoimi konfiguracjami znajdują się na oddzielnych partycjach. Powrót do poprzedniej wersji oprogramowania układowego przywraca więc również poprzedni stan jej konfiguracji.
6. Po ponownym uruchomieniu zaloguj się i sprawdź aktywną wersję oprogramowania układowego w lewym górnym rogu Control Center, a następnie stan bramy, DNS i dostęp pilotażowy.

Eksploatacja, przegląd i cykl życia

Aktualizacja bramy wirtualnej

W sekcji Gateways zielony znacznik wyboru obok numeru wersji informuje o dostępnej wersji dla maszyny wirtualnej. Kliknij numer wersji, wybierz wersję docelową i zaplanuj aktualizację lub wybierz Now. Jeśli wymagany jest restart, interfejs pokaże ostrzeżenie; zaplanuj go w oknie serwisowym. Funkcja ta dotyczy tylko bram na ESXi i Hyper-V. Bramę na zaporze aktualizuje się przez oprogramowanie układowe SFOS.

Stan weryfikacji na 21 października 2026 r.: Sophos ogłosił 6 października 2026 r. aktualizacje 2.2.1 dla aplikacji i 2.3.0 dla obrazu bazowego. Dotyczą one maszyn wirtualnych bram ZTNA zarządzanych przez klienta na ESXi i Hyper-V. Ze względu na poprawki bezpieczeństwa w 2.3.0 Sophos zaleca szybkie rozpoczęcie procesu aktualizacji. Oba etapy wymagają oddzielnej weryfikacji:

1. Sprawdzić wersję źródłową i oferowaną ścieżkę aktualizacji. Starsza brama z 2.1.2 nie może przejść bezpośrednio do 2.2.1; najpierw ustalić wymagane wersje pośrednie na podstawie kolejności wydań i kroków oferowanych w Fusion.
2. Wykonać lub zaplanować oferowaną aktualizację aplikacji do 2.2.1.
3. Poczekać, aż brama ponownie zgłosi Active. Wszystkie testy w konsoli diagnostycznej bramy muszą zakończyć się powodzeniem przed rozpoczęciem kolejnego etapu.
4. Następnie zaktualizować obraz bazowy do 2.3.0. Ponownie potwierdzić Active, pomyślną diagnostykę bramy i opisany wyżej dostęp pilotażowy.

Sophos podaje około 30 minut na każdą aktualizację pojedynczego węzła; przy wielu węzłach czas odpowiednio się wydłuża. Te aktualizacje bramy nie wymagają aktualizacji agenta ZTNA. Brama na Sophos Firewall nie potrzebuje tych aktualizacji VM i nadal korzysta z procesu aktualizacji firmware SFOS. Jeśli diagnostyka się nie powiedzie, zatrzymać kolejny etap; sekcja dotycząca wycofania aktualizacji nadal obowiązuje.

Przeanalizowane informacje o wydaniach wymieniają ZTNA 2.2 z 13 stycznia 2026 r. dla ESXi i Hyper-V, zarówno przy wdrożeniu lokalnym, jak i Sophos Cloud, oraz określają aktualizację jako obowiązkową z powodu nowych wymaganych funkcji. Mimo to przed oknem serwisowym zawsze sprawdź wersję docelową oferowaną w Sophos Fusion oraz aktualne informacje o wydaniach; nie wyciągaj z tej historycznej informacji o wersji wniosków o dacie końca wsparcia ani o obecnej wersji docelowej.

Historia wydań wymienia także konfigurowalny limit bezczynności tuneli agent–brama oraz wyłączenie Resource Connection Pooling od wersji 2.1.2. Dla wersji 2.2 dokumentuje poprawki sporadycznych problemów z połączeniem zasobów z agentem przez bramę lokalną, stanu Updating utrzymującego się po aktualizacji obrazu, mylących komunikatów diagnostycznych o podach klastra oraz warunku wyścigu dotyczącego podów Kubernetes. Używaj tej historii do oceny zmian i usterek, a nie zamiast aktualnego widoku szczegółów bramy.

Osobna weryfikacja problemów AD/Kerberos po aktualizacji bramy

Stwierdzenie, że aktualizacja bramy nie wymaga aktualizacji agenta, opisuje wymaganie dotyczące uaktualnienia. Nie potwierdza, że rozwiązuje ona każdy błąd po stronie agenta. W NZT-10022 Sophos wskazuje dla bram 2.2 i 2.3 sporadyczne straty większych pakietów AD, które mogą wpływać między innymi na RDP, udziały plikowe i Kerberos.

Dlatego po aktualizacji należy w ograniczonym pilotażu Windows sprawdzić również odpowiednie aplikacje zależne od AD i udokumentować wersję agenta/bramy, czas oraz odtwarzalne objawy. Na 24 października 2026 lista Known Issues wskazuje jako poprawkę dopiero nadchodzący Windows Endpoint Agent 2026.3. Ta zapowiedź nie potwierdza, że odpowiednia poprawka ZTNA została już wdrożona we własnym kanale aktualizacji. Przed wdrożeniem agenta należy sprawdzić konkretne wydanie i przypisanie poprawki; samego uaktualnienia bramy do 2.3.0 nie należy obiecywać jako rozwiązania. Jeśli objawy pozostają, przekazać dowody do Sophos Support i uzgodnić tymczasowe obejście dla danego przypadku.

Regularny przegląd

Sprawdzaj co najmniej zgodnie z własnym cyklem serwisowym:

• stan bramy i węzłów oraz wersję zainstalowaną i oferowaną;
• ważność certyfikatu i pełny łańcuch;
• publiczne rekordy CNAME służące do walidacji domen, bramy i zasobów;
• prywatne rozwiązywanie nazw DNS oraz tylko nadal potrzebne trasy i reguły DNAT, SNAT i zapory;
• region PoP, dodatkowy PoP i rzeczywiste opóźnienia dla Cloud Gateway;
• zsynchronizowane grupy użytkowników z włączonymi zabezpieczeniami oraz dostawcę tożsamości;
• przypisania zasobów do bram i bramy, które nie są już potrzebne;
• procedury diagnostyki i pomocy technicznej, okna serwisowe oraz osoby odpowiedzialne.

Nie podano tu wiarygodnej daty przejścia, migracji ani EOL na potrzeby planowania bram. Przed zastąpieniem bramy należy sprawdzić takie terminy w aktualnym komunikacie produktowym.

Powiązane istniejące instrukcje

Ta instrukcja celowo kończy się na granicach odpowiedzialności za bramę. Pełna konfiguracja usługi katalogowej i dostawcy tożsamości, instalowanie lub usuwanie agenta ZTNA, diagnostyka problemów specyficznych dla agenta, reguły dostępu do zasobów oraz szczególne projekty z wieloma kontrolerami domeny należą do odpowiednich istniejących instrukcji. Podlinkowane wyżej podstawy Zero Trust, dostępu zdalnego, certyfikatów, DNAT i diagnostyki zapory uzupełniają procedurę dotyczącą bramy bez powielania tych odrębnych procesów.