Teilen über

Voraussetzungen für Microsoft Tunnel in Intune

  • Artikel

Bevor Sie das Microsoft Tunnel-VPN-Gateway für Microsoft Intune installieren können, überprüfen und konfigurieren Sie die Voraussetzungen. Zu den Voraussetzungen gehört die Verwendung eines Linux-Servers, auf dem Container zum Hosten der Tunnel-Serversoftware ausgeführt werden. Planen Sie außerdem, Ihr Netzwerk, Ihre Firewalls und Proxys zur Unterstützung der Kommunikation für Microsoft Tunnel zu konfigurieren.

Auf hoher Ebene erfordert Microsoft Tunnel Folgendes:

  • Ein Azure-Abonnement.

  • Ein Microsoft Intune Plan 1-Abonnement.

    Hinweis

    Diese Voraussetzung gilt für Microsoft Tunnel und umfasst nicht Microsoft Tunnel für die Verwaltung mobiler Anwendungen, bei dem es sich um ein Intune-Add-On handelt, das ein Microsoft Intune Plan 2-Abonnement erfordert.

  • Ein Linux-Server, auf dem Container ausgeführt werden. Der Server kann lokal oder in der Cloud sein und unterstützt einen der folgenden Containertypen:

    • Podman für Red Hat Enterprise Linux (RHEL). Weitere Informationen finden Sie unter Linux-Serveranforderungen .
    • Docker für alle anderen Linux-Distributionen.

  • Ein TLS-Zertifikat (Transport Layer Security) für den Linux-Server, um Verbindungen zwischen Geräten und dem Tunnel Gateway-Server zu schützen.

  • Geräte, auf denen Android oder iOS/iPadOS ausgeführt wird.

Nach dem Konfigurieren der Voraussetzungen wird empfohlen, das Bereitschaftstool auszuführen, um zu überprüfen, ob Ihre Umgebung für eine erfolgreiche Installation gut konfiguriert ist.

In den folgenden Abschnitten werden die Voraussetzungen für Microsoft Tunnel und die Verwendung des Bereitschaftstools erläutert.

Hinweis

Tunnel und Global Secure Access (GSA) können nicht gleichzeitig auf demselben Gerät verwendet werden.

Linux-Server

Richten Sie einen linuxbasierten virtuellen Computer oder einen physischen Server ein, auf dem das Microsoft Tunnel-Gateway installiert werden soll.

Hinweis

Nur die in der folgenden Tabelle aufgeführten Betriebssysteme und Containerversionen werden unterstützt. Nicht aufgeführte Versionen werden nicht unterstützt. Erst nach dem Ausführen von Tests zur Überprüfung der Unterstützbarkeit werden neuere Versionen zu dieser Liste hinzugefügt. Halten Sie das Betriebssystem auch mit Sicherheitsupdates auf dem neuesten Stand.

  • Unterstützte Linux-Distributionen – In der folgenden Tabelle wird aufgeführt, welche Linux-Versionen für den Tunnel Server unterstützt werden, und welche Container sie benötigen:

    Verteilungsversion Containeranforderungen Überlegungen
    CentOS 7.4+ Docker CE Der Support endet im Juni 2024. CentOS 8+ wird nicht unterstützt
    Red Hat (RHEL) 7.4 und höher Docker CE Support endet Juni 2024
    Red Hat (RHEL) 8.6 Support endet Juni 2024 Podman 4.0 (Standard)
    Podman 3.0    		 Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.0 verwendet werden. Wenn Sie ein Upgrade von Containern von v3 auf v4.0 durchführen und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 8.7 Podman 4.2 (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 8.8 Podman 4.4.1 Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 8.9 Podman 4.4.1 Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 8.10 Podman 4.9.4-rhel (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 9.0 Support endet Juni 2024 Podman 4.4.1 (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.

    Der Support endet im Februar 2024.
    Red Hat (RHEL) 9.1 Podman 4.4.1 (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 9.2 Podman 4.4.1 (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 9.3 Podman 4.6.1. (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (Standard) Diese Version von RHEL lädt das ip_tables-Modul nicht automatisch in den Linux-Kernel. Wenn Sie diese Version verwenden, planen Sie, die ip_tables manuell zu laden, bevor Tunnel installiert wird.

    Container, die von Podman v3 und früher erstellt wurden , können nicht mit Podman v4.2 und höher verwendet werden. Wenn Sie Container aktualisieren und ändern, planen Sie, neue Container zu erstellen und Microsoft Tunnel zu deinstallieren und dann neu zu installieren.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    Wichtig

    Im April 2023 beendet Ubuntu die Unterstützung für Ubuntu 18.04. Mit dem Ende des Supports durch Ubuntu endet Intune auch die Unterstützung für Ubuntu 18.04 für die Verwendung mit Microsoft Tunnel. Weitere Informationen finden Sie unter https://wiki.ubuntu.com/Releases.

  • Größe des Linux-Servers anpassen:Verwenden Sie die folgenden Anleitungen, um die erwartete Verwendung zu erfüllen:

    Anzahl Geräte Anzahl CPUs Arbeitsspeicher (GB) Anzahl Server Anzahl Sites Speicherplatz auf dem Datenträger in 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

    Die Unterstützung wird linear skaliert. Während jeder Microsoft-Tunnel bis zu 64.000 gleichzeitige Verbindungen unterstützt, können einzelne Geräte mehrere Verbindungen öffnen.

  • CPU: 64-Bit-AMD/Intel-Prozessor.

  • Installieren von Docker CE oder Podman: Installieren Sie abhängig von der Linux-Version, die Sie für Ihren Tunnelserver verwenden, eine der folgenden Komponenten auf dem Server:

    • Docker Version 19.03 CE oder höher.
    • Podman Version 3.0 oder 4.0 abhängig von der Rhel-Version.

    Microsoft Tunnel erfordert Docker oder Podman auf dem Linux-Server, um Unterstützung für Container bereitzustellen. Container bieten eine konsistente Ausführungsumgebung, Integritätsüberwachung und proaktive Wiederherstellung sowie ein sauberes Upgradeszenario.

    Weitere Informationen zum Installieren und Konfigurieren von Docker oder Podman finden Sie in den folgenden Artikeln:

    • Installieren Sie die Docker-Engine unter CentOS oder Red Hat Enterprise Linux 7.

      Hinweis

      Der vorherige Link leitet Sie zum Download und den Installationsanweisungen für CentOS weiter. Verwenden Sie die gleichen Anweisungen für RHEL 7.4. Die standardmäßig auf RHEL 7.4 installierte Version ist zu alt, um Microsoft Tunnel Gateway zu unterstützen.

    • Installieren Sie die Docker-Engine unter Ubuntu.

    • Installieren Sie Podman unter Red Hat Enterprise Linux 8.4 und höher (scrollen Sie nach unten zu RHEL8).

      Diese Versionen von RHEL unterstützen Docker nicht. Stattdessen verwenden diese Versionen Podman, und Podman ist Teil eines Moduls namens „Containertools“. In diesem Kontext ist ein Modul ein Satz von U/Min-Paketen, die eine Komponente darstellen und in der Regel zusammen installiert werden. Ein typisches Modul enthält Pakete mit einer Anwendung, Pakete mit den anwendungsspezifischen Abhängigkeitsbibliotheken, Pakete mit der Dokumentation für die Anwendung und Pakete mit Hilfsprogrammen. Weitere Informationen finden Sie unter Einführung in Module in der Red Hat-Dokumentation.

      Hinweis

      Rootless Podman: Microsoft Tunnel unterstützt die Verwendung eines Rootless Podman-Containers.

      Die Verwendung von Podman ohne Stamm erfordert zusätzliche Voraussetzungen , die in diesem Artikel beschrieben sind, und die Verwendung einer geänderten Befehlszeile, wenn Sie das Tunnel-Installationsskript starten. Informationen zu den zusätzlichen Voraussetzungen und zur Installationsbefehlszeile finden Sie unter Verwenden eines Rootless Podman-Containers im Artikel Konfigurieren von Microsoft Tunnel für Intune.

  • TLS (Transport Layer Security)-Zertifikat:Der Linux-Server benötigt ein vertrauenswürdiges TLS-Zertifikat, um die Verbindung zwischen Geräten und dem Tunnel Gatewayserver zu sichern. Während der Installation des Tunnelgateways fügen Sie dem Server das TLS-Zertifikat und die vollständige vertrauenswürdige Zertifikatkette hinzu.

    • Der SAN (Subject Alternative Name) des TLS-Zertifikats, das Sie zum Schützen des Tunnel-Gatewayendpunkts verwenden, muss mit der IP-Adresse oder dem FQDN des Tunnel-Gatewayservers übereinstimmen.

    • Für das TLS-Zertifikat darf das Ablaufdatum maximal zwei Jahre betragen. Wenn das Datum länger als zwei Jahre ist, wird es auf iOS-Geräten nicht akzeptiert.

    • Die Unterstützung von Wildcards ist begrenzt. * .contoso.com wird beispielsweise unterstützt, aber cont*.com wird nicht unterstützt.

    • Während der Installation des Tunnel Gateway-Servers müssen Sie die gesamte vertrauenswürdige Zertifikatkette auf Ihren Linux-Server kopieren. Das Installationsskript gibt den Speicherort an, in den Sie die Zertifikatdateien kopieren müssen, und fordert Sie zum Kopieren auf.

    • Wenn Sie ein TLS-Zertifikat verwenden, das nicht öffentlich vertrauenswürdig ist, müssen Sie die gesamte Vertrauenskette mithilfe eines Intune vertrauenswürdigen Zertifikatprofils an Geräte pushen.

    • Das TLS-Zertifikat kann PEM- oder PFX-Format vorliegen.

    • Um die Integritätsprüfung für die TLS-Zertifikatssperrung zu unterstützen, stellen Sie sicher, dass vom Server aus auf die Adresse des Online Certificate Status Protocol (OCSP) oder die Zertifikatsperrliste (Certificate Revocation List, CRL) zugegriffen werden kann, wie sie vom TLS-Zertifikat definiert ist.

    • Konfigurieren Sie das Tunnelclientzertifikat mit einem Schlüssel, der mindestens 2048 Bit ist. Es wird empfohlen, größere Schlüssel zu verwenden, damit Ihre Bereitstellung für zukünftige und sich weiterentwickelnde SSL/TLS-Anforderungen durch verschiedene SSL/TLS-Bibliothekslösungen unterstützt wird.

      Tipp

      Überprüfen Sie in regelmäßigen Abständen die Anforderungen ihrer ausgewählten SSL/TLS-Bibliothek, um sicherzustellen, dass Ihre Infrastruktur und Zertifikate weiterhin unterstützt werden und den aktuellen Änderungen für diese Bibliothek entsprechen, und stellen Sie bei Bedarf Tunnel-Clientzertifikate erneut aus, um mit den sich entwickelnden Anforderungen Ihrer Lösungen auf dem neuesten Stand zu bleiben.

  • TLS-Version: Standardmäßig verwenden Verbindungen zwischen Microsoft Tunnel-Clients und -Servern TLS 1.3. Wenn TLS 1.3 nicht verfügbar ist, kann die Verbindung auf DIE Verwendung von TLS 1.2 zurückgreifen.

Standardbrückennetzwerk

Sowohl Podman- als auch Docker-Container verwenden ein Brückennetzwerk, um Datenverkehr über den Linux-Host weiterzuleiten. Wenn das Containerbrückennetzwerk mit einem Unternehmensnetzwerk in Konflikt tritt, kann Tunnel Gateway datenverkehr nicht erfolgreich an dieses Unternehmensnetzwerk weiterleiten.

Die Standardbrückennetzwerke sind:

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

Um Konflikte zu vermeiden, können Sie sowohl Podman als auch Docker neu konfigurieren, um ein von Ihnen angegebenes Brückennetzwerk zu verwenden.

Wichtig

Der Tunnel Gateway-Server muss installiert sein, bevor Sie die Brückennetzwerkkonfiguration ändern können.

Ändern des von Docker verwendeten Standardbrückennetzwerks

Docker verwendet die Datei /etc/docker/daemon.json, um eine neue Standard-IP-Adresse der Brücke zu konfigurieren. In der Datei muss die IP-Adresse der Brücke in CIDR-Notation (Classless inter-domain routing) angegeben werden. Dies ist eine kompakte Möglichkeit, eine IP-Adresse zusammen mit der zugeordneten Subnetzmaske und dem Routingpräfix darzustellen.

Wichtig

Die in den folgenden Schritten verwendete IP-Adresse ist ein Beispiel. Stellen Sie sicher, dass die von Ihnen verwendete IP-Adresse nicht mit Ihrem Unternehmensnetzwerk in Konflikt gerät.

  1. Verwenden Sie den folgenden Befehl, um den MS Tunnel Gateway-Container zu beenden: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Führen Sie als Nächstes den folgenden Befehl aus, um das vorhandene Docker-Brückengerät zu entfernen: sudo ip link del docker0

  3. Wenn die Datei /etc/docker/daemon.json auf Ihrem Server vorhanden ist, verwenden Sie einen Datei-Editor wie vi oder nano, um die Datei zu ändern. Führen Sie den Datei-Editor mit root- oder sudo-Berechtigungen aus:

    • Wenn der Eintrag "bip": mit einer IP-Adresse vorhanden ist, ändern Sie ihn, indem Sie eine neue IP-Adresse in der CIDR-Notation hinzufügen.
    • Wenn der Eintrag "bip": nicht vorhanden ist, müssen Sie sowohl den Wert "bip": als auch die neue IP-Adresse in der CIDR-Notation hinzufügen.

    Das folgende Beispiel zeigt die Struktur einer daemon.json-Datei mit einem aktualisierten Eintrag "bip", der eine geänderte IP-Adresse von "192.168.128.1/24" verwendet.

    Beispiel für „daemon.json“:

    {
"bip": "192.168.128.1/24"
}

  4. Wenn die Datei /etc/docker/daemon.json auf Ihrem Server nicht vorhanden ist, führen Sie einen Befehl ähnlich dem folgenden Beispiel aus, um die Datei zu erstellen und die Bridge-IP-Adresse zu definieren, die Sie verwenden möchten.

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

  5. Verwenden Sie den folgenden Befehl, um den MS Tunnel Gateway-Container zu starten: sudo mst-cli agent start ; sudo mst-cli server start

Weitere Informationen finden Sie unter Verwenden von Brückennetzwerken in der Docker-Dokumentation.

Ändern des von Podman verwendeten Standardbrückennetzwerks

Podman verwendet die Datei /etc/cni/net.d as 87-podman-bridge.conflist, um eine neue Standard-IP-Adresse der Brücke zu konfigurieren.

  1. Verwenden Sie den folgenden Befehl, um den MS Tunnel Gateway-Container zu beenden: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Führen Sie als Nächstes den folgenden Befehl aus, um das vorhandene Podman-Brückengerät zu entfernen: sudo ip link del cni-podman0

  3. Ändern Sie mit Stammberechtigungen und einem Datei-Editor wie vi oder nano/etc/cni/net.d als 87-podman-bridge.conflist , um die Standardwerte für "subnet:" und "gateway:" zu aktualisieren, indem Sie die Podman-Standardwerte durch ihre gewünschten Subnetz- und Gatewayadressen ersetzen. Die Subnetzadresse muss in CIDR-Notation angegeben werden.

    Die Podman-Standardwerte sind:

    • subnet: 10.88.0.0/16
    • gateway: 10.88.0.1

  4. Verwenden Sie den folgenden Befehl, um die MS Tunnel Gateway-Container neu zu starten: sudo mst-cli agent start ; sudo mst-cli server start

Weitere Informationen finden Sie unter Konfigurieren von Containernetzwerken mit Podman in der Red Hat-Dokumentation.

Linux-Systemüberwachung

Die Linux-Systemüberwachung kann dabei helfen, sicherheitsrelevante Informationen oder Sicherheitsverstöße auf einem Linux-Server zu identifizieren, der Microsoft Tunnel hostet. Die Linux-Systemüberwachung wird für Microsoft Tunnel empfohlen, ist aber nicht erforderlich. Um die Systemüberwachung verwenden zu können, muss auf einem Linux-Server das auditd-Paket auf installiert sein /etc/audit/auditd.conf.

Details zur Implementierung der Überwachung hängen von der verwendeten Linux-Plattform ab:

  • Red Hat: Versionen von Red Had Enterprise Linux 7 und höher installieren das überwachte Paket standardmäßig. Wenn das Paket jedoch nicht installiert ist, können Sie es über die folgende Befehlszeile auf dem Linux-Server installieren: sudo dnf install audit audispd-plugins

    In der Regel ist das überwachte Paket im Standardrepository jeder REHL-Version verfügbar.

    Weitere Informationen zur Verwendung der Systemüberwachung unter RHEL finden Sie unter Konfigurieren der Linux-Systemüberwachung mit auditd im Red Hat-Blog.

  • Ubuntu: Um die Systemüberwachung mit Ubuntu verwenden zu können, müssen Sie das überwachte Paket manuell installieren. Verwenden Sie dazu die folgende Befehlszeile auf dem Linux-Server: sudo apt install auditd audispd-plugins

    In der Regel ist das überwachte Paket im Standardrepository jeder Ubuntu-Version verfügbar.

    Weitere Informationen zur Verwendung der Systemüberwachung unter Ubuntu finden Sie unter Einrichten und Installieren von Auditd unter Ubuntu, einem Artikel, der auf der dev.to Website verfügbar ist, die ursprünglich auf kubefront.com veröffentlicht wurde.

Netzwerk

  • Erweitern der Paketweiterleitung für IPv4: Auf jedem Linux-Server, der die Tunnel-Serversoftware hostet, muss die IP-Weiterleitung für IPv4 aktiviert sein. Um den Status der IP-Weiterleitung zu überprüfen, führen Sie auf dem Server einen der folgenden generischen Befehle als root oder sudo aus. Beide Befehle geben den Wert 0 für deaktiviert und den Wert 1 für aktiviert zurück:

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

    Wenn diese Option nicht aktiviert ist, können Sie die IP-Weiterleitung vorübergehend aktivieren, indem Sie einen der folgenden generischen Befehle als root oder sudo auf dem Server ausführen. Diese Befehle können die IP-Weiterleitungskonfiguration ändern, bis der Server neu gestartet wird. Nach einem Neustart setzt der Server das IP-Weiterleitungsverhalten in den vorherigen Zustand zurück. Verwenden Sie für beide Befehle den Wert 1, um die Weiterleitung zu aktivieren. Der Wert 0 deaktiviert die Weiterleitung. In den folgenden Befehlsbeispielen wird der Wert 1 verwendet, um die Weiterleitung zu aktivieren:

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

    Um die IP-Weiterleitung dauerhaft zu aktivieren, bearbeiten Sie auf jedem Linux-Server die Datei /etc/sysctl.conf, indem Sie das führende Rautenzeichen (#) aus #net.ipv4.ip_forward=1 entfernen, um die Paketweiterleitung zu aktivieren. Nach der Bearbeitung sollte der Eintrag wie folgt aussehen:

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

    Damit diese Änderung wirksam wird, müssen Sie entweder den Server neu starten oder sysctl -p ausführen.

    Wenn der erwartete Eintrag nicht in der Datei „sysctl.conf“ vorhanden ist, konsultieren Sie die Dokumentation der von Ihnen verwendeten Distribution hinsichtlich Aktivierung der IP-Weiterleitung. In der Regel können Sie sysctl.conf bearbeiten und die fehlende Zeile am Ende der Datei hinzufügen, um die IP-Weiterleitung dauerhaft zu aktivieren.

  • Konfigurieren mehrerer NICs pro Server(Optional):Es wird empfohlen, zwei Netzwerkschnittstellencontroller (Network Interface Controller, NICs) pro Linux-Server zu verwenden, um die Leistung zu verbessern, obwohl die Verwendung von zwei optional ist.

    • NIC 1: Dieser NIC verarbeitet den Datenverkehr von ihren verwalteten Geräten und sollte sich in einem öffentlichen Netzwerk mit öffentlicher IP-Adresse befinden.  Diese IP-Adresse ist die Adresse, die Sie in der Sitekonfiguration konfigurieren. Diese Adresse kann einen einzelnen Server oder ein Lastenausgleichsmodul darstellen.

    • Nic 2: Dieser NIC verarbeitet den Datenverkehr zu Ihren lokalen Ressourcen und sollte sich in Ihrem privaten internen Netzwerk ohne Netzwerksegmentierung befinden.

  • Sicherstellen, dass cloudbasierte Linux-VMs auf Ihr lokales Netzwerk zugreifen können: Wenn Sie Linux als virtuellen Computer in einer Cloud ausführen, stellen Sie sicher, dass der Server auf Ihr lokales Netzwerk zugreifen kann. Für eine VM in Azure können Sie beispielsweise Azure ExpressRoute oder ein ähnliches Tool verwenden, um Zugriff bereitzustellen. Azure ExpressRoute ist nicht erforderlich, wenn Sie den Server lokal auf einer VM ausführen.

  • Lastenausgleichsmodule(optional): Wenn Sie sich für das Hinzufügen eines Lastenausgleichs entscheiden, finden Sie konfigurationsdetails in der Dokumentation Ihrer Anbieter. Berücksichtigen Sie den Netzwerkverkehr und die Firewallports, die für Intune und die Microsoft Tunnel-Instanz spezifisch sind.

    Der Tunnelserver antwortet auf GET-Anforderungen mit einer statischen Seite. Die Antwort wird von Lastenausgleichsmodulen als Test verwendet, um die Gültigkeit des Tunnelservers zu überprüfen. Die Antwort ist statisch und enthält keine vertraulichen Informationen.

  • Pro-App-VPN und Domänenunterstützung auf oberster Ebene : Die Verwendung pro App-VPN mit interner Verwendung lokaler Domänen der obersten Ebene wird von Microsoft Tunnel nicht unterstützt.

Firewall

Standardmäßig verwenden die Microsoft Tunnel-Instanz und der Server die folgenden Ports:

Ports für eingehenden Datenverkehr:

  • TCP 443 – für Microsoft Tunnel erforderlich.
  • UDP 443 – für Microsoft Tunnel erforderlich.
  • TCP 22 – optional. Wird für SSH/SCP zum Linux-Server verwendet.

Ports für ausgehenden Datenverkehr:

  • TCP 443 – für den Zugriff auf Intune-Dienste erforderlich. Für Docker oder Podman zum Abrufen von Bildern erforderlich.

Beim Erstellen der Serverkonfiguration für den Tunnel können Sie einen anderen Port als den Standardport 443 angeben. Wenn Sie einen anderen Port angeben, konfigurieren Sie die Firewalls so, dass Ihre Konfiguration unterstützt wird.

Weitere Anforderungen:

Um auf den Sicherheitstokendienst und den Azure-Speicher für Protokolle zuzugreifen, gewähren Sie Zugriff auf die folgenden FQDNs:

  • Sicherheitstokendienst: *.sts.windows.net
  • Azure-Speicher für Tunnelprotokolle: *.blob.core.windows.net
  • Andere Speicherendpunkt-URLs: *.blob.storage.azure.net
  • Microsoft Intune:*.manage.microsoft.com
  • Microsoft-Authentifizierung: login.microsoftonline.com
  • Microsoft Graph: graph.microsoft.com
  • Konfigurieren Sie Firewallregeln, um die konfigurationen zu unterstützen, die in Microsoft-Artefaktregistrierung (MAR) Client Firewall Rules Configuration (MAR) beschrieben sind.

Proxy

Sie können einen Proxyserver mit Microsoft Tunnel verwenden.

Hinweis

Proxyserverkonfigurationen werden bei Android-Versionen vor Version 10 nicht unterstützt. Weitere Informationen finden Sie unter VpnService.Builder in dieser Android-Entwicklerdokumentation.

Hinweis

Stellen Sie sicher, dass Ihre Android-Branchenanwendungen sowohl für MDM als auch für MAM den direkten Proxy oder die automatische Proxykonfiguration (Proxy Auto-Configuration, PAC) unterstützen.

Hinweis

Bekanntes Problem: Benutzer, die versuchen, sich mit ihrem persönlichen konto oder ihrem Unternehmenskonto bei Edge anzumelden, können probleme auftreten, wenn eine Proxy Auto-Configuration (PAC) konfiguriert ist. In diesem Szenario schlägt der Anmeldevorgang möglicherweise fehl, wodurch verhindert wird, dass der Benutzer auf interne Ressourcen zugreifen kann.

Problemumgehungen: Um dieses Problem zu beheben, bietet Microsoft Tunnel split tunneling als Option an. Split Tunneling ermöglicht benutzern, nur die Routen einzuschließen, die einen Proxy erfordern, während Anmeldeserver und Authentifizierungspfade vom Routing durch den Tunnel ausgeschlossen werden. Diese Problemumgehung stellt sicher, dass der Anmeldevorgang nicht von der PAC-Konfiguration betroffen ist, sodass der Benutzer auf interne Ressourcen zugreifen und im Internet surfen kann.

Der direkte Proxy ist auch eine Option ohne geteiltes Tunneln, damit die Anmeldung in Edge mithilfe von Unternehmenskonten funktioniert. Dies umfasst die Konfiguration von Microsoft Tunnel für die Verwendung eines direkten Proxys anstelle einer PAC-URL.

Wenn keine Benutzeranmeldung bei Edge erforderlich ist, wird PAC für das normale Browsen und den Zugriff auf interne Ressourcen unterstützt.

Die folgenden Überlegungen können Ihnen helfen, den Linux-Server und Ihre Umgebung erfolgreich zu konfigurieren:

Konfigurieren eines ausgehenden Proxys für Docker

  • Wenn Sie einen internen Proxy verwenden, müssen Sie den Linux-Host möglicherweise mithilfe von Umgebungsvariablen so konfigurieren, dass der Proxyserver verwendet wird. Um die Variablen zu verwenden, bearbeiten Sie die Datei /etc/environment auf dem Linux-Server, und fügen Sie die folgenden Zeilen hinzu:

    http_proxy=[address]
    https_proxy=[address]

  • Authentifizierte Proxys werden nicht unterstützt.

  • Der Proxy kann keine Unterbrechungen und Überprüfungen durchführen, da der Linux-Server beim Herstellen einer Verbindung mit Intune die gegenseitige TLS-Authentifizierung verwendet.

  • Konfigurieren Sie Docker so, dass der Proxy zum Pullen von Images verwendet wird. Bearbeiten Sie hierzu die Datei /etc/systemd/System/docker.service.d/http-proxy.conf auf dem Linux-Server, und fügen Sie die folgenden Zeilen hinzu:

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

    Hinweis

    Microsoft Tunnel unterstützt keine Microsoft Entra Anwendungsproxy oder ähnliche Proxylösungen.

Konfigurieren eines ausgehenden Proxys für Podman

Die folgenden Details helfen Ihnen beim Konfigurieren eines internen Proxys bei der Verwendung von Podman:

  • Authentifizierte Proxys werden nicht unterstützt.

  • Der Proxy kann keine Unterbrechungen und Überprüfungen durchführen, da der Linux-Server beim Herstellen einer Verbindung mit Intune die gegenseitige TLS-Authentifizierung verwendet.

  • Podman liest HTTP-Proxyinformationen, die in /etc/profile.d/http_proxy.shgespeichert sind. Wenn diese Datei nicht auf Ihrem Server vorhanden ist, erstellen Sie sie. Bearbeiten Sie http_proxy.sh, um die folgenden beiden Zeilen hinzuzufügen. In den folgenden Zeilen ist 10.10.10.1:3128 ein Beispiel für „address:port entry“. Wenn Sie diese Zeilen hinzufügen, ersetzen Sie 10.10.10.1:3128 durch die Werte für Ihre Proxy-IP address:port:

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

    Wenn Sie Zugriff auf das Red Hat-Kundenportal haben, können Sie den Knowledge Base-Artikel anzeigen, der dieser Lösung zugeordnet ist. Weitere Informationen finden Sie unter Einrichten von HTTP-Proxyvariablen für Podman – Red Hat Customer Portal.

  • Wenn Sie diese beiden Zeilen http_proxy.sh hinzufügen, bevor Sie Microsoft Tunnel Gateway installieren, indem Sie mstunnel-setup ausführen, konfiguriert das Skript automatisch die Proxyumgebungsvariablen des Tunnelgateways in /etc/mstunnel/env.sh.

    Führen Sie die folgenden Aktionen aus, um einen Proxy zu konfigurieren, nachdem die Einrichtung des Microsoft Tunnel-Gateways abgeschlossen ist:

    1. Ändern oder erstellen Sie die Datei /etc/profile.d/http_proxy.sh, und fügen Sie die beiden Zeilen aus dem vorherigen Aufzählungspunkt hinzu.

    2. Bearbeiten Sie /etc/mstunnel/env.sh, und fügen Sie am Ende der Datei die folgenden beiden Zeilen hinzu. Ersetzen Sie wie in den vorherigen Zeilen den Beispielwert address:port von 10.10.10.1:3128 durch die Werte für Ihre Proxy-IP-Adresse :Port:

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

    3. Tunnelgatewayserver neu starten: mst-cli server restart ausführen

    Beachten Sie, dass RHEL SELinux verwendet. Da ein Proxy, der nicht auf einem SELinux-Port für http_port_t ausgeführt wird, eine zusätzliche Konfiguration erfordern kann, überprüfen Sie die Verwendung von verwalteten SELinux-Ports für HTTP. Führen Sie den folgenden Befehl aus, um die Konfigurationen anzuzeigen: sudo semanage port -l | grep "http_port_t"

    Beispiel für die Ergebnisse des Portüberprüfungsbefehls. In diesem Beispiel verwendet der Proxy 3128 und ist nicht aufgeführt:

    Screenshot, der die Ergebnisse der Portüberprüfung anzeigt.

    • Wenn Ihr Proxy auf einem der SELinux-Ports für http_port_t ausgeführt wird, können Sie mit dem Tunnelgateway-Installationsvorgang fortfahren.

    • Wenn Ihr Proxy nicht wie im vorherigen Beispiel auf einem SELinux-Port für http_port_t ausgeführt wird, müssen Sie zusätzliche Konfigurationen vornehmen.

      Wenn Ihr Proxyport nicht für http_port_t aufgeführt ist, überprüfen Sie, ob der Proxyport von einem anderen Dienst verwendet wird. Verwenden Sie den Semanage-Befehl , um zuerst den Port zu überprüfen, den Ihr Proxy verwendet, und später, falls erforderlich, um ihn zu ändern. Führen Sie Folgendes aus, um den von Ihrem Proxy verwendeten Port zu überprüfen: sudo semanage port -l | grep "your proxy port"

      Beispiel für die Ergebnisse der Überprüfung auf einen Dienst, der den Port verwenden kann:

      Screenshot, der die Ergebnisse der Dienstüberprüfung anzeigt.

      • In dem Beispiel wird der erwartete Port (3128) von einem Squid, einem OSS-Proxydienst. Die Squid Proxy-SELinux-Richtlinien sind Teil vieler gängiger Distributionen. Da Squid den Port 3128 (unser Beispielport) verwendet, müssen wir die http_port_t Ports ändern und Port 3128 so hinzufügen, dass er über SELinux für den vom Tunnel verwendeten Proxy zugelassen ist. Führen Sie den folgenden Befehl aus, um die Portanwendung zu ändern: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        Beispiel für den Befehl zum Ändern des Ports:

        Screenshot, der ein Beispiel für den Portänderungsbefehl zeigt.

        Führen Sie nach dem Ausführen des Befehls zum Ändern des Ports den folgenden Befehl aus, um zu überprüfen, ob der Port von einem anderen Dienst verwendet wird: sudo semanage port -l | grep "your proxy port"

        Beispiel für den Befehl zum Überprüfen des Ports nach dem Ändern des Ports:

        Screenshot der Portüberprüfung nach der Änderung.

        In diesem Beispiel ist Port 3128 jetzt sowohl http_port-t als auch squid_port_tzugeordnet. Dieses Ergebnis wird erwartet. Wenn Ihr Proxyport beim Ausführen des Befehks sudo semanage port -l | grep "your_proxy_port" nicht aufgeführt ist, führen Sie den Befehl aus, um den Port erneut zu ändern, ersetzen Sie jedoch -m im Befehl semanage durch -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Konfigurieren von Podman für die Verwendung des Proxys zum Herunterladen von Imageupdates

Sie können Podman so konfigurieren, dass der Proxy zum Herunterladen (Pullen) aktualisierter Images für Podman verwendet wird:

  1. Verwenden Sie auf dem Tunnelserver eine Eingabeaufforderung, um den folgenden Befehl auszuführen, um einen Editor für die Überschreibungsdatei für den Microsoft Tunnel-Dienst zu öffnen:

    systemctl edit --force mstunnel_monitor

  2. Fügen Sie der Datei die folgenden drei Zeilen hinzu. Ersetzen Sie alle instance von [address] durch Ihren Proxy-DN oder Ihre Proxyadresse, und speichern Sie dann die Datei:

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

  3. Führen Sie als Nächstes an der Eingabeaufforderung Folgendes aus:

    systemctl restart mstunnel_monitor

  4. Führen Sie abschließend an der Eingabeaufforderung Folgendes aus, um zu überprüfen, ob die Konfiguration erfolgreich war:

    systemctl show mstunnel_monitor | grep http_proxy

    Wenn die Konfiguration erfolgreich ist, ähneln die Ergebnisse den folgenden Informationen:

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

Den Proxyserver aktualisieren, der vom Tunnelserver verwendet wird

So ändern Sie die Proxy-Server-Konfiguration, die vom Linux-Host des Tunnelservers verwendet wird:

  1. Bearbeiten Sie auf dem Tunnelserver /etc/mstunnel/env.sh und geben Sie den neuen Proxyserver an.

  2. Ausführen mst-cli install.

    Mit diesem Befehl werden die Container mit den neuen Proxy-Server-Details neu erstellt. Während dieses Vorgangs werden Sie aufgefordert, den Inhalt von /etc/mstunnel/env.sh zu überprüfen und sicherzustellen, dass das Zertifikat installiert ist. Das Zertifikat sollte bereits von der vorherigen Proxy-Server-Konfiguration vorhanden sein.

    Um beides zu bestätigen und die Konfiguration abzuschließen, geben Sie Ja ein.

Plattformen

Geräte müssen bei Intune registriert werden, um von Microsoft Tunnel unterstützt zu werden. Nur folgende Geräteplattformen werden unterstützt:

  • iOS/iPadOS

  • Android Enterprise:

    • Vollständig verwaltet
    • Unternehmenseigenes Arbeitsprofil
    • Persönliches Arbeitsprofil

    Hinweis

    Dedizierte Android Enterprise-Geräte werden vom Microsoft Tunnel nicht unterstützt.

Alle Plattformen unterstützen die folgenden Funktionen:

  • Microsoft Entra die Authentifizierung für den Tunnel mit Benutzername und Kennwort.
  • Active Directory-Verbunddienste (AD FS)-Authentifizierung beim Tunnel mit Benutzername und Kennwort.
  • Unterstützung pro App.
  • Manueller vollständiger Gerätetunnel über eine Tunnel-App, bei dem der Benutzer das VPN startet und Verbinden auswählt.
  • Split Tunneling. Unter iOS werden Split Tunneling-Regeln jedoch ignoriert, wenn Ihr VPN-Profil ein VPN pro App verwendet.

Unterstützung für einen Proxy ist auf die folgenden Plattformen beschränkt:

  • Android 10 und höher
  • iOS/iPadOS

Berechtigungen

Damit Benutzer Microsoft Tunnel verwalten können, müssen sie über die Berechtigungen verfügen, die in der Berechtigungsgruppe Microsoft Tunnel-Gateway in Intune enthalten sind. Standardmäßig verfügen Intune-Administratoren und Microsoft Entra-Administratoren über diese Berechtigungen. Sie können diese auch benutzerdefinierten Rollen hinzufügen, die Sie für Ihren Intune-Mandanten erstellen.

Erweitern Sie beim Konfigurieren einer Rolle auf der Seite Berechtigungen die Option Microsoft Tunnel-Gateway, und wählen Sie die Berechtigungen aus, die erteilt werden sollen.

Screenshot der Tunnelgatewayberechtigungen im Microsoft Intune Admin Center.

Die Berechtigungsgruppe „Microsoft Tunnel-Gateway“ erteilt die folgenden Berechtigungen:

  • Erstellen: Benutzer können Server und Standorte für Microsoft Tunnel-Gateways konfigurieren. Zu den Serverkonfigurationen zählen Einstellungen für IP-Adressbereiche, DNS-Server, Ports und Split-Tunneling-Regeln. Standorte sind logische Gruppierungen mehrerer Server, die Microsoft Tunnel unterstützen.

  • Aktualisieren (Bearbeiten): Benutzer können Serverkonfigurationen und Standorte für Microsoft Tunnel-Gateways aktualisieren. Zu den Serverkonfigurationen zählen Einstellungen für IP-Adressbereiche, DNS-Server, Ports und Split-Tunneling-Regeln. Standorte sind logische Gruppierungen mehrerer Server, die Microsoft Tunnel unterstützen.

  • Löschen: Benutzer können Serverkonfigurationen und Standorte für Microsoft Tunnel-Gateways löschen. Zu den Serverkonfigurationen zählen Einstellungen für IP-Adressbereiche, DNS-Server, Ports und Split-Tunneling-Regeln. Standorte sind logische Gruppierungen mehrerer Server, die Microsoft Tunnel unterstützen.

  • Lesen: Benutzer können Serverkonfigurationen und Standorte für Microsoft Tunnel-Gateways anzeigen. Zu den Serverkonfigurationen zählen Einstellungen für IP-Adressbereiche, DNS-Server, Ports und Split-Tunneling-Regeln. Standorte sind logische Gruppierungen mehrerer Server, die Microsoft Tunnel unterstützen.

Ausführen des Bereitschaftstools

Bevor Sie mit einer Serverinstallation beginnen, empfehlen wir Ihnen, die neueste Version des mst-Readiness-Tools herunterzuladen und auszuführen. Das Tool ist ein Skript, das auf Ihrem Linux-Server ausgeführt wird und die folgenden Aktionen durchführt:

  • Überprüft, ob das Microsoft Entra Konto, das Sie zum Installieren von Microsoft Tunnel verwenden, über die erforderlichen Rollen verfügt, um die Registrierung abzuschließen.

  • Es bestätigt, dass die Netzwerkkonfiguration es Microsoft Tunnel ermöglicht, auf die erforderlichen Microsoft-Endpunkte zuzugreifen.

  • Überprüft, ob das ip_tables-Modul auf dem Linux-Server vorhanden ist. Diese Überprüfung wurde dem Skript am 11. Februar 2022 hinzugefügt, als die Unterstützung für RHEL 8.5 hinzugefügt wurde. RHEL 8.5 später lädt das ip_tables Modul standardmäßig nicht. Wenn sie nach der Installation des Linux-Servers fehlen, müssen Sie das ip_tables-Modul manuell laden.

Wichtig

Das Bereitschaftstool überprüft keine eingehenden Ports, was eine häufige Fehlkonfiguration ist. Sobald das Bereitschaftstool ausgeführt wird, überprüfen Sie die Firewallvoraussetzungen, und validieren Sie manuell Ihre Firewalls, die eingehenden Datenverkehr weiterleiten.

Das mst-readiness-Tool weist eine Abhängigkeit von jq auf, einem Befehlszeilen-JSON-Prozessor. Bevor Sie das Bereitschaftstool ausführen, stellen Sie sicher, dass jq installiert ist. Informationen dazu, wie Sie jq abrufen und installieren, finden Sie in der Dokumentation zu der von Ihnen verwendete Version von Linux.

So verwenden Sie das Bereitschaftstool:

  1. Holen Sie sich die neueste Version des Bereitschaftstools, indem Sie eine der folgenden Methoden verwenden:

    • Laden Sie das Tool direkt mithilfe eines Webbrowsers herunter. Navigieren Sie zu https://aka.ms/microsofttunnelready, um eine Datei namens mst-readiness herunterzuladen.

    • Melden Sie sich bei Microsoft Intune Admin Center>Mandantenverwaltung>Microsoft Tunnel Gateway an, wählen Sie die Registerkarte Server aus, wählen Sie Erstellen aus, um den Bereich Server erstellen zu öffnen, und wählen Sie dann Tool zur Downloadbereitschaft aus.

    • Verwenden Sie einen Linux-Befehl, um das Bereitschaftstool direkt abzurufen. Beispielsweise können Sie wget oder curl verwenden, um den Link https://aka.ms/microsofttunnelready zu öffnen.

      Um etwa wget zu verwenden und Details während des Downloads in mst-readiness zu protokollieren, führen Sie wget --output-document=mst-readiness https://aka.ms/microsofttunnelready aus.

    Das Skript kann von jedem Linux-Server ausgeführt werden, der sich im selben Netzwerk wie der Server befindet, den Sie installieren möchten. Dadurch können Netzwerkadministratoren das Skript verwenden, um Netzwerkprobleme unabhängig voneinander zu beheben.

  2. Führen Sie das Skript mit den folgenden Befehlen aus, um ihre Netzwerk- und Linux-Konfiguration zu überprüfen. Mit diesen Befehlen werden die Ausführungsberechtigungen für das Skript festgelegt, überprüft, ob tunnel eine Verbindung mit den richtigen Endpunkten herstellen kann, und überprüfen Sie dann, ob von Tunnel verwendete Hilfsprogramme vorhanden sind:

    • sudo ./mst-readiness

    • sudo ./mst-readiness network – Dieser Befehl führt die folgenden Aktionen aus und meldet dann Erfolg oder Fehler für beide:

      • Es versucht, eine Verbindung mit jedem Microsoft-Endpunkt herzustellen, den der Tunnel verwenden wird.
      • Es überprüft, ob die erforderlichen Ports in der Firewall geöffnet sind.

    • sudo ./mst-readiness utils – Dieser Befehl überprüft, ob von Tunnel verwendete Hilfsprogramme wie Docker oder Podman und ip_tables verfügbar sind.

  3. Führen Sie das Skript mit der folgenden Befehlszeile aus, um zu überprüfen, ob das Konto, das Sie zum Installieren von Microsoft Tunnel verwenden, über die erforderlichen Rollen und Berechtigungen verfügt, um die Registrierung abzuschließen: ./mst-readiness account

    Das Skript fordert Sie auf, einen anderen Computer mit einem Webbrowser zu verwenden, den Sie zum Authentifizieren für Microsoft Entra ID und zum Intune verwenden. Das Tool meldet einen Erfolg oder einen Fehler.

Weitere Informationen zu diesem Tool finden Sie unter Referenz für mst-cli im Referenzartikel für den Microsoft Tunnel-Artikel.

Laden Sie ip_tables manuell

Während die meisten Linux-Distributionen das ip_tables-Modul automatisch laden, ist dies bei einigen Distributionen möglicherweise nicht der Fall. Beispielsweise lädt RHEL 8.5 die ip_tables standardmäßig nicht.

Um zu überprüfen, ob dieses Modul vorhanden ist, führen Sie die neueste Version des mst-readiness-Tools auf dem Linux-Server aus. Die Überprüfung auf ip_tables wurde dem Skript des Bereitschaftstools am 11. Februar 2022 hinzugefügt.

Wenn das Modul nicht vorhanden ist, wird das Tool bei der ip_tables Modulüberprüfung beendet. In diesem Szenario können Sie die folgenden Befehle ausführen, um das Modul manuell zu laden.

Das ip_tables-Modul manuell laden

Führen Sie im Kontext von Sudo die folgenden Befehle auf Ihrem Linux-Server aus:

  1. Überprüfen Sie, ob ip_tables auf dem Server vorhanden sind: lsmod |grep ip_tables

  2. Wenn ip_tables nicht vorhanden ist, führen Sie Folgendes aus, um das Modul sofort ohne Neustart in den Kernel zu laden: /sbin/modprobe ip_tables

  3. Führen Sie die Überprüfung erneut aus, um zu bestätigen, dass die Tabellen jetzt geladen sind: lsmod |grep ip_tables

Wichtig

Beim Aktualisieren des Tunnelservers wird ein manuell geladenes ip_tables-Modul möglicherweise nicht beibehalten. Dann müssen Sie das Modul nach Abschluss des Updates eventuell erneut laden. Überprüfen Sie nach Abschluss des Serverupdates, ob das ip_tables-Modul vorhanden ist.

Wenn die Tabellen nicht vorhanden sind, führen Sie die vorherigen Schritte aus, um das Modul neu zu laden, und führen Sie den zusätzlichen Schritt aus, um den Server nach dem Laden des Moduls neu zu starten.

Linux so konfigurieren, dass ip_tables beim Start geladen wird

Führen Sie im Kontext von sudo den folgenden Befehl auf Ihrem Linux-Server aus, um eine Konfigurationsdatei zu erstellen, die die ip_tables während des Startvorgangs in den Kernel lädt: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Manuelles Laden des Tun-Moduls

Microsoft Tunnel erfordert das Tun-Modul , aber einige Linux-Distributionen laden das Modul tun nicht standardmäßig.

Führen Sie Folgendes aus, um die Gegenwart des tun-Moduls auf dem Server zu überprüfen:lsmod |grep tun

  1. Wenn tun nicht vorhanden ist, führen Sie Folgendes aus, um das Modul sofort ohne Neustart in den Kernel zu laden: /sbin/modprobe tun

  2. Führen Sie die Überprüfung erneut aus, um zu bestätigen, dass das Modul "tun " jetzt geladen ist: lsmod |grep tun

Wichtig

Beim Aktualisieren des Tunnelservers wird ein manuell geladenes Tun-Modul möglicherweise nicht beibehalten. Dies kann erfordern, dass Sie das Modul nach Abschluss des Updates erneut laden. Überprüfen Sie nach Abschluss des Serverupdates den Server auf das Vorhandensein des tun-Moduls .

Wenn sie nicht vorhanden sind, führen Sie die vorherigen Schritte aus, um das Modul neu zu laden, und führen Sie den zusätzlichen Schritt aus, um den Server nach dem Laden des Moduls neu zu starten.

Konfigurieren von Linux zum Laden von Tun beim Start

Führen Sie im Kontext von sudo den folgenden Befehl auf Ihrem Linux-Server aus, um eine Konfigurationsdatei zu erstellen, die tun während des Startvorgangs in den Kernel lädt: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Nächste Schritte

Konfigurieren von Microsoft Tunnel