Monitorowanie Microsoft Tunnel

  • Artykuł

Po zainstalowaniu aplikacji Microsoft Tunnel można wyświetlić konfigurację serwera i kondycję serwera w centrum administracyjnym Microsoft Intune.

Korzystanie z interfejsu użytkownika centrum administracyjnego

Zaloguj się do centrum administracyjnego Microsoft Intune i przejdź do pozycji Administracja dzierżawą Stan kondycji>usługi Microsoft Tunnel Gateway>.

Następnie wybierz serwer, a następnie otwórz kartę Sprawdzanie kondycji , aby wyświetlić metryki stanu kondycji serwerów. Domyślnie każda metryka używa wstępnie zdefiniowanych wartości progowych, które określają stan. Następujące metryki obsługują dostosowywanie tych progów:

  • Użycie procesora CPU
  • Użycie pamięci
  • Użycie miejsca na dysku
  • Opóźnienie

Wartości domyślne metryk kondycji serwera:

  • Ostatnie zaewidencjonowanie — kiedy serwer bramy tunelu ostatnio zaewidencjonował usługę Intune.

    • Zdrowe — ostatnie zaewidencjonowynie miało miejsce w ciągu ostatnich pięciu minut.
    • Zła kondycja — ostatnie zaewidencjonowynie miało miejsce ponad pięć minut temu.

  • Bieżące połączenia — liczba unikatowych połączeń, które były aktywne podczas ostatniego zaewidencjonowania serwera.

    • W dobrej kondycji — było 4990 lub mniej połączeń
    • W złej kondycji — było ponad 4990 aktywnych połączeń

  • Przepływność — bity megabitów na sekundę ruchu przechodzącego przez kartę sieciową bramy tunelu podczas ostatniego zaewidencjonowania serwera.

  • Użycie procesora CPU — średnie użycie procesora CPU przez serwer bramy tunelu co pięć minut.

    • W dobrej kondycji — 95% lub mniej
    • Ostrzeżenie — od 96% do 99%
    • W złej kondycji — 100% użycia

  • Rdzenie procesora CPU — liczba rdzeni procesora CPU dostępnych na tym serwerze.

    • W dobrej kondycji — co najmniej 4 rdzenie
    • Ostrzeżenie — 1, 2 lub 3 rdzenie
    • Rdzenie w złej kondycji -0

  • Użycie pamięci — średnie użycie pamięci przez serwer bramy tunelu co 5 minut.

    • W dobrej kondycji — 95% lub mniej
    • Ostrzeżenie — od 96% do 99%
    • W złej kondycji — 100% użycia

  • Użycie miejsca na dysku — ilość miejsca na dysku używanego przez serwer bramy tunelu.

    • W dobrej kondycji — powyżej 5 GB
    • Ostrzeżenie — 3–5 GB
    • Zła kondycja — poniżej 3 GB

  • Opóźnienie — średni czas potrzebny na odebranie pakietów IP, a następnie wyjście z interfejsu sieciowego.

    • W dobrej kondycji — mniej niż 10 milisekund
    • Ostrzeżenie — od 10 milisekund do 20 milisekund
    • Zła kondycja — ponad 20 milisekund

  • Certyfikat agenta zarządzania — certyfikat agenta zarządzania jest używany przez usługę Tunnel Gateway do uwierzytelniania w usłudze Intune, dlatego należy go odnowić przed wygaśnięciem. Należy jednak automatycznie odnowić się.

    • W dobrej kondycji — wygaśnięcie certyfikatu trwa dłużej niż 30 dni.
    • Ostrzeżenie — wygaśnięcie certyfikatu jest krótsze niż 30 dni.
    • Zła kondycja — certyfikat wygasł.

  • Certyfikat TLS — liczba dni do wygaśnięcia certyfikatu TLS (Transport Layer Security), który zabezpiecza ruch między klientami a serwerem bramy tunelu.

    • W dobrej kondycji — ponad 30 dni
    • Ostrzeżenie — 30 dni lub mniej
    • Zła kondycja — certyfikat wygasł

  • Odwołanie certyfikatu protokołu TLS — brama tunelu próbuje sprawdzić stan odwołania certyfikatu TLS (Transport Layer Security) przy użyciu protokołu OCSP (Online Certificate Status Protocol) lub adresu listy odwołania certyfikatów (CRL) zgodnie z definicją certyfikatu protokołu TLS. To sprawdzenie wymaga, aby serwer miał dostęp do punktu końcowego OCSP lub adresu CRL zgodnie z definicją w certyfikacie.

    • W dobrej kondycji — certyfikat TLS nie został odwołany.
    • Ostrzeżenie — nie można sprawdzić, czy certyfikat protokołu TLS został odwołany. Upewnij się, że dostęp do punktów końcowych zdefiniowanych w certyfikacie można uzyskać z serwera tunnel.
    • W złej kondycji — certyfikat protokołu TLS jest odwoływany.

    Zaplanuj zastąpienie odwołanego certyfikatu protokołu TLS.

    Aby dowiedzieć się więcej na temat protokołu OCSP (Online Certificate Status Protocol), zobacz Protokół stanu certyfikatu online w wikipedia.org.

  • Ułatwienia dostępu do sieci wewnętrznej — stan z ostatniego sprawdzenia wewnętrznego adresu URL. Adres URL można skonfigurować w ramach konfiguracji lokacji tunelu.

    • W dobrej kondycji — serwer może uzyskać dostęp do adresu URL określonego we właściwościach witryny.
    • Zła kondycja — serwer nie może uzyskać dostępu do adresu URL określonego we właściwościach witryny.
    • Nieznany — ten stan jest wyświetlany, gdy nie ustawiono adresu URL we właściwościach witryny. Ten stan nie ma wpływu na ogólny stan witryny.

  • Możliwość uaktualnienia — możliwość skontaktowania się z repozytorium kontenerów firmy Microsoft przez serwer, co umożliwia uaktualnienie bramy tunnel gateway, gdy wersje staną się dostępne.

    • W dobrej kondycji — serwer nie skontaktował się z repozytorium kontenerów firmy Microsoft w ciągu ostatnich 5 minut.
    • Zła kondycja — serwer nie skontaktował się z repozytorium kontenerów firmy Microsoft przez ponad 5 minut.

  • Wersja serwera — stan oprogramowania tunnel gateway server w odniesieniu do najnowszej wersji.

    • W dobrej kondycji — aktualne informacje o najnowszej wersji oprogramowania
    • Ostrzeżenie — jedna wersja za
    • Zła kondycja — co najmniej dwie wersje z tyłu i brak pomocy technicznej

    Jeśli wersja serwera nie jest w dobrej kondycji, zaplanuj instalację uaktualnień dla aplikacji Microsoft Tunnel.

  • Kontener serwera — określa, czy kontener hostujący serwer Microsoft Tunnel jest uruchomiony.

    • W dobrej kondycji — stan kontenera serwera jest w dobrej kondycji.
    • W złej kondycji — stan kontenera serwera nie jest w dobrej kondycji.

  • Konfiguracja serwera — określa, czy konfiguracja serwera została pomyślnie zastosowana do serwera tunnel z Microsoft Intune ustawień lokacji.

    • W dobrej kondycji — konfiguracja serwera została pomyślnie zastosowana.
    • Zła kondycja — nie można zastosować konfiguracji serwera.

  • Dzienniki serwera — określa, czy dzienniki zostały przekazane do serwera w ciągu ostatnich 60 minut.

    • W dobrej kondycji — dzienniki serwera zostały przekazane w ciągu ostatnich 60 minut.
    • Zła kondycja — dzienniki serwera zostały przekazane w ciągu ostatnich 60 minut.

Zarządzanie progami stanu kondycji

Możesz dostosować następujące metryki stanu kondycji aplikacji Microsoft Tunnel, aby zmienić progi, których każdy używa do raportowania stanu. Dostosowania są dostępne dla całej dzierżawy i mają zastosowanie do wszystkich fragmentów tunelu. Metryki sprawdzania kondycji, które można dostosować, obejmują:

  • Użycie procesora CPU
  • Użycie pamięci
  • Użycie miejsca na dysku
  • Opóźnienie

Aby zmodyfikować wartość progu metryk:

Zrzut ekranu przedstawiający sposób wybierania i konfigurowania progów stanu kondycji.

  1. Zaloguj się do centrum administracyjnego Microsoft Intune i przejdź do obszaru Stankondycji usługiMicrosoft Tunnel Gateway>administracji> dzierżawczej.

  2. Wybierz pozycję Konfiguruj progi.

  3. Na stronie Skonfigurowane progi ustaw nowe progi dla każdej kategorii sprawdzania kondycji, którą chcesz dostosować.

    • Wartości progowe mają zastosowanie do wszystkich serwerów we wszystkich lokacjach.
    • Wybierz pozycję Przywróć domyślne , aby przywrócić wszystkie progi z powrotem do wartości domyślnych.

  4. Wybierz Zapisz.

  5. W okienku Stan kondycji wybierz pozycję Odśwież , aby zaktualizować stan wszystkich serwerów na podstawie dostosowanych wartości progowych.

Po zmodyfikowaniu progów wartości na karcie sprawdzania kondycji serwerów są automatycznie aktualizowane w celu odzwierciedlenia jego stanu na podstawie bieżących progów.

Zrzut ekranu przedstawiający widok sprawdzania kondycji serwerów.

Wyświetlanie trendów stanu kondycji metryk kondycji usługi Microsoft Tunnel Gateway w postaci wykresu. Dane dla wykresów są uśredniane w trzygodzinnym bloku i w związku z tym mogą być opóźnione do trzech godzin.

Wykresy trendu stanu kondycji są dostępne dla następujących metryk:

  • Connections
  • Użycie procesora CPU
  • Użycie miejsca na dysku
  • Użycie pamięci
  • Średnie opóźnienie
  • Przepustowość

Aby wyświetlić wykresy trendu:

  1. Zaloguj się do centrum administracyjnego Microsoft Intune.

  2. Przejdź do pozycji Stan kondycji> usługiMicrosoft Tunnel Gateway> administracja >dzierżawą Wybierz serwer, a następnie wybierz pozycję Trendy

  3. Użyj listy rozwijanej Metryka , aby wybrać wykres metryki, który chcesz wyświetlić.

Korzystanie z narzędzia wiersza polecenia mst-cli

Użyj narzędzia wiersza polecenia mst-cli , aby uzyskać informacje o serwerze Microsoft Tunnel. Ten plik jest dodawany do serwera z systemem Linux po zainstalowaniu programu Microsoft Tunnel. Narzędzie znajduje się pod adresem: /usr/sbin/mst-cli.

Aby uzyskać więcej informacji i przykłady wiersza polecenia, zobacz mst-cli command-line tool for Microsoft Tunnel (Narzędzie wiersza polecenia mst-cli dla rozwiązania Microsoft Tunnel).

Wyświetlanie dzienników tunelu firmy Microsoft

Program Microsoft Tunnel rejestruje informacje w dziennikach serwera systemu Linux w formacie dziennika systemowego . Aby wyświetlić wpisy dziennika, użyj polecenia journalctl -t , po którym następuje co najmniej jeden tag specyficzny dla wpisów microsoft tunnel:

  • mstunnel-agent: wyświetlanie dzienników agenta.

  • mstunnel_monitor: wyświetlanie dzienników zadań monitorowania.

  • ocserv — wyświetlanie dzienników serwera.

  • ocserv-access — wyświetlanie dzienników dostępu.

    Domyślnie rejestrowanie dostępu jest wyłączone. Włączenie dzienników dostępu może zmniejszyć wydajność w zależności od liczby aktywnych połączeń i wzorców użycia na serwerze. Rejestrowanie połączeń DNS zwiększa pełność dzienników, co może stać się hałaśliwe.

    Dzienniki dostępu mają następujący format: <Server timestamp><Server Name><ProcessID on Server><userId><deviceId><protocol><src IP and port><dst IP and port><bytes sent><bytes received><connection time in seconds> na przykład:

    • Luty 25 16:37:56 MSTunnelTest-VM ocserv-access[9528]: ACCESS_LOG,41150dc4-238x-4dwv-9q89-55e987f30c32,f5132455-ef2dd-225a-a693-afbbqed482dce,tcp,169.254.54.149:49462,10.88.0.5:80,112,60,10

    Ważna

    W programie ocserv-access wartość deviceId identyfikuje unikatowe wystąpienie instalacji Microsoft Defender uruchomione na urządzeniu i nie identyfikuje identyfikatora urządzenia usługi Intune ani identyfikatora urządzenia Microsoft Entra. Jeśli usługa Defender zostanie odinstalowana, a następnie ponownie zainstalowana na urządzeniu, zostanie wygenerowane nowe wystąpienie identyfikatora DeviceId*.

    Aby włączyć rejestrowanie dostępu:

    1. ustaw wartość TRACE_SESSIONS=1 w /etc/mstunnel/env.sh
    2. ustaw wartość TRACE_SESSIONS=2, aby uwzględnić rejestrowanie połączeń DNS
    3. Uruchom polecenie mst-cli server restart , aby ponownie uruchomić serwer.

    Jeśli dzienniki dostępu są zbyt hałaśliwe, możesz wyłączyć rejestrowanie połączeń DNS, ustawiając wartość TRACE_SESSIONS=1 i ponownie uruchamiając serwer.

  • OCSERV_TELEMETRY — wyświetlanie szczegółów telemetrii dla połączeń z usługą Tunnel.

    Dzienniki telemetrii mają następujący format: wartości dla bytes_in, bytes_out i czasu trwania są używane tylko w przypadku operacji rozłączania: <operation><client_ip><server_ip><gateway_ip><assigned_ip><user_id><device_id><user_agent><bytes_in><bytes_out><duration> Na przykład:

    • 20 października 19:32:15 mstunnel ocserv[4806]: OCSERV_TELEMETRY,connect,31258,73.20.85.75,172.17.0.3,3 169.254.0.1,169.254.107.209,3780e1fc-3ac2-4268-a1fd-dd910ca8c13c, 5A683ECC-D909-4E5F-9C67-C0F595A4A70E,MobileAccess iOS 1.1.34040102

    Ważna

    W OCSERV_TELEMETRY wartość deviceId identyfikuje unikatowe wystąpienie instalacji Microsoft Defender uruchomione na urządzeniu i nie identyfikuje identyfikatora urządzenia usługi Intune ani identyfikatora urządzenia Microsoft Entra. Jeśli usługa Defender zostanie odinstalowana, a następnie ponownie zainstalowana na urządzeniu, zostanie wygenerowane nowe wystąpienie identyfikatora DeviceId*.

Przykłady wiersza polecenia dla journalctl:

  • Aby wyświetlić informacje tylko dla serwera tunelu, uruchom polecenie journalctl -t ocserv.
  • Aby wyświetlić dziennik telemetrii, uruchom polecenie journalctl -t ocserv | grep TELEMETRY
  • Aby wyświetlić informacje dotyczące wszystkich opcji dziennika, można uruchomić polecenie journalctl -t ocserv -t ocserv-access -t mstunnel-agent -t mstunnel_monitor.
  • Dodaj -f do polecenia, aby wyświetlić aktywny i ciągły widok pliku dziennika. Aby na przykład aktywnie monitorować trwające procesy dla aplikacji Microsoft Tunnel, uruchom polecenie journalctl -t mstunnel_monitor -f.

Więcej opcji dla journalctl:

  • journalctl -h — Wyświetl pomoc polecenia dla journalctl.
  • man journalctl — Wyświetl dodatkowe informacje.
  • man journalctl.conf Wyświetl informacje na temat konfiguracji Aby uzyskać więcej informacji na temat narzędzia journalctl, zapoznaj się z dokumentacją używanej wersji systemu Linux.

Łatwe przekazywanie dzienników diagnostycznych dla serwerów tunelu

W ramach pomocy diagnostycznej można użyć jednego kliknięcia w centrum administracyjnym usługi Intune, aby usługa Intune mogła włączać, zbierać i przesyłać pełne dzienniki z serwera bramy tunelu bezpośrednio do firmy Microsoft. Te pełne dzienniki są następnie dostępne bezpośrednio dla firmy Microsoft podczas pracy z firmą Microsoft w celu identyfikowania lub rozwiązywania problemów z serwerem tunnel.

Przed otwarciem zdarzenia pomocy technicznej można zbierać i przekazywać pełne dzienniki z zdarzenia lub na żądanie, jeśli już pracujesz z firmą Microsoft w celu zbadania operacji serwerów tunnel.

Aby użyć tej funkcji:

  1. Otwórz centrum administracyjne Microsoft Intune przejdź do pozycji Administracja> dzierżawąUsługa Microsoft Tunnel Gateway> wybierz serwer>, a następnie wybierz kartę Dzienniki.

  2. Na karcie Dzienniki znajdź sekcję Wyślij pełne dzienniki serwera i wybierz pozycję Wyślij dzienniki.

Po wybraniu pozycji Wyślij dzienniki dla serwera tunnel rozpoczyna się następujący proces:

  • Najpierw usługa Intune przechwytuje bieżący zestaw dzienników serwera Tunnel i przekazuje je bezpośrednio do firmy Microsoft. Te dzienniki są zbierane przy użyciu bieżącego poziomu szczegółowości dzienników serwerów. Domyślnie poziom szczegółowości serwera wynosi zero (0).
  • Następnie usługa Intune włącza poziom szczegółowości wynoszący cztery (4) dla dzienników serwera tunnel. Ten szczegółowy poziom szczegółowości jest zbierany przez osiem godzin.
  • W ciągu ośmiu godzin pełnego zbierania dzienników należy odtworzyć problem lub badaną operację, aby przechwycić pełne szczegóły w dziennikach.
  • Po ośmiu godzinach usługa Intune zbiera drugi zestaw dzienników serwera zawierających pełne szczegóły i przekazuje je do firmy Microsoft. W momencie przekazywania usługa Intune resetuje również dzienniki serwera tunnel w celu użycia domyślnego poziomu szczegółowości wynoszącego zero (0). Jeśli wcześniej podniesiono poziom szczegółowości serwera, po zresetowaniu przez usługę Intune pełności do zera można przywrócić niestandardowy poziom szczegółowości.

Każdy zestaw dzienników zbieranych i przekazywanych przez usługę Intune jest identyfikowany jako oddzielny zestaw z następującymi szczegółami wyświetlanymi w centrum administracyjnym poniżej przycisku Wyślij dzienniki :

  • Godzina rozpoczęcia i zakończenia kolekcji dzienników
  • Po wygenerowaniu przekazywania
  • Dziennik ustawia poziom szczegółowości
  • Identyfikator zdarzenia, który może służyć do identyfikowania określonego zestawu dzienników

Zrzut ekranu przedstawiający interfejs Wyślij pełne dzienniki serwera.

Po przechwyceniu problemu podczas uruchamiania pełnej kolekcji dzienników możesz podać identyfikator zdarzenia tego dziennika ustawiony na firmę Microsoft, aby ułatwić badanie.

Informacje o kolekcji dzienników

  • Usługa Intune nie zatrzymuje ani nie uruchamia ponownie serwera tunnel, aby włączyć lub wyłączyć pełne rejestrowanie.
  • Nie można wcześniej przedłużyć ani zatrzymać okresu pełnego rejestrowania przez osiem godzin.
  • Aby przechwycić problem z pełne rejestrowanie, można użyć procesu wysyłania dzienników tak często, jak to konieczne. Jednak zwiększona pełność dziennika zwiększa obciążenie serwera tunnel i nie jest zalecana jako zwykła konfiguracja.
  • Po zakończeniu pełnego rejestrowania domyślny poziom szczegółowości zero jest ustawiany dla dzienników serwera tunnel, niezależnie od wcześniej ustawionych poziomów szczegółowości.
  • W tym procesie są zbierane następujące dzienniki:
    • mstunnel-agent (dzienniki agenta)
    • mstunnel_monitor (Dzienniki zadań monitorowania)
    • ocserv (dzienniki serwera)

Dzienniki dostępu ocserv nie są zbierane ani przekazywane.

Znane problemy

Poniżej przedstawiono znane problemy dotyczące rozwiązania Microsoft Tunnel.

Kondycja serwera

Klienci mogą pomyślnie używać tunelu, gdy stan kondycji serwera jest wyświetlany jako offline

Problem: Na karcie Stan kondycji tunelu stan kondycji serwera jest raportowany jako w trybie offline wskazujący, że jest odłączony, mimo że użytkownicy mogą nawiązać połączenie z serwerem tunelu i połączyć się z zasobami organizacji.

Rozwiązanie: Aby rozwiązać ten problem, należy ponownie zainstalować aplikację Microsoft Tunnel, która ponownie rejestruje agenta serwera Tunnel w usłudze Intune. Aby zapobiec temu problemowi, zainstaluj aktualizacje agenta i serwera tunnel wkrótce po ich wydaniu. Użyj metryk kondycji serwera Tunnel w centrum administracyjnym Microsoft Intune, aby monitorować kondycję serwera.

W usłudze Podman w dzienniku mstunnel_monitor zostanie wyświetlony komunikat "Błąd podczas wykonywania ewidencjonowania"

Problem: Narzędzie Podman nie może zidentyfikować lub wyświetlić aktywnych kontenerów, które są uruchomione, i zgłasza błąd podczas wykonywania ewidencjonowania w dzienniku mstunnel_monitor serwera Tunnel. Poniżej przedstawiono przykłady błędów:

  • Agenta:

    Error executing Checkup
Error details
\tscript: 561 /usr/sbin/mst-cli
\t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger)
\tstack:
\t\t<> Checkup /usr/sbin/mst-cli Message: NA
\t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-agent
\t\t<> main /usr/sbin/mstunnel_monitor Message: NA

  • Serwera:

    Error executing Checkup
Error details
\tscript: 649 /usr/sbin/mst-cli
\t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger)
\tstack:
\t\t<> Checkup /usr/sbin/mst-cli Message: NA
\t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-server
\t\t<> main /usr/sbin/mstunnel_monitor Message: NA

Rozwiązanie: Aby rozwiązać ten problem, ręcznie uruchom ponownie kontenery podman. Następnie narzędzie Podman powinno być w stanie zidentyfikować kontenery. Jeśli problem będzie się powtarzać lub powróci, rozważ użycie narzędzia cron do utworzenia zadania, które automatycznie ponownie uruchamia kontenery, gdy ten problem będzie widoczny.

W usłudze Podman w dzienniku mstunnel-agent są widoczne błędy System.DateTime

Problem: W przypadku korzystania z narzędzia Podman dziennik mstunnel-agent może zawierać błędy podobne do następujących wpisów:

  • Failed to parse version-info.json for version information.
  • System.Text.Json.JsonException: The JSON value could not be converted to System.DateTime

Ten problem występuje z powodu różnic w datach formatowania między podmanem a agentem tunelu. Te błędy nie wskazują na problem krytyczny ani nie uniemożliwiają łączności. Począwszy od kontenerów wydanych po październiku 2022 r., należy rozwiązać problemy z formatowaniem.

Rozwiązanie: Aby rozwiązać te problemy, zaktualizuj kontener agenta (Podman lub Docker) do najnowszej wersji. W miarę odnajdywania nowych źródeł tych błędów będziemy nadal naprawiać je w kolejnych aktualizacjach wersji.

Łączność z tunelem

Urządzenia nie mogą nawiązać połączenia z serwerem tunelu

Problem: Urządzenia nie mogą nawiązać połączenia z serwerem, a plik dziennika ocserv serwera tunnel zawiera wpis podobny do następującego wpisu: main: tun.c:655: Can't open /dev/net/tun: Operation not permitted

Aby uzyskać wskazówki dotyczące wyświetlania dzienników tunelu, zobacz Wyświetlanie dzienników tunelu firmy Microsoft w tym artykule.

Rozwiązanie: uruchom ponownie serwer przy użyciu mst-cli server restart po ponownym uruchomieniu serwera z systemem Linux.

Jeśli ten problem będzie się powtarzać, rozważ zautomatyzowanie polecenia ponownego uruchomienia przy użyciu narzędzia do planowania cron. Zobacz How to use cron on Linux at opensource.com (Jak używać crona w systemie Linux w opensource.com).

Następne kroki

Dokumentacja aplikacji Microsoft Tunnel