Wymagania wstępne aplikacji Microsoft Tunnel w usłudze Intune

Zanim będzie można zainstalować bramę sieci VPN Microsoft Tunnel dla usługi Microsoft Intune, przejrzyj i skonfiguruj wymagania wstępne. Wymagania wstępne obejmują użycie serwera systemu Linux, który uruchamia kontenery do hostowania oprogramowania serwera tunelu. Ponadto zaplanuj skonfigurowanie sieci, zapór i serwerów proxy do obsługi komunikacji z aplikacją Microsoft Tunnel.

Na wysokim poziomie aplikacja Microsoft Tunnel wymaga:

• Subskrypcja platformy Azure.

• Subskrypcja usługi Microsoft Intune Plan 1).

  Uwaga

  To wymaganie wstępne dotyczy aplikacji Microsoft Tunnel i nie obejmuje aplikacji Microsoft Tunnel do zarządzania aplikacjami mobilnymi, która jest zaawansowaną funkcją usługi Microsoft Intune wymagającą dodatkowych licencji poza usługą Microsoft Intune.

• Aby ukończyć konfigurację aplikacji Microsoft Tunnel, konto, którego użyjesz do zarejestrowania usługi Tunnel Gateway w usłudze Microsoft Intune, oraz dzierżawa usługi Intune muszą mieć przypisaną rolę administratora usługi Microsoft Entra ID usługi Microsoft Entra ID oraz licencję usługi Intune.

• Serwer systemu Linux, który obsługuje kontenery. Serwer może być lokalny lub w chmurze i obsługuje jeden z następujących typów kontenerów:

  • Podman dla Red Hat Enterprise Linux (RHEL). Zobacz wymagania serwera systemu Linux.
  • Docker dla wszystkich innych dystrybucji systemu Linux.

• Certyfikat TLS (Transport Layer Security) dla serwera systemu Linux w celu zabezpieczenia połączeń z urządzeń do serwera bramy tunelu.

• Urządzenia z systemem Android lub iOS/iPadOS.

Po skonfigurowaniu wymagań wstępnych zalecamy uruchomienie narzędzia gotowości w celu sprawdzenia, czy środowisko jest dobrze skonfigurowane do pomyślnej instalacji.

W poniższych sekcjach szczegółowo opisano wymagania wstępne aplikacji Microsoft Tunnel i podano wskazówki dotyczące korzystania z narzędzia przygotowywania.

Pomoc techniczna dla chmury dla instytucji rządowych

Aplikacja Microsoft Tunnel jest obsługiwana przez następujące niezależne środowiska chmurowe:

• U.S. Government Community Cloud (GCC) High

Aplikacja Microsoft Tunnel nie jest obsługiwana na platformie Microsoft Azure obsługiwanej przez firmę 21Vianet.

Aby uzyskać więcej informacji, zobacz opis usługi Microsoft Intune dla rządu USA GCC.

Serwer systemu Linux

Skonfiguruj maszynę wirtualną opartą na systemie Linux lub serwer fizyczny, na którym zostanie zainstalowana brama Microsoft Tunnel.

• Obsługiwane dystrybucje systemu Linux — poniższa tabela zawiera informacje o wersjach systemu Linux, które są obsługiwane dla serwera tunelu, oraz wymaganego kontenera:

  Wersja dystrybucji	Wymagania dotyczące kontenerów	Zagadnienia do rozważenia
  Red Hat (RHEL) 8.9	Podman 4.4.1	Pomoc techniczna kończy się w listopadzie 2025 r. Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 8.10	Podman 4.9.4-rhel (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.3	Podman 4.6.1. (domyślnie)	Pomoc techniczna kończy się w listopadzie 2025 r. Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.4	Podman 4.9.4-rhel (domyślnie)	Pomoc techniczna kończy się w listopadzie 2025 r. Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.5	Podman 5.2.2 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.6	Podman 5.4.0 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.7	Podman 5.8.2 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.8	Podman 5.8.2+ (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 10.0	Podman 5.4.0 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 10.1	Podman 5.8.2 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 10.2	Podman 5.8.2 (domyślnie)	Ta wersja systemu RHEL nie ładuje automatycznie modułu ip_tables do jądra Linux. W przypadku korzystania z tej wersji zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez Podman w wersji 3 i wcześniejszych nie można używać w Podman w wersji 4.2 i nowszych. W przypadku uaktualniania i zmieniania kontenerów zaplanuj utworzenie nowych kontenerów oraz odinstalowanie, a następnie ponowne zainstalowanie aplikacji Microsoft Tunnel.
  Ubuntu 24.04	Docker CE
  Ubuntu 26.04	Docker CE

  Ważna

  W kwietniu 2023 r. Ubuntu zakończy obsługę Ubuntu 18.04. Wraz z zakończeniem świadczenia pomocy technicznej przez system Ubuntu usługa Intune zakończy również obsługę systemu Ubuntu 18.04 do użytku z aplikacją Microsoft Tunnel. W celu uzyskania więcej informacji, zobacz następujący temat: https://wiki.ubuntu.com/Releases.

• Rozmiar serwera systemu Linux: Skorzystaj z następujących wskazówek, aby spełnić Twoje oczekiwane potrzeby:

  # Urządzenia	# Procesory	Pamięć GB	# Serwery	# Witryny	Miejsce na dysku w GB
  1,000	4	4	1	1	30
  2,000	4	4	1	1	30
  5,000	8	8	2	1	30
  10,000	8	8	3	1	30
  20,000	8	8	4	1	30
  40,000	8	8	8	1	30

  Wsparcie skaluje się liniowo. Chociaż każde urządzenie Microsoft Tunnel obsługuje do 64 000 jednoczesnych połączeń, poszczególne urządzenia mogą otwierać wiele połączeń.

• Procesor: 64-bitowy procesor AMD/Intel.

• Instalowanie programu Docker CE lub Podman: W zależności od wersji systemu Linux używanej na serwerze Tunnel zainstaluj na serwerze jeden z następujących elementów:

  • Platforma Docker w wersji 19.03 CE lub nowszej.
  • Podman w wersji 3.0 lub 4.0 w zależności od wersji RHEL.

  Aplikacja Microsoft Tunnel wymaga platformy Docker lub Podman na serwerze systemu Linux, aby zapewnić obsługę kontenerów. Kontenery zapewniają spójne środowisko wykonywania, monitorowanie kondycji i proaktywne korygowanie oraz czyste środowisko uaktualniania.

  Aby uzyskać informacje na temat instalowania i konfigurowania platformy Docker lub Podman, zobacz:

  • Zainstaluj aparat platformy Docker w systemie CentOS lub Red Hat Enterprise Linux 7.

    Uwaga

    Poprzedni link odsyła do instrukcji pobierania i instalacji CentOS. Użyj tych samych instrukcji dla systemu RHEL 7.4. Wersja zainstalowana domyślnie w systemie RHEL 7.4 jest zbyt stara, aby obsługiwać bramę tunelu firmy Microsoft.

  • Zainstaluj Docker Engine na Ubuntu.

  • Zainstaluj Podman na Red Hat Enterprise Linux 8.4 i nowszych (przewiń w dół do RHEL8).

    Te wersje systemu RHEL nie obsługują platformy Docker. Zamiast tego te wersje używają Podmana, a podman jest częścią modułu o nazwie "container-tools". W tym kontekście moduł jest zestawem pakietów RPM, które reprezentują składnik i które zwykle instalują się razem. Typowy moduł zawiera pakiety z aplikacją, pakiety z bibliotekami zależności specyficznymi dla aplikacji, pakiety z dokumentacją aplikacji i pakiety z narzędziami pomocniczymi. Aby uzyskać więcej informacji, zobacz Wprowadzenie do modułów w dokumentacji systemu Red Hat.

    Uwaga

    Podman bez rootowania: Microsoft Tunnel obsługuje użycie kontenera Podman bez rootowania.

    Korzystanie z podmana bez rootowania wymaga dodatkowych wymagań wstępnych w stosunku do tych wyszczególnionych w tym artykule oraz użycia zmodyfikowanego wiersza polecenia podczas uruchamiania skryptu instalacji tunelu. Aby uzyskać informacje o dodatkowych wymaganiach wstępnych i wierszu polecenia instalacji, zobacz Korzystanie z kontenera Podman bez rootowania w artykule Konfigurowanie aplikacji Microsoft Tunnel dla Intune.

• Certyfikat TLS (Transport Layer Security): serwer systemu Linux wymaga zaufanego certyfikatu TLS w celu zabezpieczenia połączenia między urządzeniami a serwerem bramy tunelowej. Podczas instalacji bramy tunelu dodajesz do serwera certyfikat TLS i pełny łańcuch zaufanych certyfikatów.

  • Alternatywna nazwa podmiotu (SAN) certyfikatu TLS używanego do zabezpieczania punktu końcowego bramy tunelu musi być zgodna z adresem IP lub nazwą FQDN serwera bramy tunelu.

  • W przypadku urządzeń z systemem iOS publiczne certyfikaty TLS muszą być wystawiane z głównego urzędu certyfikacji, a ich maksymalna data wygaśnięcia to 398 dni. Certyfikaty wystawione przez dodane przez użytkownika lub dodane przez administratora główne urzędy certyfikacji mogą mieć maksymalną datę wygaśnięcia wynoszącą do dwóch lat (730 dni). Aby uzyskać więcej informacji na temat tych wymagań dotyczących certyfikatów TLS, zobacz Informacje o nadchodzących limitach dotyczących zaufanych certyfikatów na stronie support.apple.com.

  • W przypadku urządzeń z systemem Android zalecamy, aby publiczne certyfikaty TLS wystawione z głównego urzędu certyfikacji miały maksymalną datę wygaśnięcia wynoszącą 398 dni.

  • Obsługa symboli wieloznacznych jest ograniczona. Na przykład *.contoso.com jest obsługiwana, ale ciąg dalszy*.com nie jest obsługiwany.

  • Podczas instalacji serwera bramy tunelu należy skopiować cały łańcuch zaufanych certyfikatów na serwer systemu Linux. Skrypt instalacyjny podaje lokalizację, do której kopiowane są pliki certyfikatów, i monituje o jej skopiowanie.

  • Jeśli używasz certyfikatu TLS, który nie jest publicznie zaufany, musisz wypchnąć cały łańcuch zaufania do urządzeń przy użyciu profilu zaufanego certyfikatu usługi Intune.

  • Certyfikat TLS może być w formacie PEM lub pfx .

  • Aby umożliwić sprawdzanie kondycji odwołania certyfikatu TLS , upewnij się, że adres protokołu OCSP (Online Certificate Status Protocol) lub listy odwołania certyfikatów (CRL) zdefiniowany przez certyfikat TLS jest dostępny z serwera.

  • Skonfiguruj certyfikat klientów tunelowania przy użyciu klucza o rozmiarze 2048 bitów lub większym. Zalecamy stosowanie większych kluczy, aby ułatwić obsługę przyszłych i zmieniających się wymagań protokołu SSL/TLS przez różne rozwiązania bibliotek SSL/TLS.

    Porada

    Okresowo przeglądaj wymagania wybranej biblioteki SSL/TLS, aby upewnić się, że infrastruktura i certyfikaty pozostają obsługiwane i zgodne z ostatnimi zmianami w tej bibliotece, a także ponownie wydawaj certyfikaty klienta Tunnel, gdy jest to konieczne, aby być na bieżąco ze zmieniającymi się wymaganiami rozwiązań.

• Wersja protokołu TLS: domyślnie połączenia między klientami i serwerami aplikacji Microsoft Tunnel używają protokołu TLS 1.3. Jeśli protokół TLS 1.3 jest niedostępny, połączenie może wrócić do TLS 1.2.

Domyślna sieć mostka

Zarówno kontenery Podman, jak i Docker używają sieci mostka do przekazywania ruchu przez hosta systemu Linux. Gdy kontenery łączą sieć z siecią firmową, brama tunelu nie może pomyślnie kierować ruchu do tej sieci firmowej.

Domyślne sieci mostkowe to:

• Dokownik: 172.17.0.0/16
• Podman: 10.88.0.0/16

Aby uniknąć konfliktów, można ponownie skonfigurować zarówno Podman, jak i Docker, aby korzystać z określonej sieci mostkowej.

Zmienianie domyślnej sieci mostka używanej przez platformę Docker

Docker używa pliku /etc/docker/daemon.json do skonfigurowania nowego domyślnego adresu IP mostka. W pliku adres IP mostka musi być określony w notacji CIDR (Classless inter-domain routing), czyli w zwartym sposobie reprezentowania adresu IP wraz z towarzyszącą mu maską podsieci i prefiksem routingu.

1. Użyj następującego polecenia, aby zatrzymać kontener MS Tunnel Gateway: sudo mst-cli server stop ; sudo mst-cli agent stop

2. Następnie uruchom następujące polecenie, aby usunąć istniejące urządzenie mostka platformy Docker: sudo ip link del docker0

3. Jeśli plik /etc/docker/daemon.json znajduje się na serwerze, użyj edytora plików, takiego jak vi lub nano , aby zmodyfikować plik. Uruchom edytor plików z uprawnieniami użytkownika root lub sudo:

   • Gdy wpis "bip: jest obecny z adresem IP, zmodyfikuj go, dodając nowy adres IP w notacji CIDR.
   • Jeśli wpis "bip" nie istnieje, należy dodać zarówno wartość "bip" : jak i nowy adres IP w notacji CIDR.

   W poniższym przykładzie przedstawiono strukturę pliku daemon.json ze zaktualizowanym wpisem "bip:, który używa zmodyfikowanego adresu IP "192.168.128.1/24".

   Przykład daemon.json:

   {
   "bip": "192.168.128.1/24"
   }
   

4. Jeśli plik /etc/docker/daemon.json nie znajduje się na serwerze, uruchom polecenie podobne do poniższego przykładu, aby utworzyć plik i zdefiniować adres IP mostka, którego chcesz użyć.

   Przykład: sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.json

5. Użyj następującego polecenia, aby uruchomić kontener MS Tunnel Gateway: sudo mst-cli agent start ; sudo mst-cli server start

Aby uzyskać więcej informacji, zobacz Korzystanie z sieci mostkowych w dokumentacji platformy Docker.

Zmienianie domyślnej sieci mostka używanej przez Podmana

Podman używa pliku /etc/cni/net.d jako 87-podman-bridge.conflist do skonfigurowania nowego domyślnego adresu IP mostka.

1. Użyj następującego polecenia, aby zatrzymać kontener MS Tunnel Gateway: sudo mst-cli server stop ; sudo mst-cli agent stop

2. Następnie uruchom następujące polecenie, aby usunąć istniejące urządzenie mostka Podman: sudo ip link del cni-podman0

3. Używając uprawnień roota i edytora plików, takiego jak vi lub nano, zmodyfikuj /etc/cni/net.d jako 87-podman-bridge.conflist , aby zaktualizować wartości domyślne dla "subnet:" i "gateway:" , zastępując domyślne wartości Podman żądanymi adresami podsieci i bramy. Adres podsieci musi być określony w notacji CIDR.

   Domyślne ustawienia Podmana to:

   • Podsieć: 10.88.0.0/16
   • Brama: 10.88.0.1

4. Użyj następującego polecenia, aby ponownie uruchomić kontenery MS Tunnel Gateway: sudo mst-cli agent start ; sudo mst-cli server start

Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci kontenerów za pomocą Podmana w dokumentacji systemu Red Hat.

Inspekcja systemu Linux

Inspekcja systemu Linux może pomóc zidentyfikować informacje istotne z punktu widzenia zabezpieczeń lub naruszenia zabezpieczeń na serwerze systemu Linux, który hostuje aplikację Microsoft Tunnel. Inspekcja systemu Linux jest zalecana dla aplikacji Microsoft Tunnel, ale nie jest wymagana. Aby użyć inspekcji systemu, na serwerze z systemem Linux musi być zainstalowany pakiet auditd w /etc/audit/auditd.conf.

Za każdym razem, gdy uruchomisz narzędzie mst-readiness, narzędzie może wyświetlić ostrzeżenie wskazujące na brak auditd . Aby włączyć inspekcję katalogów specyficznych dla tunelu, zainstaluj pakiet auditd przed uruchomieniem mstunnel-setup.

Szczegóły implementacji inspekcji zależą od używanej platformy systemu Linux:

• Red Hat: Wersje Red Had Enterprise Linux 7 i nowsze domyślnie instalują pakiet auditd. Jeśli jednak pakiet nie jest zainstalowany, możesz go zainstalować za pomocą następującego wiersza polecenia na serwerze systemu Linux:sudo dnf install audit audispd-plugins

  Zazwyczaj audytowany pakiet jest dostępny w domyślnym repozytorium każdej wersji REHL.

  Aby uzyskać więcej informacji na temat używania inspekcji systemu w systemie RHEL, zobacz Konfigurowanie inspekcji systemu systemu Linux za pomocą auditd w blogu Red Hat.

• Ubuntu: Aby korzystać z audytu systemu w Ubuntu, musisz ręcznie zainstalować audytowany pakiet. Aby to zrobić, użyj następującego wiersza polecenia na serwerze systemu Linux:sudo apt install auditd audispd-plugins

  Zazwyczaj audytowany pakiet jest dostępny w domyślnym repozytorium każdej wersji systemu Ubuntu.

  Aby uzyskać więcej informacji na temat korzystania z audytu systemu w systemie Ubuntu, zobacz artykuł Jak skonfigurować i zainstalować Auditd w systemie Ubuntu, który jest dostępny na stronie internetowej dev.to, która została pierwotnie opublikowana pod adresem kubefront.com.

Sieć

• Włącz przekazywanie pakietów dla IPv4: każdy serwer systemu Linux, który hostuje oprogramowanie serwera tunelu, musi mieć włączone przekazywanie IP dla IPv4. Aby sprawdzić stan przekazywania adresów IP, na serwerze uruchom jedno z następujących poleceń ogólnych jako root lub sudo. Oba polecenia zwracają wartość 0 dla wyłączonego i wartość 1 dla włączonego:

  • sysctl net.ipv4.ip_forward
  • cat /proc/sys/net/ipv4/ip_forward

  Jeśli nie jest włączone, możesz tymczasowo włączyć przekazywanie IP, uruchamiając na serwerze jedno z następujących poleceń ogólnych jako root lub sudo . Te polecenia mogą zmienić konfigurację przekazywania adresów IP do momentu ponownego uruchomienia serwera. Po ponownym uruchomieniu serwer przywraca poprzedni stan przekazywania adresów IP. W przypadku obu poleceń użyj wartości 1 , aby włączyć przesyłanie dalej. Wartość 0 wyłącza przesyłanie dalej. W poniższych przykładach poleceń jest używana wartość 1 , aby włączyć przesyłanie dalej:

  • sysctl -w net.ipv4.ip_forward=1
  • echo 1 > /proc/sys/net/ipv4/ip_forward

  Aby przekazywanie IP było trwałe, na każdym serwerze Linux należy edytować plik /etc/sysctl.conf i usunąć wiodący hashtag (#) z #net.ipv4.ip_forward=1, aby włączyć przekazywanie pakietów. Po zakończeniu edycji wpis powinien wyglądać następująco:

  # Uncomment the next line to enable packet forwarding for IPv4
  net.ipv4.ip_forward=1
  

  Aby ta zmiana została uwzględniona, musisz ponownie uruchomić serwer lub uruchomić program sysctl -p.

  Jeśli oczekiwany wpis nie znajduje się w pliku sysctl.conf, zapoznaj się z dokumentacją używanej dystrybucji, aby dowiedzieć się, jak włączyć przekazywanie IP. Zazwyczaj można edytować plik sysctl.conf , aby dodać brakujący wiersz na końcu pliku w celu trwałego włączenia przekazywania IP.

• Konfigurowanie wielu kart sieciowych na serwer(opcjonalnie): zalecamy używanie dwóch kontrolerów interfejsu sieciowego (NIC) na serwer systemu Linux w celu zwiększenia wydajności, chociaż użycie dwóch jest opcjonalne.

  • NIC 1 — ta karta sieciowa obsługuje ruch z zarządzanych urządzeń i powinna znajdować się w sieci publicznej za pomocą publicznego adresu IP.  Ten adres IP jest adresem konfigurowanym w konfiguracji witryny. Ten adres może reprezentować pojedynczy serwer lub moduł równoważenia obciążenia.

  • NIC 2 — ta karta sieciowa obsługuje ruch do zasobów lokalnych i powinna znajdować się w prywatnej sieci wewnętrznej bez segmentacji sieci.

• Upewnij się, że oparte na chmurze maszyny wirtualne z systemem Linux mogą uzyskiwać dostęp do Twojej sieci lokalnej: Jeśli uruchomisz system Linux jako maszynę wirtualną w chmurze, upewnij się, że serwer ma dostęp do Twojej sieci lokalnej. Na przykład dla maszyny wirtualnej na platformie Azure możesz użyć usługi Azure ExpressRoute lub podobnej w celu zapewnienia dostępu. Usługa Azure ExpressRoute nie jest konieczna, gdy serwer jest uruchamiany lokalnie na maszynie wirtualnej.

• Moduły równoważenia obciążenia(opcjonalnie): jeśli zdecydujesz się dodać moduł równoważenia obciążenia, zapoznaj się z dokumentacją dostawcy, aby uzyskać szczegóły konfiguracji. Weź pod uwagę ruch sieciowy i porty zapory specyficzne dla usługi Intune i aplikacji Microsoft Tunnel.

  Serwer tunelowania odpowiada na żądania GET za pomocą strony statycznej. Odpowiedź jest używana jako sonda przez moduły równoważenia obciążenia w celu sprawdzenia żywotności serwera tunelu. Odpowiedź jest statyczna i nie zawiera informacji poufnych.

• Sieć VPN dla aplikacji i obsługa domen najwyższego poziomu — korzystanie z sieci VPN dla aplikacji z wewnętrznym użyciem lokalnych domen najwyższego poziomu nie jest obsługiwane przez aplikację Microsoft Tunnel.

Zapora

Domyślnie aplikacja Microsoft Tunnel i serwer korzystają z następujących portów:

Porty przychodzące:

• TCP 443 — wymagany przez aplikację Microsoft Tunnel.
• UDP 443 — wymagany przez aplikację Microsoft Tunnel.
• TCP 22 – opcjonalny. Używany do SSH/SCP do serwera systemu Linux.

Porty wyjściowe:

• TCP 443 — wymagany do uzyskania dostępu do usług Intune. Wymagany przez platformę Docker lub Podmana do ściągania obrazów.

Podczas tworzenia konfiguracji serwera dla tunelu można określić inny port niż domyślny 443. Jeśli określisz inny port, skonfiguruj zapory obsługujące Twoją konfigurację.

Więcej wymagań:

Aby uzyskać dostęp do usługi tokenów zabezpieczających i magazynu platformy Azure na potrzeby dzienników, zapewnij dostęp do następujących nazw FQDN:

• Usługa tokenów zabezpieczających: *.sts.windows.net
• Magazyn platformy Azure dla dzienników tunelu:*.blob.core.windows.net
• Inne adresy URL punktu końcowego magazynu: *.blob.storage.azure.net
• Microsoft Intune:*.manage.microsoft.com
• Uwierzytelnianie firmy Microsoft: login.microsoftonline.com
• Microsoft Graph: graph.microsoft.com
• Skonfiguruj reguły zapory do obsługi konfiguracji wyszczególnionych w konfiguracji reguł zapory klienta rejestru artefaktów Microsoft (MAR).

Serwer proxy

Z aplikacją Microsoft Tunnel można używać serwera proxy.

Poniższe zagadnienia mogą ułatwić pomyślne skonfigurowanie serwera systemu Linux i środowiska:

Konfigurowanie serwera proxy ruchu wychodzącego dla platformy Docker

• Jeśli używasz wewnętrznego serwera proxy, może być konieczne skonfigurowanie hosta systemu Linux do korzystania z serwera proxy przy użyciu zmiennych środowiskowych. Aby użyć zmiennych, edytuj plik /etc/environment na serwerze systemu Linux i dodaj następujące wiersze, zastępując adres w każdym wierszu adresem adresu IP serwera proxy:port:

  http_proxy=address
https_proxy=address

• Uwierzytelnione serwery proxy nie są obsługiwane.

• Serwer proxy nie może przerwać i sprawdzić, ponieważ serwer systemu Linux używa wzajemnego uwierzytelniania TLS podczas nawiązywania połączenia z usługą Intune.

• Skonfiguruj platformę Docker, aby używała serwera proxy do ściągania obrazów. W tym celu należy edytować plik /etc/system/docker.service.d/http-proxy.conf na serwerze systemu Linux i dodać następujące wiersze:

  [Service]
  Environment="HTTP_PROXY=http://your.proxy:8080/"
  Environment="HTTPS_PROXY=https://your.proxy:8080/"
  Environment="NO_PROXY=127.0.0.1,localhost"
  

  Uwaga

  Aplikacja Microsoft Tunnel nie obsługuje serwera proxy aplikacji usługi Microsoft Entra ani podobnych rozwiązań serwera proxy.

Konfigurowanie serwera proxy ruchu wychodzącego dla Podman

Poniższe szczegóły mogą pomóc w skonfigurowaniu wewnętrznego serwera proxy podczas korzystania z Podmana:

• Uwierzytelnione serwery proxy nie są obsługiwane.

• Serwer proxy nie może przerwać i sprawdzić, ponieważ serwer systemu Linux używa wzajemnego uwierzytelniania TLS podczas nawiązywania połączenia z usługą Intune.

• Podman odczytuje informacje o serwerze proxy HTTP przechowywane w pliku /etc/profile.d/http_proxy.sh. Jeśli ten plik nie istnieje na serwerze, utwórz go. Edytuj http_proxy.sh , aby dodać dwa następujące wiersze. W poniższych wierszach 10.10.10.1:3128 to przykładowy adres:wpis portu. Po dodaniu tych wierszy zastąp 10.10.10.1:3128 wartościami adresu IP serwera proxy :port:

  export HTTP_PROXY=http://10.10.10.1:3128
export HTTPS_PROXY=http://10.10.10.1:3128

  Jeśli masz dostęp do portalu Red Hat Customer Portal, możesz wyświetlić artykuł z bazy wiedzy związany z tym rozwiązaniem. Zobacz Konfigurowanie zmiennych serwera proxy protokołu HTTP dla Podman - Red Hat Customer Portal.

• Po dodaniu tych dwóch wierszy do http_proxy.sh przed zainstalowaniem usługi Microsoft Tunnel Gateway przez uruchomienie mstunnel-setup skrypt automatycznie konfiguruje zmienne środowiskowe serwera proxy bramy tunelu w pliku /etc/mstunnel/env.sh.

  Aby skonfigurować serwer proxy po zakończeniu konfiguracji usługi Microsoft Tunnel Gateway, wykonaj następujące czynności:

  1. Zmodyfikuj lub utwórz plik /etc/profile.d/http_proxy.sh i dodaj dwa wiersze z poprzedniego punktora.

  2. Edytuj plik /etc/mstunnel/env.sh i dodaj następujące dwa wiersze na końcu pliku. Podobnie jak w poprzednich wierszach, zastąp przykładową wartość address:portz 10.10.10.1:3128 wartościami adresu IP serwera proxy:port:

     HTTP_PROXY=http://10.10.10.1:3128
HTTPS_PROXY=http://10.10.10.1:3128

  3. Uruchom ponownie serwer bramy tunelu: Uruchom mst-cli server restart

  Należy pamiętać, że RHEL używa SELinux. Ponieważ serwer proxy, który nie jest uruchomiony na porcie SELinux dla http_port_t , może wymagać dodatkowej konfiguracji, sprawdź użycie portów zarządzanych SELinux dla protokołu http. Aby wyświetlić konfiguracje, uruchom następujące polecenie: sudo semanage port -l | grep "http_port_t"

  Przykład wyników polecenia sprawdzania portu. W tym przykładzie serwer proxy używa adresu 3128 i nie ma go na liście:

  

  • Jeśli serwer proxy działa na jednym z portów SELinux dla http_port_t, możesz kontynuować proces instalacji bramy tunelu.

  • Jeśli serwer proxy nie jest uruchomiony na porcie SELinux dla http_port_t , jak w poprzednim przykładzie, musisz wykonać dodatkowe konfiguracje.

    Jeśli portu serwera proxy nie ma na liście dlahttp_port_t, sprawdź, czy nie jest on używany przez inną usługę. Użyj polecenia semanage , aby najpierw sprawdzić port używany przez serwer proxy, a potem, w razie potrzeby, zmienić go. Aby sprawdzić port używany przez serwer proxy, uruchom polecenie: sudo semanage port -l | grep "your proxy port"

    Przykład wyników wyszukiwania usługi, która może korzystać z portu:

    

    • W przykładzie oczekiwany przez nas port (3128) jest używany przez kałamarnicę, która jest usługą proxy OSS. Zasady SELinux serwera proxy Squid są częścią wielu popularnych dystrybucji. Ponieważ squid używa portu 3128 (naszego przykładowego portu), musimy zmodyfikować porty http_port_t i dodać port 3128, aby był dozwolony przez SELinux dla proxy używanego przez Tunnel. Aby zmodyfikować użycie portu, uruchom następujące polecenie: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

      Przykład polecenia modyfikującego port:

      

      Po uruchomieniu polecenia zmiany portu uruchom następujące polecenie, aby sprawdzić, czy port jest używany przez inną usługę: sudo semanage port -l | grep "your proxy port"

      Przykład polecenia sprawdzającego port po modyfikacji portu:

      

      W tym przykładzie port 3128 jest teraz skojarzony zarówno z http_port-t , jak i squid_port_t. Taki wynik jest oczekiwany. Jeśli port serwera proxy nie jest wymieniony podczas uruchamiania polecenia sudo semanage port -l | grep "your_proxy_port" , uruchom polecenie, aby ponownie zmodyfikować port, ale -m w poleceniu semanage z -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Skonfiguruj Podmana, aby używał serwera proxy do pobierania aktualizacji obrazu

Możesz skonfigurować Podmana tak, aby używał serwera proxy do pobierania (ściągania) zaktualizowanych obrazów dla Podmana. Ta konfiguracja jest ważna dla przyszłych uaktualnień. Ponieważ należy go skonfigurować po zainstalowaniu bramy tunelu, wspominamy o tym tutaj, ale dodaliśmy wskazówki dotyczące konfiguracji do konfigurowania Podmana w celu używania serwera proxy do pobierania aktualizacji obrazu w artykule Konfigurowanie aplikacji Microsoft Tunnel jako zadanie do wykonania po zainstalowaniu serwera bramy tunelu.

Platformy

Urządzenia muszą być zarejestrowane w usłudze Intune, aby były obsługiwane przez aplikację Microsoft Tunnel. Obsługiwane są tylko następujące platformy urządzeń:

• iOS/iPadOS

• Android Enterprise:

  • W pełni zarządzane
  • Profil służbowy Corporate-Owned
  • Personally-Owned Profil służbowy

  Uwaga

  Dedykowane urządzenia z systemem Android Enterprise nie są obsługiwane przez aplikację Microsoft Tunnel.

  Ważna

  Wsparcie techniczne dla systemu Android 10 w aplikacji Microsoft Tunnel zakończyło się 31 marca 2026 r. Urządzenia z systemem Android 10 należy uaktualnić do systemu Android 11 lub nowszego, aby nadal korzystać z aplikacji Microsoft Tunnel.

Wszystkie platformy obsługują następujące funkcje:

• Uwierzytelnianie usługi Microsoft Entra w aplikacji Tunnel przy użyciu nazwy użytkownika i hasła.
• Uwierzytelnianie usług federacyjnych Active Directory Federation Services (AD FS) w tunelu przy użyciu nazwy użytkownika i hasła.
• Obsługa poszczególnych aplikacji.
• Ręczny tunel dla całego urządzenia za pośrednictwem aplikacji Tunnel, w której użytkownik uruchamia sieć VPN i wybiera pozycję Połącz.
• Dzielone tunelowanie. Jednak w systemie iOS reguły dzielonego tunelowania są ignorowane, gdy profil sieci VPN korzysta z sieci VPN dla aplikacji.

Obsługa serwera proxy jest ograniczona do następujących platform:

• Android 11 i nowszy
• iOS/iPadOS

Uprawnienia

Aby zarządzać aplikacją Microsoft Tunnel, użytkownicy muszą mieć uprawnienia należące do grupy uprawnień bramy aplikacji Microsoft Tunnel w usłudze Intune. Domyślnie te uprawnienia mają administratorzy usługi Intune i administratorzy usługi Microsoft Entra. Możesz również dodać je do ról niestandardowych utworzonych dla dzierżawy usługi Intune.

Podczas konfigurowania roli na stronie Uprawnienia rozwiń pozycję Microsoft Tunnel Gateway , a następnie wybierz uprawnienia, których chcesz udzielić.

Grupa uprawnień Microsoft Tunnel Gateway przyznaje następujące uprawnienia:

• Tworzenie — konfigurowanie serwerów i lokacji bramy tunelowej firmy Microsoft. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł dzielonego tunelowania. Lokacje są logicznymi grupami wielu serwerów obsługujących aplikację Microsoft Tunnel.

• Aktualizuj (modyfikuj) — aktualizuj konfiguracje serwera i lokacje bramy tunelowej firmy Microsoft. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł dzielonego tunelowania. Lokacje są logicznymi grupami wielu serwerów obsługujących aplikację Microsoft Tunnel.

• Delete — usuń konfiguracje serwera i lokacje usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł dzielonego tunelowania. Lokacje są logicznymi grupami wielu serwerów obsługujących aplikację Microsoft Tunnel.

• Odczyt — wyświetlanie konfiguracji serwera i lokacji usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł dzielonego tunelowania. Lokacje są logicznymi grupami wielu serwerów obsługujących aplikację Microsoft Tunnel.

Uruchamianie narzędzia gotowości

Przed rozpoczęciem instalacji serwera zalecamy pobranie i uruchomienie najnowszej wersji narzędzia mst-readiness . Narzędzie to jest skryptem uruchamianym na serwerze systemu Linux, który wykonuje następujące akcje:

• Sprawdza, czy konto usługi Microsoft Entra, którego używasz do zainstalowania aplikacji Microsoft Tunnel, ma role wymagane do ukończenia rejestracji.

• Potwierdza, że konfiguracja sieci zezwala aplikacji Microsoft Tunnel na dostęp do wymaganych punktów końcowych firmy Microsoft.

• Sprawdza obecność modułu ip_tables na serwerze Linux. Ten test został dodany do skryptu 11 lutego 2022 r., kiedy dodano obsługę systemu RHEL 8.5. RHEL 8.5 później nie ładuj domyślnie modułu ip_tables. Jeśli po zainstalowaniu serwera Linux nie są one wyświetlane, należy ręcznie załadować moduł ip_tables.

Narzędzie mst-readiness jest zależne od jq, procesora JSON wiersza polecenia. Przed uruchomieniem narzędzia gotowości upewnij się, że JQ jest zainstalowany. Aby uzyskać informacje o tym, jak pobrać i zainstalować jq, zobacz dokumentację używanej wersji systemu Linux.

Aby użyć narzędzia sprawdzania gotowości:

1. Uzyskaj najnowszą wersję narzędzia gotowości, korzystając z jednej z następujących metod:

   • Pobierz narzędzie bezpośrednio przy użyciu przeglądarki internetowej. Przejdź do https://aka.ms/microsofttunnelready strony umożliwiającej pobranie pliku o nazwie mst-readiness.

   • Zaloguj się do centrum >administracyjnego usługi Microsoft IntuneAdministrowanie> dzierżawąMicrosoft Tunnel Gateway, wybierz kartę Serwery, wybierz pozycję Utwórz, aby otworzyć okienko Tworzenie serwera, a następnie wybierz pozycję Download readiness tool.

   • Użyj polecenia systemu Linux, aby bezpośrednio pobrać narzędzie gotowości. Na przykład możesz użyć polecenia wget lub curl , aby otworzyć link https://aka.ms/microsofttunnelready.

     Na przykład, aby użyć wget i log details do mst-readiness podczas pobierania, uruchom polecenie wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

   Skrypt można uruchomić z dowolnego serwera systemu Linux znajdującego się w tej samej sieci co serwer, który zamierzasz zainstalować, dzięki czemu administratorzy sieci mogą użyć skryptu do samodzielnego rozwiązywania problemów z siecią.

2. Aby sprawdzić konfigurację sieci i systemu Linux, uruchom skrypt za pomocą następujących poleceń. Te polecenia ustawiają uprawnienia uruchamiania skryptu, sprawdzają, czy tunel może połączyć się z poprawnymi punktami końcowymi, a następnie sprawdzają obecność narzędzi używanych przez tunel:

   • sudo ./mst-readiness

   • sudo ./mst-readiness network - To polecenie uruchamia następujące akcje, a następnie zgłasza powodzenie lub błąd dla obu:

     • Próbuje nawiązać połączenie z każdym punktem końcowym firmy Microsoft, który będzie używany przez tunel.
     • Sprawdza, czy wymagane porty w zaporze są otwarte.

   • sudo ./mst-readiness utils - To polecenie sprawdza, czy dostępne są narzędzia używane przez Tunnel, takie jak Docker lub Podman i ip_tables.

3. Aby sprawdzić, czy konto, które zostanie użyte do zainstalowania aplikacji Microsoft Tunnel, ma wymagane role i uprawnienia do ukończenia rejestracji, uruchom skrypt za pomocą następującego wiersza polecenia: ./mst-readiness account

   Skrypt monituje o użycie innego komputera z przeglądarką internetową, która jest używana do uwierzytelniania w usłudze Microsoft Entra ID i w usłudze Intune. Narzędzie zgłasza powodzenie lub błąd.

Aby uzyskać więcej informacji na temat tego narzędzia, zobacz Reference for mst-cli in the reference article for Microsoft Tunnel article .

Ręczna instalacja auditd na potrzeby inspekcji systemu Linux

Narzędzie gotowości sprawdza obecność kontrolowanego pakietu na potrzeby inspekcji systemu systemu Linux. Ponieważ inspekcja jest opcjonalna i niewymagana, skrypt gotowości zwróci ostrzeżenie, gdy ten pakiet nie zostanie wykryty.

Auditd jest instalowany domyślnie przez RHEL 7 i nowsze wersje, ale może nie być instalowany domyślnie przez dystrybucje Ubuntu. Jeśli nie istnieje, możesz zainstalować go ręcznie na serwerze systemu Linux.

Aby uzyskać informacje na temat ręcznej instalacji przed zainstalowaniem serwera tunelu, zobacz Inspekcja systemu systemu systemu Linux we wcześniejszej części tego artykułu.

Aby zainstalować narzędzie auditd po zainstalowaniu Microsoft Tunnel, zobacz Instalowanie inspekcji systemu systemu Linux po zainstalowaniu serwera Tunnel w temacie Konfigurowanie Micrfosoft Tunnel.

Ręczne ładowanie ip_tables

Podczas gdy większość dystrybucji Linux automatycznie ładuje moduł ip_tables, niektóre dystrybucje mogą nie być. Na przykład system RHEL 8.5 domyślnie nie ładuje ip_tables.

Aby sprawdzić obecność tego modułu, uruchom najnowszą wersję narzędzia mst-readiness na serwerze systemu Linux. Sprawdzenie ip_tables zostało dodane do skryptu narzędzi gotowości 11 lutego 2022 r.

Jeśli moduł nie jest obecny, narzędzie zatrzymuje się na sprawdzaniu ip_tables modułu. W tym scenariuszu możesz uruchomić następujące polecenia, aby ręcznie załadować moduł.

Ręczne ładowanie modułu ip_tables

W kontekście sudo uruchom następujące polecenia na serwerze systemu Linux:

1. Zweryfikuj obecność ip_tables na serwerze: lsmod |grep ip_tables

2. Jeśli ip_tables nie istnieje, uruchom następujące polecenie, aby natychmiast załadować moduł do jądra, bez ponownego uruchamiania: /sbin/modprobe ip_tables

3. Uruchom ponownie walidację, aby potwierdzić, że tabele są teraz załadowane: lsmod |grep ip_tables

Konfigurowanie Linux ładowania ip_tables podczas rozruchu

W kontekście sudo uruchom następujące polecenie na serwerze Linux, aby utworzyć plik konfiguracyjny, który ładuje ip_tables do jądra w czasie rozruchu:echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Ręcznie załaduj moduł tun

Aplikacja Microsoft Tunnel wymaga modułu tun, jednak niektóre dystrybucje systemu Linux domyślnie nie ładują modułu tun.

Aby sprawdzić obecność modułu tun na serwerze, uruchom polecenie: lsmod |grep tun

1. Jeśli tun nie jest obecny, uruchom następujące polecenie, aby natychmiast załadować moduł do jądra, bez ponownego uruchamiania: /sbin/modprobe tun

2. Uruchom ponownie walidację, aby potwierdzić, że moduł tun jest teraz załadowany: lsmod |grep tun

Konfigurowanie systemu Linux do ładowania tun podczas rozruchu

W kontekście sudo uruchom następujące polecenie na serwerze systemu Linux, aby utworzyć plik konfiguracyjny, który ładuje tun do jądra w czasie rozruchu:echo tun > /etc/modules-load.d/mstunnel_tun.conf

Następne kroki

Konfigurowanie aplikacji Microsoft Tunnel