Wymagania wstępne dotyczące aplikacji Microsoft Tunnel w Intune

Przed zainstalowaniem bramy sieci VPN microsoft tunnel dla Microsoft Intune zapoznaj się z wymaganiami wstępnymi i skonfiguruj je. Wymagania wstępne obejmują korzystanie z serwera z systemem Linux, który uruchamia kontenery do hostowania oprogramowania serwera Tunnel. Zaplanuj również skonfigurowanie sieci, zapór i serwerów proxy w celu obsługi komunikacji dla aplikacji Microsoft Tunnel.

Na wysokim poziomie aplikacja Microsoft Tunnel wymaga następujących elementów:

• Subskrypcja platformy Azure.

• Subskrypcja planu Microsoft Intune 1.

• Serwer z systemem Linux z uruchomionymi kontenerami. Serwer może być lokalny lub w chmurze i obsługuje jeden z następujących typów kontenerów:

  • Podman for Red Hat Enterprise Linux (RHEL). Zapoznaj się z wymaganiami dotyczącymi serwera z systemem Linux .
  • Platforma Docker dla wszystkich innych dystrybucji systemu Linux.

• Certyfikat TLS (Transport Layer Security) dla serwera z systemem 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 , aby sprawdzić, czy środowisko jest dobrze skonfigurowane pod kątem pomyślnej instalacji.

W poniższych sekcjach szczegółowo opisano wymagania wstępne dotyczące rozwiązania Microsoft Tunnel i przedstawiono wskazówki dotyczące korzystania z narzędzia gotowości.

Uwaga

Na tym samym urządzeniu nie można używać protokołu Tunnel i globalnego bezpiecznego dostępu (GSA).

Serwer z systemem Linux

Skonfiguruj maszynę wirtualną z systemem Linux lub serwer fizyczny, na którym ma zostać zainstalowana brama Microsoft Tunnel Gateway.

Uwaga

Obsługiwane są tylko systemy operacyjne i wersje kontenerów wymienione w poniższej tabeli. Wersje, których nie ma na liście, nie są obsługiwane. Dopiero po zweryfikowaniu możliwości testowania i obsługi nowsze wersje są dodawane do tej listy. Bądź na bieżąco z aktualizacjami zabezpieczeń.

• Obsługiwane dystrybucje systemu Linux — w poniższej tabeli opisano, które wersje systemu Linux są obsługiwane dla serwera Tunnel i kontenera, którego potrzebują:

  Wersja dystrybucji	Wymagania dotyczące kontenera	Zagadnienia dotyczące
  CentOS 7.4+	Docker CE	Pomoc techniczna kończy się w czerwcu 2024 r. System CentOS 8+ nie jest obsługiwany
  Red Hat (RHEL) 7.4+	Docker CE	Pomoc techniczna kończy się w czerwcu 2024 r.
  Czerwony kapelusz (RHEL) 8.6	Podman 4.0 (domyślnie) Podman 3.0	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.0. Jeśli uaktualnisz i zmienisz kontenery z wersji 3 na 4.0, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Czerwony kapelusz (RHEL) 8.7	Podman 4.2 (wartość domyślna)	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Czerwony Kapelusz (RHEL) 8.8	Podman 4.4.1	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 8.9	Podman 4.4.1	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Red Hat (RHEL) 9.0	Podman 4.4.1 (wartość domyślna)	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel. Pomoc techniczna kończy się w lutym 2024 r.
  Czerwony Kapelusz (RHEL) 9.1	Podman 4.4.1 (wartość domyślna)	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Czerwony kapelusz (RHEL) 9.2	Podman 4.4.1 (wartość domyślna)	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Czerwony kapelusz (RHEL) 9.3	Podman 4.6.1. (wartość domyślna)	Ta wersja RHEL nie ładuje automatycznie modułu ip_tables do jądra systemu Linux. Jeśli używasz tej wersji, zaplanuj ręczne załadowanie ip_tables przed zainstalowaniem aplikacji Tunnel. Kontenerów utworzonych przez podman w wersji 3 i starszych nie można używać za pomocą narzędzia Podman w wersji 4.2 lub nowszej. Jeśli uaktualniasz i zmieniasz kontenery, zaplanuj tworzenie nowych kontenerów i odinstalowywanie, a następnie ponowne instalowanie aplikacji Microsoft Tunnel.
  Ubuntu 20.04	Docker CE
  Ubuntu 22.04	Docker CE

  Ważna

  W kwietniu 2023 r. system Ubuntu zakończy wsparcie dla systemu Ubuntu 18.04. Po zakończeniu wsparcia przez system Ubuntu Intune zakończy również obsługę systemu Ubuntu 18.04 do użycia z rozwiązaniem Microsoft Tunnel. W celu uzyskania więcej informacji, zobacz następujący temat: https://wiki.ubuntu.com/Releases.

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

  # Urządzenia	# Procesory CPU	Pamięć GB	# Serwery	# Witryny	Miejsce na dysku 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

  Obsługa skaluje się liniowo. Mimo że każdy tunel Microsoft Tunnel obsługuje do 64 000 połączeń współbieżnych, poszczególne urządzenia mogą otwierać wiele połączeń.

• Procesor CPU: 64-bitowy procesor AMD/Intel.

• Zainstaluj platformę Docker CE lub Podman: w zależności od wersji systemu Linux używanej dla serwera Tunnel zainstaluj na serwerze jedną z następujących opcji:

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

  Program Microsoft Tunnel wymaga, aby platforma Docker lub podman na serwerze z systemem Linux zapewniała 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

    Powyższy link kieruje Cię do instrukcji pobierania i instalacji systemu CentOS. Użyj tych samych instrukcji dla programu RHEL 7.4. Wersja zainstalowana domyślnie w systemie RHEL 7.4 jest zbyt stara, aby obsługiwać usługę Microsoft Tunnel Gateway.

  • Zainstaluj aparat platformy Docker w systemie Ubuntu.

  • Zainstaluj narzędzie Podman w systemie Red Hat Enterprise Linux 8.4 lub nowszym (przewiń w dół do pozycji RHEL8).

    Te wersje programu RHEL nie obsługują platformy Docker. Zamiast tego te wersje używają narzędzia Podman, 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 są instalowane 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 usługi Red Hat.

    Uwaga

    Bezkorzeniowy podman: program Microsoft Tunnel obsługuje korzystanie z bezkorzeniowego kontenera Podman.

    Użycie bezkorzeniowego narzędzia Podman wymaga dodatkowych wymagań wstępnych do tych opisanych 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 Artykuł Configure Microsoft Tunnel for Intune use a rootless Podman container (Używanie kontenera podman bez roota) w artykule Configure Microsoft Tunnel for Intune (Konfigurowanie tunelu Microsoft Tunnel dla Intune).

• Certyfikat TLS (Transport Layer Security): serwer z systemem Linux wymaga zaufanego certyfikatu protokołu TLS w celu zabezpieczenia połączenia między urządzeniami a serwerem bramy tunelu. Podczas instalacji bramy tunelu należy dodać do serwera certyfikat protokołu TLS i pełny zaufany łańcuch certyfikatów.

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

  • Certyfikat protokołu TLS nie może mieć daty wygaśnięcia dłuższej niż dwa lata. Jeśli data jest dłuższa niż dwa lata, nie jest akceptowana na urządzeniach z systemem iOS.

  • Obsługa symboli wieloznacznych jest ograniczona. Na przykład *.contoso.com jest obsługiwana, ale cont*.com nie jest obsługiwana.

  • Podczas instalacji serwera bramy tunelu należy skopiować cały łańcuch zaufanych certyfikatów na serwer z systemem Linux. Skrypt instalacji udostępnia lokalizację, w której są kopiowane pliki certyfikatów, i monituje o to.

  • 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 Intune.

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

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

• Wersja protokołu TLS: domyślnie połączenia między klientami i serwerami programu Microsoft Tunnel używają protokołu TLS 1.3. Gdy protokół TLS 1.3 nie jest dostępny, połączenie może wrócić do korzystania z protokołu TLS 1.2.

Domyślna sieć mostka

Kontenery Podman i Docker używają sieci mostkowej do przekazywania ruchu przez hosta systemu Linux. Gdy sieć mostka kontenerów powoduje konflikt z siecią firmową, usługa Tunnel Gateway nie może pomyślnie skierować ruchu do tej sieci firmowej.

Domyślne sieci mostka to:

• Docker: 172.17.0.0/16
• Podman: 10.88.0.0/16

Aby uniknąć konfliktów, można ponownie skonfigurować zarówno podman, jak i platformę Docker w celu użycia określonej sieci mostka.

Ważna

Aby można było zmienić konfigurację sieci mostku, należy zainstalować serwer bramy tunelu.

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

Platforma 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 (routing między domenami bez klas), kompaktowy sposób reprezentowania adresu IP wraz ze skojarzoną maską podsieci i prefiksem routingu.

Ważna

Adres IP używany w poniższych krokach jest przykładem. Upewnij się, że używany adres IP nie powoduje konfliktu z siecią firmową.

1. Użyj następującego polecenia, aby zatrzymać kontener usługi 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 jest obecny na serwerze, użyj edytora plików, takiego jak vi lub nano , aby zmodyfikować plik. Uruchom edytor plików z uprawnieniami głównymi lub sudo:

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

   Poniższy przykład przedstawia strukturę pliku daemon.json ze zaktualizowanym ciągiem "bip": wpis, 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 jest obecny 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 usługi MS Tunnel Gateway: sudo mst-cli agent start ; sudo mst-cli server start

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

Zmienianie domyślnej sieci mostka używanej przez podman

Narzędzie 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 usługi 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ń głównych 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 "podsieci:" i "bramy:", zastępując wartości domyślne podman żądaną podsiecią i adresami bramy. Adres podsieci musi być określony w notacji CIDR.

   Wartości domyślne narzędzia Podman to:

   • podsieć: 10.88.0.0/16
   • brama: 10.88.0.1

4. Użyj następującego polecenia, aby ponownie uruchomić kontenery usługi 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ą narzędzia Podman w dokumentacji usługi Red Hat.

Sieci

• Włącz przekazywanie pakietów dla protokołu IPv4: każdy serwer z systemem Linux hostujący oprogramowanie serwera Tunnel musi mieć włączoną funkcję przekazywania adresów IP dla protokołu 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łączone i wartość 1 dla włączone:

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

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

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

  Aby zapewnić trwałe przekazywanie adresów IP, na każdym serwerze z systemem Linux edytuj plik /etc/sysctl.conf i usuń wiodący hashtag (#) z pliku #net.ipv4.ip_forward=1 , aby włączyć przekazywanie pakietów. Po 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 weszła w życie, należy ponownie uruchomić serwer lub uruchomić polecenie sysctl -p.

  Jeśli oczekiwany wpis nie znajduje się w pliku sysctl.conf, zapoznaj się z dokumentacją dotyczącą dystrybucji używanej do włączania przekazywania adresów IP. Zazwyczaj można edytować plik sysctl.conf , aby dodać brakujący wiersz na końcu pliku, aby trwale włączyć przekazywanie adresów IP.

• Skonfiguruj wiele kart sieciowych na serwer(opcjonalnie): Zalecamy użycie dwóch kontrolerów interfejsu sieciowego na serwer z systemem Linux w celu zwiększenia wydajności, chociaż użycie dwóch jest opcjonalne.

  • Karta sieciowa 1 — ta karta sieciowa obsługuje ruch z zarządzanych urządzeń i powinna znajdować się w sieci publicznej z publicznym adresem IP.  Ten adres IP to adres skonfigurowany w konfiguracji lokacji. Ten adres może reprezentować pojedynczy serwer lub moduł równoważenia obciążenia.

  • Karta sieciowa 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 maszyny wirtualne z systemem Linux oparte na chmurze mogą uzyskiwać dostęp do sieci lokalnej: jeśli uruchamiasz system Linux jako maszynę wirtualną w chmurze, upewnij się, że serwer może uzyskać dostęp do sieci lokalnej. Na przykład w przypadku maszyny wirtualnej na platformie Azure możesz użyć usługi Azure ExpressRoute lub czegoś podobnego, aby zapewnić dostęp. Usługa Azure ExpressRoute nie jest konieczna podczas uruchamiania serwera na lokalnej 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ą dostawców, aby uzyskać szczegółowe informacje o konfiguracji. Weź pod uwagę ruch sieciowy i porty zapory specyficzne dla Intune i microsoft tunnel.

  Serwer tunnel odpowiada na żądania GET za pomocą strony statycznej. Odpowiedź jest używana jako sonda przez moduły równoważenia obciążenia jako sposób sprawdzania żywotności serwera Tunnel. Odpowiedź jest statyczna i nie zawiera informacji poufnych.

• Obsługa sieci VPN dla aplikacji i domeny najwyższego poziomu — użycie sieci VPN dla aplikacji z wewnętrznym użyciem lokalnych domen najwyższego poziomu nie jest obsługiwane przez usługę Microsoft Tunnel.

Zapory

Domyślnie program Microsoft Tunnel i serwer używają następujących portów:

Porty przychodzące:

• TCP 443 — wymagany przez firmę Microsoft Tunnel.
• UDP 443 — wymagane przez firmę Microsoft Tunnel.
• TCP 22 — opcjonalnie. Używany do połączenia SSH/SCP z serwerem z systemem Linux.

Porty wychodzące:

• TCP 443 — wymagany do uzyskania dostępu do usług Intune. Wymagane przez platformę Docker lub podman do ściągnięcia 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 do obsługi konfiguracji.

Więcej wymagań:

• Aby uzyskać dostęp do usługi tokenu zabezpieczającego i usługi Azure Storage dla dzienników, zapewnij dostęp do następujących nazw FQDN:

  • Usługa tokenu zabezpieczającego: *.sts.windows.net
  • Usługa Azure Storage dla dzienników tuneli: *.blob.core.windows.net
  • Inne adresy URL punktu końcowego magazynu: *.blob.storage.azure.net

• Tunel ma te same wymagania co punkty końcowe sieci dla Microsoft Intune z dodatkiem portów TCP 22 i graph.microsoft.com.

• Skonfiguruj reguły zapory, aby obsługiwać konfiguracje opisane w konfiguracji reguł zapory klienta Rejestr Artefaktów Microsoft (MAR).

Serwera proxy

Możesz użyć serwera proxy z aplikacją Microsoft Tunnel.

Uwaga

Konfiguracje serwera proxy nie są obsługiwane w przypadku wersji systemu Android przed wersją 10. Aby uzyskać więcej informacji, zobacz VpnService.Builder w tej dokumentacji dla deweloperów systemu Android.

Uwaga

Upewnij się, że aplikacje LOB systemu Android obsługują bezpośredni serwer proxy lub automatyczną konfigurację serwera proxy (PAC) zarówno dla zarządzania urządzeniami przenośnymi, jak i zarządzania aplikacjami mobilnymi.

Uwaga

Znany problem: użytkownicy, którzy próbują zalogować się do przeglądarki Edge przy użyciu kont osobistych lub firmowych, mogą napotkać problemy po skonfigurowaniu automatycznej konfiguracji serwera proxy (PAC). W tym scenariuszu proces logowania może zakończyć się niepowodzeniem, uniemożliwiając użytkownikowi dostęp do zasobów wewnętrznych.

Obejścia: Aby rozwiązać ten problem, usługa Microsoft Tunnel oferuje tunelowanie podzielone jako opcję. Tunelowanie podzielone umożliwia użytkownikom uwzględnianie tylko tras, które wymagają serwera proxy, z wyłączeniem serwerów logowania i ścieżek uwierzytelniania z routingu przez tunel. To obejście zapewnia, że konfiguracja pacyfi nie ma wpływu na proces logowania, umożliwiając użytkownikowi dostęp do zasobów wewnętrznych i przeglądanie Internetu.

Bezpośredni serwer proxy jest również opcją bez tunelowania podzielonego, aby logowanie działało w przeglądarce Edge przy użyciu kont firmowych. Obejmuje to skonfigurowanie programu Microsoft Tunnel do używania bezpośredniego serwera proxy zamiast adresu URL PAC.

Jeśli w przeglądarce Edge nie jest wymagane logowanie użytkownika, funkcja PAC jest obsługiwana w przypadku normalnego przeglądania i uzyskiwania dostępu do zasobów wewnętrznych.

Następujące zagadnienia mogą pomóc w skonfigurowaniu serwera z systemem Linux i środowiska pod kątem powodzenia:

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 z systemem Linux i dodaj następujące wiersze:

  http_proxy=[address]
https_proxy=[address]

• Uwierzytelnione serwery proxy nie są obsługiwane.

• Serwer proxy nie może przeprowadzić przerwania i sprawdzenia, ponieważ serwer z systemem Linux używa uwierzytelniania wzajemnego protokołu TLS podczas nawiązywania połączenia z Intune.

• Skonfiguruj platformę Docker tak, aby używała serwera proxy do ściągania obrazów. W tym celu edytuj plik /etc/systemd/system/docker.service.d/http-proxy.conf na serwerze z systemem Linux i dodaj 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

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

Konfigurowanie serwera proxy ruchu wychodzącego dla narzędzia Podman

Następujące szczegóły mogą pomóc w skonfigurowaniu wewnętrznego serwera proxy podczas korzystania z narzędzia Podman:

• Uwierzytelnione serwery proxy nie są obsługiwane.

• Serwer proxy nie może przeprowadzić przerwania i sprawdzenia, ponieważ serwer z systemem Linux używa uwierzytelniania wzajemnego protokołu TLS podczas nawiązywania połączenia z 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ć następujące dwa wiersze. W następujących wierszach przykładowy adres:wpis portu to 10.10.10.1:3128 . Po dodaniu tych wierszy zastąp wartość 10.10.10.1:3128 wartościami dla 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 witryny Red Hat Customer Portal, możesz wyświetlić artykuł baza wiedzy skojarzony z tym rozwiązaniem. Zobacz Konfigurowanie zmiennych serwera proxy HTTP dla aplikacji Podman — Red Hat Customer Portal.

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

  Aby skonfigurować serwer proxy po zakończeniu konfiguracji bramy 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 punktu punktora.

  2. Edytuj /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:port10.10.10.1:3128 wartościami dla 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 funkcja RHEL używa protokołu SELinux. Ponieważ serwer proxy, który nie jest uruchamiany na porcie SELinux dla http_port_t , może wymagać dodatkowej konfiguracji, sprawdź użycie portów zarządzanych przez protokół SELinux pod kątem 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 wartości 3128 i nie znajduje się 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 uruchamiany na porcie SELinux dla http_port_t , jak w poprzednim przykładzie, musisz wprowadzić dodatkowe konfiguracje.

    Jeśli port serwera proxy nie znajduje się na liście http_port_t, sprawdź, czy port serwera proxy jest używany przez inną usługę. Użyj polecenia semanage , aby najpierw sprawdzić port używany przez serwer proxy, a następnie 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 sprawdzania usługi, która może korzystać z portu:

    

    • W tym przykładzie port, którego oczekujemy (3128), jest używany przez kalmary, które są usługą serwera proxy systemu operacyjnego. Zasady SELinux serwera proxy squid są częścią wielu typowych dystrybucji. Ponieważ kalmary używają portu 3128 (nasz przykładowy port), musimy zmodyfikować porty http_port_t i dodać port 3128, który ma być dozwolony za pośrednictwem protokołu SELinux dla serwera proxy używanego przez usługę 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 służącego do modyfikowania portu:

      

      Po uruchomieniu polecenia w celu 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 sprawdzania portu po zmodyfikowaniu portu:

      

      W tym przykładzie port 3128 jest teraz skojarzony z http_port-t i squid_port_t. Ten wynik jest oczekiwany. Jeśli port serwera proxy nie jest wyświetlany podczas uruchamiania portu semanage sudo -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"

Konfigurowanie narzędzia Podman do korzystania z serwera proxy do pobierania aktualizacji obrazów

Możesz skonfigurować narzędzie Podman do korzystania z serwera proxy do pobierania (ściągania) zaktualizowanych obrazów dla narzędzia Podman:

1. Na serwerze tunelu użyj wiersza polecenia, aby uruchomić następujące polecenie, aby otworzyć edytor pliku zastąpienia dla usługi Microsoft Tunnel:

   systemctl edit --force mstunnel_monitor

2. Dodaj następujące cztery wiersze do pliku. Zastąp każde wystąpienie [adresu] nazwą DN lub adresem serwera proxy, a następnie zapisz plik:

   [Service]
   Environment="http_proxy=[address]"
   Environment="https_proxy=[address]"
   

3. Następnie uruchom następujące polecenie w wierszu polecenia:

   systemctl restart mstunnel_monitor

4. Na koniec uruchom następujące polecenie w wierszu polecenia, aby potwierdzić, że konfiguracja zakończyła się pomyślnie:

   systemctl show mstunnel_monitor | grep http_proxy

   Jeśli konfiguracja zakończy się pomyślnie, wyniki będą podobne do następujących informacji:

   Environment="http_proxy=address:port"
   Environment="https_proxy=address:port"
   

Aktualizowanie serwera proxy używanego przez serwer tunelu

Aby zmienić konfigurację serwera proxy używaną przez hosta systemu Linux serwera tunelu, użyj następującej procedury:

1. Na serwerze tunelu edytuj /etc/mstunnel/env.sh i określ nowy serwer proxy.

2. Uruchom mst-cli install.

   To polecenie ponownie kompiluje kontenery przy użyciu nowych szczegółów serwera proxy. Podczas tego procesu zostanie wyświetlony monit o zweryfikowanie zawartości /etc/mstunnel/env.sh i upewnienie się, że certyfikat jest zainstalowany. Certyfikat powinien być już obecny z poprzedniej konfiguracji serwera proxy.

   Aby potwierdzić konfigurację i ukończyć konfigurację, wprowadź wartość tak.

Platformy

Urządzenia muszą być zarejestrowane w celu Intune, aby były obsługiwane w programie 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
  • profil służbowy Personally-Owned

  Uwaga

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

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

• Microsoft Entra uwierzytelnianie do aplikacji Tunnel przy użyciu nazwy użytkownika i hasła.
• Active Directory Federation Services uwierzytelniania (AD FS) do tunelu przy użyciu nazwy użytkownika i hasła.
• Obsługa aplikacji.
• Ręczne tunelowanie pełnego urządzenia przez aplikację Tunnel, w której użytkownik uruchamia sieć VPN i wybiera pozycję Połącz.
• Dzielenie tunelowania. Jednak reguły tunelowania podzielonego systemu iOS są ignorowane, gdy profil sieci VPN używa sieci VPN dla aplikacji.

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

• Android 10 lub nowszy
• iOS/iPadOS

Uprawnienia

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

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

Grupa uprawnień bramy Microsoft Tunnel Gateway udziela następujących uprawnień:

• Tworzenie — konfigurowanie serwerów i lokacji usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł tunelowania podzielonego. Lokacje to logiczne grupy wielu serwerów obsługujących usługę Microsoft Tunnel.

• Aktualizacja (modyfikowanie) — aktualizowanie konfiguracji i lokacji serwera usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł tunelowania podzielonego. Lokacje to logiczne grupy wielu serwerów obsługujących usługę Microsoft Tunnel.

• Usuń — usuń konfiguracje i lokacje serwera usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł tunelowania podzielonego. Lokacje to logiczne grupy wielu serwerów obsługujących usługę Microsoft Tunnel.

• Odczyt — wyświetlanie konfiguracji i lokacji serwera usługi Microsoft Tunnel Gateway. Konfiguracje serwera obejmują ustawienia zakresów adresów IP, serwerów DNS, portów i reguł tunelowania podzielonego. Lokacje to logiczne grupy wielu serwerów obsługujących usługę 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 skrypt, który działa na serwerze z systemem Linux i wykonuje następujące akcje:

• Sprawdza, czy konto Microsoft Entra używane do zainstalowania aplikacji Microsoft Tunnel ma role wymagane do ukończenia rejestracji.

• Potwierdza, że konfiguracja sieci umożliwia usłudze Microsoft Tunnel dostęp do wymaganych punktów końcowych firmy Microsoft.

• Sprawdza obecność modułu ip_tables na serwerze z systemem Linux. Ta kontrola została dodana do skryptu 11 lutego 2022 r., kiedy dodano obsługę RHEL 8.5. Program RHEL 8.5 później nie ładuje domyślnie modułu ip_tables. Jeśli brakuje ich po zainstalowaniu serwera z systemem Linux, należy ręcznie załadować moduł ip_tables.

Ważna

Narzędzie gotowości nie weryfikuje portów przychodzących, co jest typowym błędem konfiguracji. Po uruchomieniu narzędzia gotowości przejrzyj wymagania wstępne zapory i ręcznie zweryfikuj, czy zapory przekazują ruch przychodzący.

Narzędzie mst-readiness ma zależność od procesora JSON wiersza polecenia jq. Przed uruchomieniem narzędzia gotowości upewnij się, że zainstalowano narzędzie jq . Aby uzyskać informacje o sposobie pobierania i instalowania narzędzia jq, zapoznaj się z dokumentacją używanej wersji systemu Linux.

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

1. Pobierz najnowszą wersję narzędzia gotowości przy użyciu jednej z następujących metod:

   • Pobierz narzędzie bezpośrednio za pomocą przeglądarki internetowej. Przejdź do strony, aby https://aka.ms/microsofttunnelready pobrać plik o nazwie mst-readiness.

   • Zaloguj się do Microsoft Intune administracji> administracyjnej >dzierżawyMicrosoft Tunnel Gateway, wybierz kartę Serwery, wybierz pozycję Utwórz, aby otworzyć okienko Tworzenie serwera, a następnie wybierz pozycję Pobierz narzędzie gotowości.

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

     Aby na przykład użyć szczegółów narzędzia wget i dziennika w celu mst-readiness podczas pobierania, uruchom polecenie wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

   Skrypt można uruchomić z dowolnego serwera z systemem Linux, który jest w tej samej sieci co serwer, który planujesz zainstalować, co umożliwia administratorom sieci samodzielne rozwiązywanie problemów z siecią za pomocą skryptu.

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

   • sudo chmod +x ./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órego będzie używać tunel.
     • Sprawdza, czy wymagane porty są otwarte w zaporze.

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

3. Aby sprawdzić, czy konto używane do zainstalowania programu Microsoft Tunnel ma wymagane role i uprawnienia do ukończenia rejestracji, uruchom skrypt z następującym wierszem polecenia: ./mst-readiness account

   Skrypt monituje o użycie innej maszyny z przeglądarką internetową, która służy do uwierzytelniania w celu Tożsamość Microsoft Entra i Intune. Narzędzie zgłasza powodzenie lub błąd.

Aby uzyskać więcej informacji na temat tego narzędzia, zobacz Dokumentacja interfejsu wiersza polecenia w artykule referencyjnym dotyczącym programu Microsoft Tunnel.

Ręczne ładowanie ip_tables

Chociaż większość dystrybucji systemu Linux automatycznie ładuje moduł ip_tables, niektóre dystrybucje mogą nie. Na przykład program RHEL 8.5 domyślnie nie ładuje ip_tables.

Aby sprawdzić obecność tego modułu, uruchom najnowszą wersję narzędzia mst-readiness na serwerze z systemem Linux. 11 lutego 2022 r. do skryptu narzędzi gotowości dodano sprawdzanie ip_tables.

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

Ręczne ładowanie modułu ip_tables

W kontekście programu sudo uruchom następujące polecenia na serwerze z systemem 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 uruchomienia: /sbin/modprobe ip_tables

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

Ważna

Podczas aktualizowania serwera tunnel ręcznie załadowany moduł ip_tables może nie zostać utrwalone. Może to wymagać ponownego załadowania modułu po zakończeniu aktualizacji. Po zakończeniu aktualizacji serwera przejrzyj serwer pod kątem obecności modułu ip_tables.

Jeśli tabele nie są obecne, użyj poprzednich kroków, aby ponownie załadować moduł, wykonując dodatkowy krok w celu ponownego uruchomienia serwera po załadowaniu modułu.

Konfigurowanie systemu Linux do ładowania ip_tables podczas rozruchu

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

Ręczne ładowanie modułu usługi tun

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

Aby zweryfikować prezent modułu usługi tun na serwerze, uruchom polecenie: lsmod |grep tun

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

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

Ważna

Podczas aktualizowania serwera tunnel ręcznie załadowany moduł usługi tun może nie być trwały. Może to wymagać ponownego załadowania modułu po zakończeniu aktualizacji. Po zakończeniu aktualizacji serwera przejrzyj serwer pod kątem obecności modułu usługi tun .

Jeśli nie istnieje, użyj poprzednich kroków, aby ponownie załadować moduł, wykonując dodatkowy krok w celu ponownego uruchomienia serwera po załadowaniu modułu.

Konfigurowanie systemu Linux do ładowania usługi tun podczas rozruchu

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

Następne kroki

Konfigurowanie aplikacji Microsoft Tunnel