Dela via

Krav för Microsoft Tunnel i Intune

  • Artikel

Innan du kan installera Vpn-gatewayen för Microsoft Tunnel för Microsoft Intune bör du granska och konfigurera förhandskraven. Kraven omfattar användning av en Linux-server som kör containrar som värd för tunnelserverprogramvaran. Planera även att konfigurera ditt nätverk, brandväggar och proxyservrar för att stödja kommunikation för Microsoft Tunnel.

På en hög nivå kräver Microsoft Tunnel:

  • En Azure-prenumeration.

  • En prenumeration på Microsoft Intune plan 1.

    Obs!

    Den här förutsättningen gäller för Microsoft Tunnel och omfattar inte Microsoft Tunnel för hantering av mobilprogram, vilket är ett Intune tillägg som kräver en prenumeration på Microsoft Intune Plan 2.

  • En Linux-server som kör containrar. Servern kan finnas lokalt eller i molnet och har stöd för någon av följande containertyper:

  • Ett TLS-certifikat (Transport Layer Security) för Linux-servern för att skydda anslutningar från enheter till Tunnel Gateway-servern.

  • Enheter som kör Android eller iOS/iPadOS.

När du har konfigurerat förutsättningarna rekommenderar vi att du kör beredskapsverktyget för att kontrollera att din miljö är väl konfigurerad för en lyckad installation.

I följande avsnitt beskrivs kraven för Microsoft Tunnel och ger vägledning om hur du använder beredskapsverktyget.

Obs!

Tunnel och global säker åtkomst (GSA) kan inte användas samtidigt på samma enhet.

Linux-server

Konfigurera en Linux-baserad virtuell dator eller en fysisk server där Du kan installera Microsoft Tunnel Gateway.

Obs!

Endast de operativsystem och containerversioner som anges i följande tabell stöds. Versioner som inte visas stöds inte. Först när testning och support har verifierats läggs nyare versioner till i den här listan. Håll även operativsystemet uppdaterat med säkerhetsuppdateringar.

  • Linux-distributioner som stöds – Följande tabell beskriver vilka versioner av Linux som stöds för tunnelservern och vilken container de behöver:

    Distributionsversion Containerkrav Överväganden
    CentOS 7.4+ Docker CE Support upphör juni 2024. CentOS 8+ stöds inte
    Red Hat (RHEL) 7.4+ Docker CE Support upphör juni 2024
    Red Hat (RHEL) 8.6 Support upphör juni 2024 Podman 4.0 (standard)
    Podman 3.0    		 Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.0. Om du uppgraderar och ändrar containrar från v3 till v4.0 planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 8.7 Podman 4.2 (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 8.8 Podman 4.4.1 Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 8.9 Podman 4.4.1 Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 8.10 Podman 4.9.4-rhel (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 9.0 Support upphör juni 2024 Podman 4.4.1 (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.

    Support upphör feb 2024.
    Red Hat (RHEL) 9.1 Podman 4.4.1 (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 9.2 Podman 4.4.1 (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 9.3 Podman 4.6.1. (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (standard) Den här versionen av RHEL läser inte in modulen ip_tables automatiskt i Linux-kerneln. När du använder den här versionen ska du planera att läsa in ip_tables manuellt innan Tunnel installeras.

    Containrar som skapats av Podman v3 och tidigare kan inte användas med Podman v4.2 och senare. Om du uppgraderar och ändrar containrar planerar du att skapa nya containrar och avinstallera och sedan installera om Microsoft Tunnel.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    Viktigt

    I april 2023 avslutar Ubuntu stödet för Ubuntu 18.04. När supporten upphör för Ubuntu upphör Intune även stödet för Ubuntu 18.04 för användning med Microsoft Tunnel. Mer information finns i https://wiki.ubuntu.com/Releases.

  • Storlek på Linux-servern: Använd följande vägledning för att uppfylla din förväntade användning:

    # Enheter Antal processorer Minne GB # Servrar # Webbplatser Diskutrymme 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

    Stöd skalas linjärt. Varje Microsoft Tunnel stöder upp till 64 000 samtidiga anslutningar, men enskilda enheter kan öppna flera anslutningar.

  • CPU: 64-bitars AMD/Intel-processor.

  • Installera Docker CE eller Podman: Installera något av följande på servern beroende på vilken version av Linux du använder för tunnelservern:

    • Docker version 19.03 CE eller senare.
    • Podman version 3.0 eller 4.0 beroende på versionen av RHEL.

    Microsoft Tunnel kräver Docker eller Podman på Linux-servern för att ge stöd för containrar. Containrar ger en konsekvent körningsmiljö, hälsoövervakning och proaktiv reparation samt en ren uppgraderingsupplevelse.

    Information om hur du installerar och konfigurerar Docker eller Podman finns i:

    • Installera Docker Engine på CentOS eller Red Hat Enterprise Linux 7.

      Obs!

      Föregående länk leder dig till centOS-nedladdnings- och installationsinstruktionerna. Använd samma instruktioner för RHEL 7.4. Den version som installeras på RHEL 7.4 är som standard för gammal för att stödja Microsoft Tunnel Gateway.

    • Installera Docker Engine på Ubuntu.

    • Installera Podman på Red Hat Enterprise Linux 8.4 och senare (rulla ned till RHEL8).

      Dessa versioner av RHEL stöder inte Docker. I stället använder de här versionerna Podman, och podman ingår i en modul som kallas "container-tools". I det här sammanhanget är en modul en uppsättning RPM-paket som representerar en komponent och som vanligtvis installeras tillsammans. En typisk modul innehåller paket med ett program, paket med programspecifika beroendebibliotek, paket med dokumentation för programmet och paket med hjälpverktyg. Mer information finns i Introduktion till moduler i Red Hat-dokumentationen.

      Obs!

      Rotlös Podman: Microsoft Tunnel stöder användning av en rotlös Podman-container.

      Användning av rotlös Podman kräver ytterligare krav för dem som beskrivs i den här artikeln och användningen av en modifierad kommandorad när du startar skriptet för tunnelinstallation. Information om de ytterligare kraven och kommandoraden för installation finns i Använda en rotlös Podman-container i artikeln Konfigurera Microsoft Tunnel för Intune.

  • TLS-certifikat (Transport Layer Security): Linux-servern kräver ett betrott TLS-certifikat för att skydda anslutningen mellan enheter och Tunnel Gateway-servern. Under installationen av Tunnel Gateway lägger du till TLS-certifikatet och den fullständiga betrodda certifikatkedjan på servern.

    • Alternativt namn på certifikatmottagare (SAN) för det TLS-certifikat som du använder för att skydda Tunnel Gateway-slutpunkten måste matcha IP-adressen eller FQDN för Tunnel Gateway-servern.

    • TLS-certifikatet kan inte ha ett förfallodatum längre än två år. Om datumet är längre än två år godkänns det inte på iOS-enheter.

    • Stöd för jokertecken är begränsat. * .contoso.com stöds till exempel, men cont*.com stöds inte.

    • Under installationen av Tunnel Gateway-servern måste du kopiera hela den betrodda certifikatkedjan till Din Linux-server. Installationsskriptet tillhandahåller den plats där du kopierar certifikatfilerna och uppmanar dig att göra det.

    • Om du använder ett TLS-certifikat som inte är offentligt betrott måste du push-överföra hela förtroendekedjan till enheter med hjälp av en Intune betrodd certifikatprofil.

    • TLS-certifikatet kan vara i PEM - eller pfx-format .

    • För att stödja hälsokontrollen av TLS-certifikatåterkallning kontrollerar du att OCSP-adressen (Online Certificate Status Protocol) eller crl-adressen (certificate revocation list) som definierats av TLS-certifikatet är tillgänglig från servern.

    • Konfigurera tunnelklientcertifikatet med en nyckel som är 2 048 bitar eller större. Vi rekommenderar större nycklar för att hjälpa distributionen att behålla stöd för framtida och växande SSL/TLS-krav från olika SSL/TLS-bibliotekslösningar.

      Tips

      Granska regelbundet kraven för ditt valda SSL/TLS-bibliotek för att säkerställa att din infrastruktur och dina certifikat fortfarande stöds och följer de senaste ändringarna för det biblioteket, och återutfärda Tunnel-klientcertifikat när det behövs för att hålla dig uppdaterad med dina lösningar som utvecklas.

  • TLS-version: Som standard använder anslutningar mellan Microsoft Tunnel-klienter och servrar TLS 1.3. När TLS 1.3 inte är tillgängligt kan anslutningen återgå till att använda TLS 1.2.

Standardbryggningsnätverk

Både Podman- och Docker-containrar använder ett bryggnätverk för att vidarebefordra trafik via Linux-värden. När containrarnas bryggnätverk står i konflikt med ett företagsnätverk kan Tunnel Gateway inte dirigera trafik till det företagsnätverket.

Standardbryggningsnätverken är:

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

För att undvika konflikter kan du konfigurera om både Podman och Docker för att använda ett bryggnätverk som du anger.

Viktigt

Tunnel Gateway-servern måste installeras innan du kan ändra nätverkskonfigurationen för bryggan.

Ändra standardbryggningsnätverket som används av Docker

Docker använder filen /etc/docker/daemon.json för att konfigurera en ny standardbrygga-IP-adress. I filen måste bryggans IP-adress anges i CIDR-notationen (klasslös routning mellan domäner), ett kompakt sätt att representera en IP-adress tillsammans med dess associerade nätmask och routningsprefix.

Viktigt

Ip-adressen som används i följande steg är ett exempel. Se till att DEN IP-adress som du använder inte är i konflikt med företagets nätverk.

  1. Använd följande kommando för att stoppa MS Tunnel Gateway-containern: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Kör sedan följande kommando för att ta bort den befintliga Docker-brygganheten: sudo ip link del docker0

  3. Om filen /etc/docker/daemon.json finns på servern använder du en filredigerare som vi eller nano för att ändra filen. Kör filredigeraren med rot- eller sudo-behörigheter:

    • När posten "bip": finns med en IP-adress ändrar du den genom att lägga till en ny IP-adress i CIDR-notationen.
    • När posten "bip": inte finns måste du lägga till både värdet "bip": och den nya IP-adressen i CIDR-notationen.

    I följande exempel visas strukturen för en daemon.json fil med en uppdaterad "bip": post som använder en ändrad IP-adress på "192.168.128.1/24".

    Exempel på daemon.json:

    {
"bip": "192.168.128.1/24"
}

  4. Om filen /etc/docker/daemon.json inte finns på servern kör du ett kommando som liknar följande exempel för att skapa filen och definiera bryggans IP-adress som du vill använda.

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

  5. Använd följande kommando för att starta MS Tunnel Gateway-containern: sudo mst-cli agent start ; sudo mst-cli server start

Mer information finns i Använda bryggnätverk i Docker-dokumentationen.

Ändra standardbryggningsnätverket som används av Podman

Podman använder filen /etc/cni/net.d som 87-podman-bridge.conflist för att konfigurera en ny standardbryggas IP-adress.

  1. Använd följande kommando för att stoppa MS Tunnel Gateway-containern: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Kör sedan följande kommando för att ta bort den befintliga Podman-bryggan: sudo ip link del cni-podman0

  3. Med rotbehörigheter och en filredigerare som vi eller nano ändrar du /etc/cni/net.d som 87-podman-bridge.conflist för att uppdatera standardvärdena för "subnet:" och "gateway:" genom att ersätta Podman-standardvärdena med önskade undernäts- och gatewayadresser. Undernätsadressen måste anges i CIDR-notation.

    Standardinställningarna för Podman är:

    • undernät: 10.88.0.0/16
    • gateway: 10.88.0.1

  4. Använd följande kommando för att starta om MS Tunnel Gateway-containrarna: sudo mst-cli agent start ; sudo mst-cli server start

Mer information finns i Konfigurera containernätverk med Podman i Red Hat-dokumentationen.

Linux-systemgranskning

Linux-systemgranskning kan hjälpa dig att identifiera säkerhetsrelevent information eller säkerhetsöverträdelser på en Linux-server som är värd för Microsoft Tunnel. Linux-systemgranskning rekommenderas för Microsoft Tunnel, men krävs inte. Om du vill använda systemgranskning måste det granskade paketet vara installerat på en Linux-server./etc/audit/auditd.conf

Information om hur du implementerar granskning beror på vilken Linux-plattform du använder:

  • Red Hat: Versioner av Red Had Enterprise Linux 7 och senare installerar det granskade paketet som standard. Men om paketet inte är installerat kan du använda följande kommandorad på Linux-servern för att installera det: sudo dnf install audit audispd-plugins

    Normalt är det granskade paketet tillgängligt från standardlagringsplatsen för varje REHL-version.

    Mer information om hur du använder systemgranskning på RHEL finns i Konfigurera Linux-systemgranskning med granskad i Red Hat-bloggen.

  • Ubuntu: Om du vill använda systemgranskning med Ubuntu måste du installera det granskade paketet manuellt. Det gör du genom att använda följande kommandorad på Linux-servern: sudo apt install auditd audispd-plugins

    Normalt är det granskade paketet tillgängligt från standardlagringsplatsen för varje Ubuntu-version.

    Mer information om hur du använder systemgranskning på Ubuntu finns i How to setup and Install Auditd on Ubuntu, a article that is available on the dev.to website that was originally published at kubefront.com.

Nätverk

  • Aktivera vidarebefordran av paket för IPv4: Varje Linux-server som är värd för tunnelserverprogramvaran måste ha IP-vidarebefordran för IPv4 aktiverat. Om du vill kontrollera status för IP-vidarebefordring kör du något av följande allmänna kommandon som root eller sudo på servern. Båda kommandona returnerar värdet 0 för inaktiverad och värdet 1 för aktiverad:

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

    Om det inte är aktiverat kan du tillfälligt aktivera IP-vidarebefordran genom att köra något av följande allmänna kommandon som rot eller sudo på servern. Dessa kommandon kan ändra konfigurationen för IP-vidarebefordran tills servern startas om. Efter en omstart returnerar servern IP-vidarebefordringsbeteendet till dess tidigare tillstånd. För båda kommandona använder du värdet 1 för att aktivera vidarebefordran. Värdet 0 inaktiverar vidarebefordran. Följande kommandoexempel använder värdet 1 för att aktivera vidarebefordran:

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

    Om du vill göra IP-vidarebefordran permanent redigerar du filen /etc/sysctl.conf på varje Linux-server och tar bort den inledande hashtaggen (#) från #net.ipv4.ip_forward=1 för att aktivera vidarebefordran av paket. Efter redigeringen bör posten visas på följande sätt:

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

    För att den här ändringen ska börja gälla måste du antingen starta om servern eller köra sysctl -p.

    Om den förväntade posten inte finns i filen sysctl.conf läser du dokumentationen för den distribution som du använder för att aktivera IP-vidarebefordring. Vanligtvis kan du redigera sysctl.conf för att lägga till den saknade raden i slutet av filen för att permanent aktivera IP-vidarebefordran.

  • Konfigurera flera nätverkskort per server(valfritt): Vi rekommenderar att du använder två nätverkskort per Linux-server för att förbättra prestanda, även om det är valfritt att använda två.

    • Nätverkskort 1 – Det här nätverkskortet hanterar trafik från dina hanterade enheter och bör finnas i ett offentligt nätverk med offentlig IP-adress.  Den här IP-adressen är den adress som du konfigurerar i platskonfigurationen. Den här adressen kan representera en enskild server eller en lastbalanserare.

    • Nätverkskort 2 – Det här nätverkskortet hanterar trafik till dina lokala resurser och bör finnas i ditt privata interna nätverk utan nätverkssegmentering.

  • Se till att molnbaserade virtuella Linux-datorer kan komma åt ditt lokala nätverk: Om du kör Linux som en virtuell dator i ett moln kontrollerar du att servern kan komma åt ditt lokala nätverk. För en virtuell dator i Azure kan du till exempel använda Azure ExpressRoute eller något liknande för att ge åtkomst. Azure ExpressRoute behövs inte när du kör servern lokalt på en virtuell dator.

  • Lastbalanserare(valfritt): Om du väljer att lägga till en lastbalanserare läser du leverantörens dokumentation för konfigurationsinformation. Ta hänsyn till nätverkstrafik och brandväggsportar som är specifika för Intune och Microsoft Tunnel.

    Tunnelservern svarar på GET-begäranden med en statisk sida. Svaret används som avsökning av lastbalanserare som ett sätt att kontrollera tunnelserverns livslängd. Svaret är statiskt och innehåller inte känslig information.

  • Stöd för per app-VPN och toppnivådomän – Användning per app-VPN med intern användning av lokala toppnivådomäner stöds inte av Microsoft Tunnel.

Brandvägg

Som standard använder Microsoft Tunnel och -servern följande portar:

Inkommande portar:

  • TCP 443 – krävs av Microsoft Tunnel.
  • UDP 443 – krävs av Microsoft Tunnel.
  • TCP 22 – Valfritt. Används för SSH/SCP till Linux-servern.

Utgående portar:

  • TCP 443 – Krävs för att få åtkomst till Intune tjänster. Krävs av Docker eller Podman för att hämta avbildningar.

När du skapar serverkonfigurationen för tunneln kan du ange en annan port än standardvärdet 443. Om du anger en annan port konfigurerar du brandväggar för att stödja konfigurationen.

Fler krav:

Om du vill komma åt säkerhetstokentjänsten och Azure Storage för loggar ger du åtkomst till följande FQDN:

  • Säkerhetstokentjänst: *.sts.windows.net
  • Azure Storage för tunnelloggar: *.blob.core.windows.net
  • Andra url:er för lagringsslutpunkter: *.blob.storage.azure.net
  • Microsoft Intune:*.manage.microsoft.com
  • Microsoft-autentisering: login.microsoftonline.com
  • Microsoft Graph: graph.microsoft.com
  • Konfigurera brandväggsregler för att stödja konfigurationerna som beskrivs i konfigurationen av Microsofts artefaktregister (MAR) Klientbrandväggsregler.

Proxyserver

Du kan använda en proxyserver med Microsoft Tunnel.

Obs!

Proxyserverkonfigurationer stöds inte med versioner av Android före version 10. Mer information finns i VpnService.Builder i android-utvecklardokumentationen.

Obs!

Kontrollera att dina Android LOB-program stöder direktproxy eller automatisk proxykonfiguration (PAC) för både MDM och MAM.

Obs!

Känt problem: Användare som försöker logga in på Edge med sina personliga konton eller företagskonton kan få problem när en automatisk proxykonfiguration (PAC) har konfigurerats. I det här scenariot kan inloggningsprocessen misslyckas, vilket hindrar användaren från att komma åt interna resurser.

Lösningar: För att lösa det här problemet erbjuder Microsoft Tunnel delade tunnlar som ett alternativ. Med delade tunnlar kan användare endast inkludera de vägar som kräver en proxy samtidigt som inloggningsservrar och autentiseringssökvägar undantas från routning via tunneln. Den här lösningen säkerställer att inloggningsprocessen inte påverkas av PAC-konfigurationen, vilket gör att användaren kan komma åt interna resurser och bläddra på Internet.

Direktproxy är också ett alternativ utan delade tunnlar för inloggning för att fungera i Edge med hjälp av företagskonton. Det innebär att konfigurera Microsoft Tunnel för att använda en direktproxy i stället för en PAC-URL.

Om ingen användarinloggning krävs i Edge stöds PAC för normal surfning och åtkomst till interna resurser.

Följande överväganden kan hjälpa dig att konfigurera Linux-servern och din miljö för att lyckas:

Konfigurera en utgående proxy för Docker

  • Om du använder en intern proxyserver kan du behöva konfigurera Linux-värden så att den använder proxyservern med hjälp av miljövariabler. Om du vill använda variablerna redigerar du filen /etc/environment på Linux-servern och lägger till följande rader:

    http_proxy=[address]
    https_proxy=[address]

  • Autentiserade proxyservrar stöds inte.

  • Proxyn kan inte utföra avbrott och granskning eftersom Linux-servern använder ömsesidig TLS-autentisering vid anslutning till Intune.

  • Konfigurera Docker att använda proxyn för att hämta avbildningar. Det gör du genom att redigera filen /etc/systemd/system/docker.service.d/http-proxy.conf på Linux-servern och lägga till följande rader:

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

    Obs!

    Microsoft Tunnel stöder inte Microsoft Entra programproxy eller liknande proxylösningar.

Konfigurera en utgående proxy för Podman

Följande information kan hjälpa dig att konfigurera en intern proxy när du använder Podman:

  • Autentiserade proxyservrar stöds inte.

  • Proxyn kan inte utföra avbrott och granskning eftersom Linux-servern använder ömsesidig TLS-autentisering vid anslutning till Intune.

  • Podman läser HTTP-proxyinformation som lagras i /etc/profile.d/http_proxy.sh. Om den här filen inte finns på servern skapar du den. Redigera http_proxy.sh för att lägga till följande två rader. På följande rader är 10.10.10.1:3128 ett exempel på adress:portpost. När du lägger till dessa rader ersätter du 10.10.10.1:3128 med värdena för din proxy-IP-adress :port:

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

    Om du har åtkomst till Red Hat-kundportalen kan du visa den kunskapsbas artikel som är associerad med den här lösningen. Se Konfigurera HTTP-proxyvariabler för Podman – Red Hat-kundportalen.

  • När du lägger till dessa två rader i http_proxy.sh innan du installerar Microsoft Tunnel Gateway genom att köra mstunnel-setup konfigurerar skriptet automatiskt tunnelgatewayens proxymiljövariabler i /etc/mstunnel/env.sh.

    Utför följande åtgärder för att konfigurera en proxy när Installationen av Microsoft Tunnel Gateway är klar:

    1. Ändra eller skapa filen /etc/profile.d/http_proxy.sh och lägg till de två raderna från föregående punkt.

    2. Redigera /etc/mstunnel/env.sh och lägg till följande två rader i slutet av filen. Precis som föregående rader ersätter du exempeladressen:portvärdet10.10.10.1:3128 med värdena för din proxy-IP-adress :port:

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

    3. Starta om Tunnel Gateway-servern: Kör mst-cli server restart

    Tänk på att RHEL använder SELinux. Eftersom en proxy som inte körs på en SELinux-port för http_port_t kan kräva extra konfiguration kontrollerar du användningen av SELinux-hanterade portar för http. Kör följande kommando för att visa konfigurationerna: sudo semanage port -l | grep "http_port_t"

    Exempel på resultatet av portkontrollkommandot. I det här exemplet använder proxyn 3128 och visas inte:

    Skärmbild som visar resultatet av portkontrollen.

    • Om proxyn körs på någon av SELinux-portarna för http_port_t kan du fortsätta med tunnelgatewayinstallationsprocessen.

    • Om proxyn inte körs på en SELinux-port för http_port_t som i föregående exempel måste du göra extra konfigurationer.

      Om proxyporten inte visas förhttp_port_t kontrollerar du om proxyporten används av en annan tjänst. Använd kommandot semanage för att först kontrollera porten som proxyn använder och sedan senare om det behövs för att ändra den. Kontrollera porten som proxyn använder genom att köra: sudo semanage port -l | grep "your proxy port"

      Exempel på resultatet av sökning efter en tjänst som kan använda porten:

      Skärmbild som visar resultatet av tjänstkontrollen.

      • I exemplet används porten som vi förväntar oss (3128) av bläckfisk, som råkar vara en OSS-proxytjänst. Squid proxy SELinux-principer ingår i många vanliga distributioner. Eftersom bläckfisken använder port 3128 (vår exempelport) måste vi ändra de http_port_t portarna och lägga till port 3128 så att den tillåts via SELinux för proxyn som används av Tunnel. Om du vill ändra portanvändningen kör du följande kommando: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        Exempel på kommandot för att ändra porten:

        Skärmbild som visar ett exempel på portändringskommandot.

        När du har kört kommandot för att ändra porten kör du följande kommando för att kontrollera om porten används av en annan tjänst: sudo semanage port -l | grep "your proxy port"

        Exempel på kommandot för att kontrollera porten när porten har modifierats:

        Skärmbild av att kontrollera porten efter ändringen.

        I det här exemplet är port 3128 nu associerad med både http_port-t och squid_port_t. Det resultatet är förväntat. Om proxyporten inte visas när du kör sudo semanage-porten -l | grep kommandot "your_proxy_port" kör du kommandot för att ändra porten igen, men -m i kommandot semanage med -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Konfigurera Podman att använda proxyn för att ladda ned avbildningsuppdateringar

Du kan konfigurera Podman att använda proxyn för att ladda ned (hämta) uppdaterade avbildningar för Podman:

  1. På tunnelservern använder du en kommandotolk för att köra följande kommando för att öppna en redigerare för åsidosättningsfilen för Microsoft Tunnel-tjänsten:

    systemctl edit --force mstunnel_monitor

  2. Lägg till följande tre rader i filen. Ersätt varje instans av [adress] med din proxy-DN eller -adress och spara sedan filen:

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

  3. Kör sedan följande i kommandotolken:

    systemctl restart mstunnel_monitor

  4. Kör slutligen följande i kommandotolken för att bekräfta att konfigurationen lyckades:

    systemctl show mstunnel_monitor | grep http_proxy

    Om konfigurationen lyckas liknar resultatet följande information:

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

Uppdatera proxyservern som används av tunnelservern

Om du vill ändra proxyserverkonfigurationen som används av Linux-värden på tunnelservern använder du följande procedur:

  1. På tunnelservern redigerar du /etc/mstunnel/env.sh och anger den nya proxyservern.

  2. Kör mst-cli install.

    Det här kommandot återskapar containrarna med den nya proxyserverinformationen. Under den här processen uppmanas du att verifiera innehållet i /etc/mstunnel/env.sh och kontrollera att certifikatet är installerat. Certifikatet bör redan finnas från den tidigare proxyserverkonfigurationen.

    Bekräfta båda och slutför konfigurationen genom att ange ja.

Plattformar

Enheter måste vara registrerade för att Intune ska kunna användas med Microsoft Tunnel. Endast följande enhetsplattformar stöds:

  • iOS/iPadOS

  • Android Enterprise:

    • Fullständigt hanterad
    • Corporate-Owned arbetsprofil
    • Personally-Owned Arbetsprofil

    Obs!

    Dedikerade Android Enterprise-enheter stöds inte av Microsoft Tunnel.

Alla plattformar har stöd för följande funktioner:

  • Microsoft Entra autentisering till tunneln med användarnamn och lösenord.
  • Active Directory Federation Services (AD FS) (AD FS) autentisering till tunneln med användarnamn och lösenord.
  • Stöd per app.
  • Manuell fullständig enhetstunnel via en tunnelapp, där användaren startar VPN och väljer Anslut.
  • Delade tunnlar. I regler för delade tunnlar i iOS ignoreras dock när VPN-profilen använder per app-VPN.

Stödet för en proxy är begränsat till följande plattformar:

  • Android 10 och senare
  • iOS/iPadOS

Behörigheter

För att kunna hantera Microsoft Tunnel måste användarna ha behörigheter som ingår i behörighetsgruppen för Microsoft Tunnel Gateway i Intune. Som standard har Intune administratörer och Microsoft Entra administratörer dessa behörigheter. Du kan också lägga till dem i anpassade roller som du skapar för din Intune klientorganisation.

När du konfigurerar en roll expanderar du Microsoft Tunnel Gateway på sidan Behörigheter och väljer sedan de behörigheter som du vill bevilja.

Skärmbild av behörigheterna för tunnelgatewayen i Microsoft Intune administrationscenter.

Behörighetsgruppen Microsoft Tunnel Gateway beviljar följande behörigheter:

  • Skapa – Konfigurera Microsoft Tunnel Gateway-servrar och -platser. Serverkonfigurationer omfattar inställningar för IP-adressintervall, DNS-servrar, portar och regler för delade tunnlar. Platser är logiska grupper av flera servrar som stöder Microsoft Tunnel.

  • Uppdatera (ändra) – Uppdatera Microsoft Tunnel Gateway-serverkonfigurationer och -platser. Serverkonfigurationer omfattar inställningar för IP-adressintervall, DNS-servrar, portar och regler för delade tunnlar. Platser är logiska grupper av flera servrar som stöder Microsoft Tunnel.

  • Ta bort – Ta bort serverkonfigurationer och platser för Microsoft Tunnel Gateway. Serverkonfigurationer omfattar inställningar för IP-adressintervall, DNS-servrar, portar och regler för delade tunnlar. Platser är logiska grupper av flera servrar som stöder Microsoft Tunnel.

  • Läs – Visa serverkonfigurationer och platser för Microsoft Tunnel Gateway. Serverkonfigurationer omfattar inställningar för IP-adressintervall, DNS-servrar, portar och regler för delade tunnlar. Platser är logiska grupper av flera servrar som stöder Microsoft Tunnel.

Kör beredskapsverktyget

Innan du startar en serverinstallation rekommenderar vi att du laddar ned och kör den senaste versionen av verktyget mst-readiness . Verktyget är ett skript som körs på Linux-servern och utför följande åtgärder:

  • Verifierar att det Microsoft Entra konto som du använder för att installera Microsoft Tunnel har de roller som krävs för att slutföra registreringen.

  • Bekräftar att din nätverkskonfiguration ger Microsoft Tunnel åtkomst till nödvändiga Microsoft-slutpunkter.

  • Söker efter förekomsten av modulen ip_tables på Linux-servern. Den här kontrollen lades till i skriptet den 11 februari 2022 när stöd för RHEL 8.5 lades till. RHEL 8.5 senare läser inte in ip_tables-modulen som standard. Om de saknas när Linux-servern har installerats måste du läsa in modulen ip_tables manuellt.

Viktigt

Beredskapsverktyget validerar inte inkommande portar, vilket är en vanlig felkonfiguration. När beredskapsverktyget har körts granskar du brandväggskraven och verifierar att brandväggarna skickar inkommande trafik manuellt.

Verktyget mst-readiness har ett beroende av jq, en JSON-processor på kommandoraden. Kontrollera att jq är installerat innan du kör beredskapsverktyget. Information om hur du hämtar och installerar jq finns i dokumentationen för den version av Linux som du använder.

Så här använder du beredskapsverktyget:

  1. Hämta den senaste versionen av beredskapsverktyget med någon av följande metoder:

    • Ladda ned verktyget direkt med hjälp av en webbläsare. Gå till för att https://aka.ms/microsofttunnelready ladda ned en fil med namnet mst-readiness.

    • Logga in på Microsoft Intune administrationscenter>för klientorganisationsadministration>Microsoft Tunnel Gateway, välj fliken Servrar, välj Skapa för att öppna fönstret Skapa en server och välj sedan Verktyget Ladda ned beredskap.

    • Använd ett Linux-kommando för att hämta beredskapsverktyget direkt. Du kan till exempel använda wget eller curl för att öppna länken https://aka.ms/microsofttunnelready.

      Om du till exempel vill använda wget - och logginformation för mst-readiness under nedladdningen kör du wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

    Skriptet kan köras från alla Linux-servrar som finns i samma nätverk som den server som du planerar att installera, vilket gör att nätverksadministratörer kan använda skriptet för att felsöka nätverksproblem oberoende av varandra.

  2. Om du vill verifiera nätverks- och Linux-konfigurationen kör du skriptet med följande kommandon. Dessa kommandon anger körningsbehörigheterna för skriptet, verifierar att Tunneln kan ansluta till rätt slutpunkter och kontrollerar sedan om det finns verktyg som Tunnel använder:

    • sudo ./mst-readiness

    • sudo ./mst-readiness network – Det här kommandot kör följande åtgärder och rapporterar sedan lyckade eller fel för båda:

      • Försöker ansluta till varje Microsoft-slutpunkt som tunneln ska använda.
      • Kontrollerar att de portar som krävs är öppna i brandväggen.

    • sudo ./mst-readiness utils – Det här kommandot verifierar att verktyg som används av Tunnel som Docker eller Podman och ip_tables är tillgängliga.

  3. Kontrollera att det konto som du använder för att installera Microsoft Tunnel har de roller och behörigheter som krävs för att slutföra registreringen genom att köra skriptet med följande kommandorad: ./mst-readiness account

    Skriptet uppmanar dig att använda en annan dator med en webbläsare, som du använder för att autentisera för att Microsoft Entra ID och Intune. Verktyget rapporterar lyckat eller ett fel.

Mer information om det här verktyget finns i Referens för mst-cli i referensartikeln för Microsoft Tunnel.

Läs in ip_tables manuellt

Även om de flesta Linux-distributioner automatiskt läser in ip_tables-modulen kanske vissa distributioner inte gör det. RHEL 8.5 läser till exempel inte in ip_tables som standard.

Om du vill kontrollera förekomsten av den här modulen kör du den senaste versionen av mst-readiness-verktyget på Linux-servern. Kontrollen av ip_tables lades till i skriptet för beredskapsverktyg den 11 februari 2022.

Om modulen inte finns stoppas verktyget i ip_tables modulkontroll. I det här scenariot kan du köra följande kommandon för att läsa in modulen manuellt.

Läs in modulen ip_tables manuellt

Kör följande kommandon på Linux-servern i samband med sudo:

  1. Verifiera förekomsten av ip_tables på servern: lsmod |grep ip_tables

  2. Om ip_tables inte finns kör du följande för att läsa in modulen i kerneln omedelbart, utan omstart: /sbin/modprobe ip_tables

  3. Kör verifieringen igen för att bekräfta att tabellerna nu har lästs in: lsmod |grep ip_tables

Viktigt

När du uppdaterar tunnelservern kanske en manuellt inläst ip_tables modul inte finns kvar. Detta kan kräva att du läser in modulen igen när uppdateringen har slutförts. När serveruppdateringen har slutförts granskar du servern för att se om det finns ip_tables modulen.

Om tabellerna inte finns använder du föregående steg för att läsa in modulen igen, med det ytterligare steget för att starta om servern när modulen har lästs in.

Konfigurera Linux för att läsa in ip_tables vid start

I samband med sudo kör du följande kommando på Linux-servern för att skapa en konfigurationsfil som läser in ip_tables i kernel under starttiden: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Läs in tun-modulen manuellt

Microsoft Tunnel kräver tun-modulen , men vissa Linux-distributioner läser inte in tun-modulen som standard.

Om du vill verifiera att tun-modulen finns på servern kör du: lsmod |grep tun

  1. Om tun inte finns kör du följande för att läsa in modulen i kerneln omedelbart, utan omstart: /sbin/modprobe tun

  2. Kör verifieringen igen för att bekräfta att tun-modulen nu har lästs in:lsmod |grep tun

Viktigt

När du uppdaterar tunnelservern kanske en manuellt inläst tun-modul inte finns kvar. Detta kan kräva att du läser in modulen igen när uppdateringen har slutförts. När serveruppdateringen är klar granskar du servern för förekomsten av tun-modulen.

Om den inte finns använder du föregående steg för att läsa in modulen igen, med det ytterligare steget för att starta om servern när modulen har lästs in.

Konfigurera Linux för att läsa in tun vid start

I samband med sudo kör du följande kommando på Linux-servern för att skapa en konfigurationsfil som läser in tun i kernel under starttiden: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Nästa steg

Konfigurera Microsoft Tunnel