Sophos ZTNA Agent: systematyczne rozwiązywanie problemów

Cel i najkrótsza odpowiedź

Brak dostępu do zasobu ZTNA nie oznacza automatycznie awarii agenta. Instalacja, zasada, grupa użytkowników, DNS, dostawca tożsamości, brama i aplikacja wewnętrzna tworzą jeden łańcuch zależności. Dlatego diagnostykę należy rozpocząć od widocznego objawu i zmieniać wyłącznie ten element, którego dotyczą zebrane dowody.

Najkrótsza wiarygodna procedura diagnostyczna:

Zapisz użytkownika, urządzenie i zasób, których dotyczy problem, oraz czas jego wystąpienia.
Sprawdź instalację i lokalny stan agenta.
W obszarze My Products > ZTNA (pełna ścieżka: Sophos Central > My Products > ZTNA) porównaj konfigurację zasobu, metodę dostępu i zasadę.
W obszarze ZTNA > Reports (pełna ścieżka: Sophos Central > My Products > ZTNA > Reports) odszukaj udane uwierzytelnienie albo przyczynę odmowy dostępu.
W obszarze My Environment > Alerts (pełna ścieżka: Sophos Central > Alerts) odszukaj dotyczące urządzenia zdarzenie instalacji, aktualizacji, licencjonowania lub łączności z czasu wystąpienia problemu.
Zależnie od ustalonego objawu sprawdź DNS, tożsamość, stan zabezpieczeń urządzenia albo bramę.

Pomyślne otwarcie strony w przeglądarce nie dowodzi, że ruch przebiegał przez agenta. Z kolei portal użytkownika ZTNA pokazuje tylko aplikacje dostępne bez agenta, dlatego zasób korzystający z agenta nie musi być w nim widoczny.

Wymagania, licencje i role

Do przeprowadzenia diagnostyki potrzebne są: użytkownik i zarządzane urządzenie, których dotyczy problem, nazwa FQDN niedostępnego zasobu oraz dostęp do konfiguracji ZTNA, raportów, widoku urządzenia i alertów we właściwej dzierżawie. Podczas testowania zasobu korzystającego z agenta komponent ZTNA musi być przypisany do urządzenia. W obszarze Devices > Computers lub Servers zielony znacznik wskazuje zainstalowany komponent ZTNA, a znak plus oznacza, że można go zainstalować.

Na potrzeby tej procedury nie określono odrębnej nazwy licencji ani konkretnej roli administratora. Sama widoczność menu nie świadczy o szerszych uprawnieniach. Jeśli wymagany widok lub działanie jest niedostępne, skontaktuj się z administratorem dzierżawy, zamiast zakładać, że przyczyną jest licencja lub rola.

Przed wprowadzeniem jakiejkolwiek zmiany zapisz dla jednego konkretnego użytkownika i urządzenia:

system operacyjny, używaną sieć oraz czas wraz ze strefą czasową,
nazwę FQDN zasobu i metodę dostępu: Agent lub Agentless,
dokładne brzmienie lokalnego stanu ZTNA i komunikatu w przeglądarce,
czy inne zasoby ZTNA działają na tym samym urządzeniu,
czy ten sam użytkownik może uzyskać dostęp do tego zasobu z innej sieci,
ostatnią zmianę dotyczącą zasady, grupy, DNS, dostawcy tożsamości lub bramy.

Konfiguracja z przykładowymi wartościami do zastąpienia

Na potrzeby ograniczonego testu nie wprowadzaj zbiorczych zmian w ustawieniach produkcyjnych. Zastąp wartości przykładowe, takie jak <USER>, <DEVICE>, <RESOURCE-FQDN> i <TEST TIME WITH TIME ZONE>, danymi z jednego konkretnego przypadku.

W obszarze ZTNA > Reports otwórz kartę Report Generator. Aby sprawdzić odmowę dostępu, wybierz szablon Denied resource access, ustaw krótki przedział obejmujący <TEST TIME WITH TIME ZONE> i — jeśli umożliwiają to dostępne kolumny — przefiltruj wyniki według <USER>, <DEVICE> lub <RESOURCE-FQDN>. W filtrach z operatorami = i != wielkość liter ma znaczenie. Operator ~ nie rozróżnia wielkości liter i używa znaku * jako symbolu wieloznacznego. Wynik musi spełniać wszystkie zastosowane filtry. Następnie uruchom raport przyciskiem Create.

Jeśli oczekujesz udanego logowania, użyj szablonu Authenticated users. Raport ten obejmuje użytkowników pomyślnie uwierzytelnionych przez bramy ZTNA niezależnie od trybu wdrożenia bramy. Szablony Gateway bandwidth i Resource bandwidth służą do przypisywania ruchu i same w sobie nie potwierdzają powodzenia konkretnej próby dostępu.

W obszarze My Environment > Alerts ogranicz zakres czasu i urządzeń tak, aby odpowiadał testowi. Jeden alert może grupować kilka powtarzających się zdarzeń. Otwórz alert, klikając jego tytuł, aby wyświetlić powiązane zdarzenia i pełne szczegóły. Podczas analizy nie zamykaj alertu tylko po to, aby usunąć go z listy.

Weryfikacja i oczekiwany wynik

Test można uznać za zakończony powodzeniem dopiero wtedy, gdy wszystkie poniższe wyniki są ze sobą zgodne:

Agent wskazuje stan oczekiwany dla testowanej ścieżki.
Zasób <RESOURCE-FQDN> otwiera się przy użyciu wybranego konta użytkownika, urządzenia i sieci.
Raport Authenticated users zawiera udane uwierzytelnienie z wybranego przedziału czasu.
Raport Denied resource access nie zawiera nowej odmowy dotyczącej tej samej próby.
W obszarze My Environment > Alerts nie ma otwartego alertu dotyczącego instalacji, aktualizacji, licencjonowania lub łączności, który odpowiada czasowi testu i podważa jego wynik.

Jeśli w raporcie brakuje oczekiwanego wpisu, sprawdź przedział czasu i pisownię wartości filtrów, a następnie powtórz test jeden raz, zmieniając tylko jedną zmienną. Jeśli zamiast tego pojawi się odmowa, jej przyczyna wskaże odpowiednią procedurę w następnej sekcji. Jeśli również drugi test nie utworzy przydatnego wpisu, nie próbuj wymusić powodzenia kolejnymi zmianami konfiguracji. Zachowaj dzienniki i archiwum SDU do eskalacji.

Rozwiązywanie problemów według objawu

Stan „Not Configured”

W obszarze Devices > Computers lub Servers sprawdź, czy na urządzeniu zainstalowano ZTNA. Zielony znacznik potwierdza instalację komponentu, a znak plus umożliwia jego zainstalowanie. Sama obecność programu Sophos Endpoint nie dowodzi, że do urządzenia przypisano ZTNA.

W systemie Windows istnieje ważny wyjątek. Jeżeli w obszarze Global Settings > Products and Services > ZTNA skonfigurowano opcję Don’t intercept on-premises traffic, agent Windows po wykryciu sieci wewnętrznej celowo przestaje przechwytywać ruch i wyświetla stan Not Configured. Po połączeniu z inną siecią oczekiwany jest ponownie stan Configured. Według Sophos funkcja ta jest obecnie dostępna tylko w systemie Windows; nie należy zakładać, że działa tak samo w systemie macOS.

To zachowanie w systemie Windows wymaga wersji Sophos Core Agent 2025.2.1.709 lub nowszej. Przed diagnozowaniem wykrywania sieci lokalnej otwórz urządzenie w Sophos Fusion (dawniej Sophos Central) i na karcie Summary sprawdź zainstalowaną wersję programu Core Agent. Starsze wersje nie obsługują opisanego wyjątku.

Jeśli wyjątek nie ma zastosowania, sprawdź w Sophos Fusion przypisanie komponentów, stan połączenia urządzenia i stan aktualizacji. Nie rozpoczynaj od ponownej instalacji, dopóki nie ustalisz, czy komponent ZTNA został w ogóle przypisany.

Stan „Zero Trust Network Access: Error”

Ten stan wskazuje na problem z połączeniem. Sprawdź kolejno:

Czy istnieje zasada ZTNA i czy przypisano ją do zasobu?
Czy urządzenie prawidłowo rozpoznaje nazwę FQDN bramy?
Czy Sophos Fusion wskazuje błąd instalacji lub stanu zabezpieczeń urządzenia?
Czy w systemie Windows istnieje konfiguracja Sophos TAP i czy nie została zmieniona przez inne oprogramowanie sieciowe?

Sophos wymienia wyłączenie protokołu IPv6 jako jeden z kroków diagnostycznych. Nie jest to rozwiązanie docelowe: wykonaj ten krok tylko na jednym urządzeniu pilotażowym, po zapisaniu stanu początkowego, i wyłącznie na czas jednej próby odtworzenia problemu. Po teście ponownie włącz IPv6. Jeśli objaw zmieni się w sposób jednoznaczny, zachowaj znaczniki czasu i archiwum SDU, a następnie skontaktuj się z pomocą techniczną Sophos. Nie pozostawiaj IPv6 wyłączonego na stałe ani na wielu urządzeniach.

Tunel może zostać zamknięty z powodu bezczynności. Zależnie od ustawienia centralnego następuje to po 5, 15 lub 30 minutach albo po godzinie; wartość domyślna wynosi 5 minut. Nowy ruch powoduje ponowne zestawienie tunelu. Sam fakt zamknięcia bezczynnego tunelu nie świadczy więc o usterce.

Okno logowania nie pojawia się

W przypadku zasobu korzystającego z agenta sprawdź kolejno:

Czy urządzenie może połączyć się z bramą ZTNA?
Czy proces agenta ZTNA jest uruchomiony?
Czy dla nazwy FQDN aplikacji błędnie utworzono publiczny lub wewnętrzny rekord CNAME wskazujący bramę? Taki rekord nie może istnieć dla aplikacji korzystających z agenta.
Czy zasób, metoda dostępu i nazwa FQDN są zgodne w Sophos Fusion?
Czy w czasie testu dzienniki ZTNA zawierają błąd SNTP, DNS lub połączenia?

Jeśli pojawia się ekran logowania, ale po uwierzytelnieniu użytkownik nie wraca do aplikacji, sprawdź identyfikator URI przekierowania u dostawcy tożsamości. W usłudze Okta wielkość liter ma znaczenie również w polu Groups claim expression. Pliki cookie lub dane logowania w przeglądarce resetuj dopiero po potwierdzeniu, że problem występuje na etapie uwierzytelniania.

Uwierzytelniony zasób korzystający z agenta nie działa lub przestał działać

Jeżeli uwierzytelnienie przebiega pomyślnie, ale aplikacja korzystająca z agenta się nie otwiera, sprawdź dzienniki SNTP punktu końcowego pod kątem błędów oraz upewnij się, że certyfikat zapisany w pliku heartbeat.xml jest obecnie ważny. Nieprawidłowy czas urządzenia, błąd synchronizacji czasu albo certyfikat, który wygasł lub nie jest jeszcze ważny, mogą przerwać uwierzytelnioną ścieżkę agenta, nawet jeśli zasada i DNS wydają się skonfigurowane prawidłowo. Zachowaj dzienniki, plik i znacznik czasu. Nie edytuj pliku XML ani nie wyłączaj weryfikacji certyfikatu.

Jeśli dostęp wcześniej działał, a następnie przestał, wykonaj te same kontrole dzienników SNTP i ważności certyfikatu w pliku heartbeat.xml, po czym sprawdź urządzenie w Sophos Fusion. Czerwony stan Endpoint health jest istotną wskazówką diagnostyczną: usuń wskazaną przyczynę nieprawidłowego stanu i ponów test, zamiast łagodzić zasadę ZTNA.

„403 Access Denied / No Access”, „Device Health” lub „Policy Off”

Raport Denied resource access pozwala ustalić następny krok:

403 Access Denied / No Access: użytkownik nie należy skutecznie do grupy przypisanej do zasobu albo dla tej grupy nie włączono zabezpieczeń w Microsoft Entra ID. Sprawdź poprawność importu grupy, czy grupa ma włączone zabezpieczenia (security-enabled), oraz uprawnienia interfejsu API dostawcy tożsamości. Zastosowanie zmian na liście dozwolonych grup może potrwać do godziny.
Device Health: urządzenie nie spełnia wymagań dotyczących stanu zabezpieczeń określonych w przypisanej zasadzie agenta. Usuń konkretną przyczynę nieprawidłowego stanu zamiast ogólnie łagodzić zasadę.
Policy Off: otwórz odpowiednią zasadę w obszarze My Products > ZTNA > Policies i sprawdź ustawienie Policy is enforced.
Upstream request error for Agentless: brama nie może połączyć się z aplikacją wewnętrzną, aplikacja jest niedostępna, jej nazwa FQDN lub adres IP są nieprawidłowo rozpoznawane albo skonfigurowano niewłaściwy port. Nie świadczy to o awarii agenta na urządzeniu końcowym.
404 Not Found for Agentless: sprawdź rekord CNAME aplikacji wskazujący nazwę FQDN bramy. Nie stosuj tej reguły DNS do zasobów korzystających z agenta.

Jeśli użytkownik został właśnie dodany do grupy, ponów test dopiero po upływie udokumentowanego czasu replikacji. Prywatne okno przeglądarki pozwala wykluczyć nieaktualne dane przeglądarki w przypadku aplikacji internetowej, ale nie przyspiesza replikacji grup.

Problemy z DNS po instalacji

Adapter ZTNA TAP może stać się domyślnym interfejsem dla polecenia nslookup. Zapytanie dotyczące hosta poza bramą ZTNA może wtedy zakończyć się niepowodzeniem, mimo że rozpoznawanie nazw zasadniczo działa. W celu porównania Sophos zaleca jawne wskazanie właściwego serwera DNS:

nslookup <FQDN> <DNS-SERVER>

Porównaj odpowiedź otrzymaną z oczekiwanego firmowego serwera DNS, a następnie wykonaj rzeczywistą próbę otwarcia aplikacji. Nie zmieniaj kolejności adapterów, metryk ani adresów serwerów DNS bez potwierdzonej przyczyny. W przypadku zasobów korzystających z agenta upewnij się również, że dla aplikacji nie istnieje rekord CNAME wskazujący bramę.

Sophos DNS Protection korzysta z osobnej ścieżki danych. Jeśli ta funkcja jest również używana, zapoznaj się z zasadami i wyjątkami w artykule Konfigurowanie Sophos DNS Protection dla punktów końcowych. Nie traktuj obsługi DNS przez ZTNA i funkcji Endpoint DNS Protection jako tej samej funkcji.

ZTNA razem z siecią VPN lub oprogramowaniem dostępu zdalnego

Nie usuwaj profilaktycznie adapterów TAP, nie zmieniaj powiązań i nie ustawiaj na stałe metryk sieciowych. Najpierw przeprowadź kontrolowaną próbę dostępu do tego samego zasobu z drugim klientem i bez niego, zapisując czas, odpowiedź DNS i stan ZTNA.

W przypadku ZTNA 2026.1 używanego razem z Sophos DNS Protection firma Sophos opisuje jeden konkretny sposób zapewnienia współdziałania: włącz DNS Protection, a następnie w odpowiedniej zasadzie punktu końcowego włącz opcję Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN. Wymaga to odpowiedniej wersji, licencji i konfiguracji DNS Protection; nie jest to uniwersalne rozwiązanie problemów z dowolnym oprogramowaniem VPN.

Ściśle określone przypadki w systemie macOS

W systemie macOS Sequoia po nowej instalacji obejmującej wyłącznie ZTNA przeglądarka Chrome może blokować aplikacje za on-premises gateway, jeśli nie ma dostępu do sieci lokalnej. Tylko w przypadku tego konkretnego objawu sprawdź w obszarze System Settings > Privacy & Security > Local Network, czy Google Chrome może wyszukiwać urządzenia lokalne. Opisany problem nie dotyczy Sophos Cloud Gateway. Nie wynika z tego ani ogólne zalecenie przyznania uprawnienia, ani gwarancja „prywatnego dostępu” w systemie macOS.

Wysokie użycie procesora po wdrożeniu za pomocą rozwiązania MDM może być spowodowane wieloma profilami VPN, których nazwy zaczynają się od Sophos ZTNA. Sprawdź w obszarze System Settings > VPN, czy istnieją duplikaty. Pozostaw dokładnie jeden profil. Profilu zainstalowanego przez rozwiązanie MDM nie można usunąć lokalnie, dlatego to właśnie on musi pozostać. Uruchom ponownie komputer Mac, a następnie ponownie sprawdź użycie procesora i dostęp przez ZTNA. Ta procedura porządkowania dotyczy wyłącznie potwierdzonego przypadku w systemie macOS, a nie adapterów TAP w systemie Windows.

Jeśli udało się jednoznacznie odtworzyć problem z nieaktualnymi danymi logowania, udokumentowane przez Sophos procedury resetowania można stosować wyłącznie podczas diagnostyki lub demonstracji, a nie jako standardowy sposób wylogowywania użytkowników w środowisku produkcyjnym. W systemie macOS narzędzie diagnostyczne Endpoint zawiera opcję ZTNA > Reset. Skrypty usuwające pliki cookie przeglądarki lub ręczne usuwanie danych witryn w Safari muszą dotyczyć dokładnie używanej bramy i dostawcy tożsamości. W systemie Windows procedura Sophos wymaga wyłączenia ochrony przed naruszeniem i uruchomienia z podwyższonymi uprawnieniami pliku clearcreds.bat dołączonego do artykułu bazy wiedzy. Nie używaj skryptów porządkujących innych firm ani samodzielnie opracowanych procedur ręcznego usuwania danych. Oryginalne pliki i ograniczenia opisano w artykule Sophos ZTNA: Wyloguj się z agenta.

Bezpieczne wycofanie zmian lub usunięcie rozwiązania

Ta procedura diagnostyczna i raportowa nie obejmuje ogólnej naprawy, odinstalowywania ani wycofywania agenta. Dlatego obowiązują następujące bezpieczne zasady przerwania pracy:

Filtry testowe i narzędzie Report Generator nie zmieniają ścieżki danych. Szablon lub harmonogram zapisany wyłącznie na potrzeby diagnostyki można usunąć w obszarze Saved templates lub Scheduled exports.
Po teście porównawczym z wyłączonym IPv6 natychmiast przywróć udokumentowany stan początkowy.
Nie pozostawiaj tymczasowo złagodzonej zasady, zmienionego przypisania do grupy, zmienionej konfiguracji DNS ani wyłączonej weryfikacji certyfikatu jako rozwiązania problemu. Jeżeli taką zmianę wprowadzono poza tą procedurą, przywróć wcześniej udokumentowany stan i powtórz ten sam test.
Nie usuwaj agenta ani adapterów TAP i nie wyłączaj weryfikacji certyfikatu, dopóki nie ustalisz miejsca występowania usterki. Jeśli nie istnieje udokumentowany sposób wycofania zmiany, przerwij pracę i przekaż sprawę do wyższego poziomu pomocy wraz z zachowanymi dowodami.

Po każdym wycofaniu zmiany stan agenta, odpowiedź DNS, rzeczywista próba dostępu do zasobu i odpowiedni raport ZTNA muszą ponownie odpowiadać stanowi początkowemu. Jeśli tak nie jest, nie wprowadzaj kolejnej zmiany.

Eksploatacja, przeglądy i cykl życia

Raporty i alerty ZTNA stanowią materiał diagnostyczny, a nie działania naprawcze. Na potrzeby cyklicznych przeglądów można zapisać szablon raportu z filtrami lub zaplanować eksport. Zaplanowane raporty mogą być generowane codziennie, co tydzień lub co miesiąc w formacie PDF, CSV albo HTML. Sophos Central obsługuje maksymalnie 200 harmonogramów. Eksporty utworzone ręcznie lub automatycznie są usuwane po 90 dniach. Jeśli raport zawiera dane osobowe, wybierz łącze w wiadomości e-mail zamiast załącznika, ponieważ otwarcie łącza wymaga zalogowania się do Sophos Central.

Alerty zawierają informacje o ważności, stanie, zdarzeniach i urządzeniu. Powtarzające się zdarzenia mogą zostać połączone w jeden alert, a późniejsze zdarzenie może automatycznie zamknąć go ze stanem Resolved. Dlatego podczas incydentu zawsze sprawdzaj zawarte w alercie zdarzenia i ich znaczniki czasu. Opcja Mark as acknowledged usuwa alert z listy, ale nie usuwa jego przyczyny. Opcja Mark as resolved również nie zastępuje usunięcia usterki.

Przed ponowną instalacją, usuwaniem profili lub wprowadzaniem kolejnych zmian w sieci zbierz:

informacje o urządzeniu, użytkowniku, systemie operacyjnym i faktycznie zainstalowanych komponentach,
informacje o zasobie, metodzie dostępu, zasadzie i przypisanej grupie,
dokładne brzmienie komunikatu, lokalny stan ZTNA oraz znacznik czasu ze strefą czasową,
wynik próby z innym użytkownikiem, urządzeniem lub siecią, za każdym razem ze zmianą tylko jednej zmiennej,
odpowiedzi DNS dla nazw FQDN zasobu i bramy,
odpowiednie zdarzenia z Sophos Central oraz dzienniki ZTNA, SNTP i instalacji,
raport ZTNA z filtrami lub eksport obejmujący czas testu,
aktualne archiwum SDU.

Pierwszeństwo mają aktualne wersje dokumentacji i komponentów. Na podstawie tej procedury nie należy wyciągać wniosków dotyczących wcześniejszych zmian w ZTNA, cofnięcia dawnych uprawnień, terminów migracji, wycofania produktu ani dokładnych dat zakończenia jego obsługi.

Powiązane przewodniki

Opis architektury i zależności znajduje się w artykule Konfiguracja Sophos ZTNA: przegląd i kolejność działań. Niniejszy artykuł dotyczy stanu agenta i dowodów związanych z połączeniem; wdrażanie bramy i ogólna procedura naprawy agenta wykraczają poza jego zakres.

W artykule Sophos Endpoint: diagnostyka za pomocą SDU opisano bezpieczne zbieranie danych. Następnie otwórz zgłoszenie do pomocy technicznej Sophos i dołącz zachowane dowody. Nie kopiuj do zgłoszeń ani niezabezpieczonych załączników danych logowania, tokenów ani plików cookie przeglądarki.