Condividi tramite

Prerequisiti per Microsoft Tunnel in Intune

  • Articolo

Prima di poter installare il gateway VPN di Microsoft Tunnel per Microsoft Intune, esaminare e configurare i prerequisiti. I prerequisiti includono l'uso di un server Linux che esegue contenitori per ospitare il software del server tunnel. Pianificare anche la configurazione della rete, dei firewall e dei proxy per supportare le comunicazioni per Microsoft Tunnel.

A livello generale, Microsoft Tunnel richiede:

  • Una sottoscrizione di Azure.

  • Sottoscrizione Microsoft Intune Piano 1.

    Nota

    Questo prerequisito è per Microsoft Tunnel e non include Microsoft Tunnel per la gestione di applicazioni mobili, che è un componente aggiuntivo Intune che richiede una sottoscrizione Microsoft Intune Piano 2.

  • Un server Linux che esegue contenitori. Il server può essere locale o nel cloud e supporta uno dei tipi di contenitore seguenti:

    • Podman per Red Hat Enterprise Linux (RHEL). Vedere i requisiti del server Linux .
    • Docker per tutte le altre distribuzioni linux.

  • Certificato TLS (Transport Layer Security) per il server Linux per proteggere le connessioni dai dispositivi al server del gateway tunnel.

  • Dispositivi che eseguono Android o iOS/iPadOS.

Dopo aver configurato i prerequisiti, è consigliabile eseguire lo strumento di preparazione per verificare che l'ambiente sia configurato correttamente per un'installazione corretta.

Le sezioni seguenti illustrano in dettaglio i prerequisiti per Microsoft Tunnel e forniscono indicazioni sull'uso dello strumento di preparazione.

Nota

Il tunnel e l'accesso sicuro globale (GSA) non possono essere usati contemporaneamente nello stesso dispositivo.

Server Linux

Configurare una macchina virtuale basata su Linux o un server fisico in cui installare il gateway di Microsoft Tunnel.

Nota

Sono supportati solo i sistemi operativi e le versioni dei contenitori elencati nella tabella seguente. Le versioni non elencate non sono supportate. Solo dopo la verifica del test e della supportabilità vengono aggiunte versioni più recenti a questo elenco. Mantenere il sistema operativo aggiornato anche con gli aggiornamenti della sicurezza.

  • Distribuzioni Linux supportate : nella tabella seguente vengono descritte le versioni di Linux supportate per il server tunnel e il contenitore richiesto:

    Versione di distribuzione Requisiti del contenitore Considerazioni
    CentOS 7.4+ Docker CE Il supporto termina a giugno 2024. CentOS 8+ non è supportato
    Red Hat (RHEL) 7.4+ Docker CE Il supporto termina a giugno 2024
    Red Hat (RHEL) 8.6 Il supporto termina a giugno 2024 Podman 4.0 (impostazione predefinita)
    Podman 3.0    		 Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.0. Se si aggiornano e modificano i contenitori dalla versione 3 alla versione 4.0, pianificare la creazione di nuovi contenitori e disinstallare e quindi reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 8.7 Podman 4.2 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 8.8 Podman 4.4.1 Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 8.9 Podman 4.4.1 Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 8.10 Podman 4.9.4-rhel (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 9.0 Il supporto termina a giugno 2024 Podman 4.4.1 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.

    Il supporto termina a febbraio 2024.
    Red Hat (RHEL) 9.1 Podman 4.4.1 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 9.2 Podman 4.4.1 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 9.3 Podman 4.6.1. (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Quando si usa questa versione, pianificare il caricamento manuale del ip_tables prima dell'installazione di Tunnel.

    I contenitori creati da Podman v3 e versioni precedenti non sono utilizzabili con Podman v4.2 e versioni successive. Se si aggiornano e si modificano i contenitori, pianificare la creazione di nuovi contenitori e disinstallare e reinstallare Microsoft Tunnel.
    Ubuntu 20.04 Docker CE
    Ubuntu 22.04 Docker CE

    Importante

    Nell'aprile 2023 Ubuntu terminerà il supporto per Ubuntu 18.04. Con la fine del supporto di Ubuntu, Intune terminerà anche il supporto per Ubuntu 18.04 per l'uso con Microsoft Tunnel. Per ulteriori informazioni, vedere https://wiki.ubuntu.com/Releases.

  • Ridimensionare il server Linux: usare le indicazioni seguenti per soddisfare l'uso previsto:

    Dispositivi # CPU # GB di memoria Server # # Siti Spazio su disco 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

    Supporto lineare delle scale. Mentre ogni Microsoft Tunnel supporta fino a 64.000 connessioni simultanee, i singoli dispositivi possono aprire più connessioni.

  • CPU: processore AMD/Intel a 64 bit.

  • Installare Docker CE o Podman: a seconda della versione di Linux usata per il server tunnel, installare una delle opzioni seguenti nel server:

    • Docker versione 19.03 CE o successiva.
    • Podman versione 3.0 o 4.0 a seconda della versione di RHEL.

    Microsoft Tunnel richiede Docker o Podman nel server Linux per fornire supporto per i contenitori. I contenitori offrono un ambiente di esecuzione coerente, il monitoraggio dell'integrità e la correzione proattiva e un'esperienza di aggiornamento pulita.

    Per informazioni sull'installazione e la configurazione di Docker o Podman, vedere:

  • Certificato TLS (Transport Layer Security): il server Linux richiede un certificato TLS attendibile per proteggere la connessione tra i dispositivi e il server gateway tunnel. Durante l'installazione del gateway tunnel, si aggiunge al server il certificato TLS e la catena di certificati attendibili completa.

    • Il nome alternativo soggetto (SAN) del certificato TLS usato per proteggere l'endpoint del gateway di tunnel deve corrispondere all'indirizzo IP o al nome di dominio completo del server del gateway di tunnel.

    • Il certificato TLS non può avere una data di scadenza superiore a due anni. Se la data è più lunga di due anni, non viene accettata nei dispositivi iOS.

    • Il supporto dei caratteri jolly è limitato. Ad esempio, *.contoso.com è supportato, ma cont*.com non è supportato.

    • Durante l'installazione del server gateway tunnel, è necessario copiare l'intera catena di certificati attendibile nel server Linux. Lo script di installazione fornisce il percorso in cui copiare i file di certificato e richiede di eseguire questa operazione.

    • Se si usa un certificato TLS non attendibile pubblicamente, è necessario eseguire il push dell'intera catena di attendibilità nei dispositivi usando un profilo certificato attendibile Intune.

    • Il certificato TLS può essere in formato PEM o pfx .

    • Per supportare il controllo dell'integrità della revoca del certificato TLS , assicurarsi che l'indirizzo OCSP (Online Certificate Status Protocol) o CRL (Certificate Revocation List) definito dal certificato TLS sia accessibile dal server.

    • Configurare il certificato dei client tunnel con una chiave di dimensioni pari o superiori a 2048 bit. È consigliabile usare chiavi più grandi per mantenere il supporto per i requisiti SSL/TLS futuri e in continua evoluzione con varie soluzioni di libreria SSL/TLS.

      Consiglio

      Esaminare periodicamente i requisiti della libreria SSL/TLS scelta per assicurarsi che l'infrastruttura e i certificati rimangano supportati e in conformità alle modifiche recenti per tale libreria e rilasciare nuovamente i certificati client tunnel quando necessario per rimanere aggiornati sui requisiti in continua evoluzione delle soluzioni.

  • Versione TLS: per impostazione predefinita, le connessioni tra i client e i server di Microsoft Tunnel usano TLS 1.3. Quando TLS 1.3 non è disponibile, la connessione può tornare a usare TLS 1.2.

Rete bridge predefinita

Sia i contenitori Podman che Docker usano una rete bridge per inoltrare il traffico attraverso l'host Linux. Quando la rete bridge dei contenitori è in conflitto con una rete aziendale, il gateway tunnel non è in grado di instradare correttamente il traffico a tale rete aziendale.

Le reti bridge predefinite sono:

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

Per evitare conflitti, è possibile riconfigurare sia Podman che Docker per usare una rete bridge specificata.

Importante

Il server del gateway tunnel deve essere installato prima di poter modificare la configurazione della rete bridge.

Modificare la rete bridge predefinita usata da Docker

Docker usa il file /etc/docker/daemon.json per configurare un nuovo indirizzo IP bridge predefinito. Nel file, l'indirizzo IP bridge deve essere specificato nella notazione CIDR (Classless inter-domain routing), un modo compatto per rappresentare un indirizzo IP insieme alla subnet mask associata e al prefisso di routing.

Importante

L'indirizzo IP usato nei passaggi seguenti è un esempio. Assicurarsi che l'indirizzo IP usato non sia in conflitto con la rete aziendale.

  1. Usare il comando seguente per arrestare il contenitore del gateway tunnel MS: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Eseguire quindi il comando seguente per rimuovere il dispositivo bridge Docker esistente: sudo ip link del docker0

  3. Se il file /etc/docker/daemon.json è presente nel server, usare un editor di file come vi o nano per modificare il file. Eseguire l'editor di file con autorizzazioni radice o sudo:

    • Quando la voce "bip": è presente con un indirizzo IP, modificarla aggiungendo un nuovo indirizzo IP nella notazione CIDR.
    • Quando la voce "bip": non è presente, è necessario aggiungere sia il valore "bip": che il nuovo indirizzo IP nella notazione CIDR.

    Nell'esempio seguente viene illustrata la struttura di un file daemon.json con una voce "bip" aggiornata che usa un indirizzo IP modificato "192.168.128.1/24".

    Esempio di daemon.json:

    {
"bip": "192.168.128.1/24"
}

  4. Se il file /etc/docker/daemon.json non è presente nel server, eseguire un comando simile all'esempio seguente per creare il file e definire l'IP bridge da usare.

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

  5. Usare il comando seguente per avviare il contenitore del gateway tunnel MS: sudo mst-cli agent start ; sudo mst-cli server start

Per altre informazioni, vedere Usare le reti bridge nella documentazione di Docker.

Modificare la rete bridge predefinita usata da Podman

Podman usa il file /etc/cni/net.d come 87-podman-bridge.conflist per configurare un nuovo indirizzo IP bridge predefinito.

  1. Usare il comando seguente per arrestare il contenitore del gateway tunnel MS: sudo mst-cli server stop ; sudo mst-cli agent stop

  2. Eseguire quindi il comando seguente per rimuovere il dispositivo bridge Podman esistente: sudo ip link del cni-podman0

  3. Usando le autorizzazioni radice e un editor di file come vi o nano, modificare /etc/cni/net.d come 87-podman-bridge.conflist per aggiornare le impostazioni predefinite per "subnet:" e "gateway:" sostituendo i valori predefiniti di Podman con la subnet e gli indirizzi del gateway desiderati. L'indirizzo della subnet deve essere specificato nella notazione CIDR.

    Le impostazioni predefinite di Podman sono:

    • subnet: 10.88.0.0/16
    • gateway: 10.88.0.1

  4. Usare il comando seguente per riavviare i contenitori del gateway tunnel MS: sudo mst-cli agent start ; sudo mst-cli server start

Per altre informazioni, vedere Configurazione della rete dei contenitori con Podman nella documentazione di Red Hat.

Controllo del sistema Linux

Il controllo del sistema Linux consente di identificare le informazioni rilevanti per la sicurezza o le violazioni della sicurezza in un server Linux che ospita Microsoft Tunnel. Il controllo del sistema Linux è consigliato per Microsoft Tunnel, ma non è obbligatorio. Per usare il controllo di sistema, in un server Linux deve essere installato il pacchetto controllato in /etc/audit/auditd.conf.

I dettagli su come implementare il controllo dipendono dalla piattaforma Linux usata:

  • Red Hat: le versioni di Red Had Enterprise Linux 7 e versioni successive installano il pacchetto controllato per impostazione predefinita. Tuttavia, se il pacchetto non è installato, è possibile usare la riga di comando seguente nel server Linux per installarlo: sudo dnf install audit audispd-plugins

    In genere, il pacchetto controllato è disponibile dal repository predefinito di ogni versione REHL.

    Per altre informazioni sull'uso del controllo di sistema in RHEL, vedere Configurare il controllo del sistema Linux con controllo nel blog di Red Hat.

  • Ubuntu: per usare il controllo di sistema con Ubuntu è necessario installare manualmente il pacchetto controllato . A tale scopo, usare la riga di comando seguente nel server Linux: sudo apt install auditd audispd-plugins

    In genere, il pacchetto controllato è disponibile dal repository predefinito di ogni versione di Ubuntu.

    Per altre informazioni sull'uso del controllo di sistema in Ubuntu, vedere Come configurare e installare Auditd in Ubuntu, un articolo disponibile nel sito Web dev.to pubblicato originariamente all'indirizzo kubefront.com.

Rete

  • Abilitare l'inoltro di pacchetti per IPv4: ogni server Linux che ospita il software del server tunnel deve avere l'inoltro IP per IPv4 abilitato. Per controllare lo stato dell'inoltro IP, nel server eseguire uno dei comandi generici seguenti come radice o sudo. Entrambi i comandi restituiscono il valore 0 per disabled e il valore 1 per enabled:

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

    Se non è abilitato, è possibile abilitare temporaneamente l'inoltro IP eseguendo uno dei comandi generici seguenti come radice o sudo nel server. Questi comandi possono modificare la configurazione dell'inoltro IP fino al riavvio del server. Dopo un riavvio, il server restituisce il comportamento di inoltro IP allo stato precedente. Per entrambi i comandi, usare il valore 1 per abilitare l'inoltro. Il valore 0 disabilita l'inoltro. Gli esempi di comando seguenti usano un valore pari a 1 per abilitare l'inoltro:

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

    Per rendere permanente l'inoltro IP, in ogni server Linux modificare il file /etc/sysctl.conf e rimuovere l'hashtag iniziale (#) da #net.ipv4.ip_forward=1 per abilitare l'inoltro dei pacchetti. Dopo la modifica, la voce dovrebbe essere visualizzata come segue:

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

    Per rendere effettiva questa modifica, è necessario riavviare il server o eseguire sysctl -p.

    Se la voce prevista non è presente nel file sysctl.conf, consultare la documentazione relativa alla distribuzione usata per abilitare l'inoltro IP. In genere, è possibile modificare sysctl.conf per aggiungere la riga mancante alla fine del file per abilitare definitivamente l'inoltro IP.

  • Configurare più schede di interfaccia di rete per server(facoltativo): è consigliabile usare due controller di interfaccia di rete (NIC) per ogni server Linux per migliorare le prestazioni, anche se l'uso di due è facoltativo.

    • Scheda di interfaccia di rete 1 : questa scheda di interfaccia di rete gestisce il traffico dai dispositivi gestiti e deve trovarsi in una rete pubblica con indirizzo IP pubblico.  Questo indirizzo IP è l'indirizzo configurato nella configurazione del sito. Questo indirizzo può rappresentare un singolo server o un servizio di bilanciamento del carico.

    • Scheda di interfaccia di rete 2 : questa scheda di interfaccia di rete gestisce il traffico verso le risorse locali e deve trovarsi nella rete interna privata senza segmentazione di rete.

  • Assicurarsi che le macchine virtuali Linux basate sul cloud possano accedere alla rete locale: se si esegue Linux come macchina virtuale in un cloud, assicurarsi che il server possa accedere alla rete locale. Ad esempio, per una macchina virtuale in Azure, è possibile usare Azure ExpressRoute o qualcosa di simile per fornire l'accesso. Azure ExpressRoute non è necessario quando si esegue il server in una macchina virtuale locale.

  • Servizi di bilanciamento del carico(facoltativo): se si sceglie di aggiungere un servizio di bilanciamento del carico, consultare la documentazione dei fornitori per informazioni dettagliate sulla configurazione. Prendere in considerazione il traffico di rete e le porte del firewall specifiche per Intune e Microsoft Tunnel.

    Il server tunnel risponde alle richieste GET con una pagina statica. La risposta viene usata come probe dai servizi di bilanciamento del carico per verificare la durata del server tunnel. La risposta è statica e non contiene informazioni riservate.

  • Vpn per app e supporto del dominio di primo livello : l'uso per app-VPN con l'uso interno di domini locali di primo livello non è supportato da Microsoft Tunnel.

Firewall

Per impostazione predefinita, Microsoft Tunnel e il server usano le porte seguenti:

Porte in ingresso:

  • TCP 443: richiesto da Microsoft Tunnel.
  • UDP 443: richiesto da Microsoft Tunnel.
  • TCP 22: facoltativo. Usato per SSH/SCP nel server Linux.

Porte in uscita:

  • TCP 443: obbligatorio per accedere ai servizi Intune. Richiesto da Docker o Podman per eseguire il pull delle immagini.

Quando si crea la configurazione del server per il tunnel, è possibile specificare una porta diversa rispetto al valore predefinito 443. Se si specifica una porta diversa, configurare i firewall per supportare la configurazione.

Altri requisiti:

Per accedere al servizio token di sicurezza e all'archiviazione di Azure per i log, fornire l'accesso ai nomi FQDN seguenti:

  • Servizio token di sicurezza: *.sts.windows.net
  • Archiviazione di Azure per i log del tunnel: *.blob.core.windows.net
  • Altri URL degli endpoint di archiviazione: *.blob.storage.azure.net
  • Microsoft Intune:*.manage.microsoft.com
  • Autenticazione Microsoft: login.microsoftonline.com
  • Microsoft Graph: graph.microsoft.com
  • Configurare le regole del firewall per supportare le configurazioni dettagliate in Configurazione regole del firewall client di Registro artefatti Microsoft (MAR).

Proxy

È possibile usare un server proxy con Microsoft Tunnel.

Nota

Le configurazioni del server proxy non sono supportate con le versioni di Android precedenti alla versione 10. Per altre informazioni, vedere VpnService.Builder nella documentazione per sviluppatori Android.

Nota

Assicurarsi che le applicazioni LOB Android supportano la configurazione automatica del proxy o del proxy diretto sia per MDM che per MAM.

Nota

Problema noto: gli utenti che tentano di accedere a Edge usando i propri account personali o aziendali possono riscontrare problemi quando viene configurata una configurazione automatica del proxy.Known Issue: Users who are trying to sign in to Edge using their personal or corporate accounts may face issues when a Proxy Auto-Configuration (PAC) is configured. In questo scenario, il processo di accesso potrebbe non riuscire, impedendo all'utente di accedere alle risorse interne.

Soluzioni alternative: per risolvere questo problema, Microsoft Tunnel offre il tunneling diviso come opzione. Il tunneling diviso consente agli utenti di includere solo le route che richiedono un proxy escludendo i server di accesso e i percorsi di autenticazione dal routing attraverso il tunnel. Questa soluzione alternativa garantisce che il processo di accesso non sia interessato dalla configurazione PAC, consentendo all'utente di accedere alle risorse interne e di esplorare Internet.

Il proxy diretto è anche un'opzione senza split tunneling per il funzionamento dell'accesso in Edge tramite account aziendali. Ciò comporta la configurazione di Microsoft Tunnel per l'uso di un proxy diretto anziché di un URL PAC.

Se non è necessario alcun accesso utente in Edge, il PAC è supportato per l'esplorazione normale e l'accesso alle risorse interne.

Le considerazioni seguenti consentono di configurare il server Linux e l'ambiente per il corretto funzionamento:

Configurare un proxy in uscita per Docker

  • Se si usa un proxy interno, potrebbe essere necessario configurare l'host Linux per l'uso del server proxy usando le variabili di ambiente. Per usare le variabili, modificare il file /etc/environment nel server Linux e aggiungere le righe seguenti:

    http_proxy=[address]
    https_proxy=[address]

  • I proxy autenticati non sono supportati.

  • Il proxy non può eseguire interruzioni e controlli perché il server Linux usa l'autenticazione reciproca TLS durante la connessione a Intune.

  • Configurare Docker per l'uso del proxy per il pull delle immagini. A tale scopo, modificare il file /etc/systemd/system/docker.service.d/http-proxy.conf nel server Linux e aggiungere le righe seguenti:

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

    Nota

    Microsoft Tunnel non supporta Microsoft Entra proxy di applicazione o soluzioni proxy simili.

Configurare un proxy in uscita per Podman

I dettagli seguenti consentono di configurare un proxy interno quando si usa Podman:

  • I proxy autenticati non sono supportati.

  • Il proxy non può eseguire interruzioni e controlli perché il server Linux usa l'autenticazione reciproca TLS durante la connessione a Intune.

  • Podman legge le informazioni del proxy HTTP archiviate in /etc/profile.d/http_proxy.sh. Se questo file non esiste nel server, crearlo. Modificare http_proxy.sh per aggiungere le due righe seguenti. Nelle righe seguenti, 10.10.10.1:3128 è una voce di esempio address:port. Quando si aggiungono queste righe, sostituire 10.10.10.1:3128 con i valori per l'indirizzo IP proxy:porta:

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

    Se si ha accesso a Red Hat Customer Portal, è possibile visualizzare l'articolo knowledge base associato a questa soluzione. Vedere Configurazione delle variabili proxy HTTP per Podman - Red Hat Customer Portal.

  • Quando si aggiungono queste due righe a http_proxy.sh prima di installare Microsoft Tunnel Gateway eseguendo mstunnel-setup, lo script configura automaticamente le variabili di ambiente proxy del gateway tunnel in /etc/mstunnel/env.sh.

    Per configurare un proxy al termine dell'installazione del gateway di Microsoft Tunnel, eseguire le azioni seguenti:

    1. Modificare o creare il file /etc/profile.d/http_proxy.sh e aggiungere le due righe dal punto elenco precedente.

    2. Modificare /etc/mstunnel/env.sh e aggiungere le due righe seguenti alla fine del file. Come le righe precedenti, sostituire il valore address:port di esempio 10.10.10.1:3128 con i valori per l'indirizzo IP proxy:porta:

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

    3. Riavviare il server del gateway tunnel: Eseguire mst-cli server restart

    Tenere presente che RHEL usa SELinux. Poiché un proxy che non viene eseguito su una porta SELinux per http_port_t può richiedere una configurazione aggiuntiva, verificare l'uso delle porte gestite SELinux per HTTP. Per visualizzare le configurazioni, eseguire il comando seguente: sudo semanage port -l | grep "http_port_t"

    Esempio dei risultati del comando port check. In questo esempio, il proxy usa 3128 e non è elencato:

    Screenshot che visualizza i risultati del controllo della porta.

    • Se il proxy viene eseguito su una delle porte SELinux per http_port_t, è possibile continuare con il processo di installazione del gateway tunnel.

    • Se il proxy non viene eseguito su una porta SELinux per http_port_t come nell'esempio precedente, è necessario eseguire configurazioni aggiuntive.

      Se la porta proxy non è elencata perhttp_port_t, verificare se la porta proxy è usata da un altro servizio. Usare il comando semanage per controllare prima la porta usata dal proxy e successivamente, se necessario, per modificarla. Per controllare la porta usata dal proxy, eseguire: sudo semanage port -l | grep "your proxy port"

      Esempio dei risultati del controllo di un servizio che potrebbe usare la porta:

      Screenshot che visualizza i risultati del controllo del servizio.

      • Nell'esempio, la porta prevista (3128) viene usata da calamari, che si tratta di un servizio proxy del sistema operativo. I criteri SELinux proxy squid fanno parte di molte distribuzioni comuni. Poiché calamari usa la porta 3128 (la porta di esempio), è necessario modificare le porte http_port_t e aggiungere la porta 3128 per essere consentita tramite SELinux per il proxy usato da Tunnel. Per modificare l'uso della porta, eseguire il comando seguente: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

        Esempio del comando per modificare la porta:

        Screenshot che mostra un esempio del comando di modifica della porta.

        Dopo aver eseguito il comando per modificare la porta, eseguire il comando seguente per verificare se la porta viene usata da un altro servizio: sudo semanage port -l | grep "your proxy port"

        Esempio del comando per controllare la porta dopo aver modificato la porta:

        Screenshot del controllo della porta dopo la modifica.

        In questo esempio la porta 3128 è ora associata sia a http_port-t che a squid_port_t. Tale risultato è previsto. Se la porta proxy non è elencata quando si esegue il comando sudo semanage port -l | grep "your_proxy_port", eseguire il comando per modificare nuovamente la porta, ma il comando -m nel comando semanage con -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Configurare Podman per l'uso del proxy per scaricare gli aggiornamenti delle immagini

È possibile configurare Podman per usare il proxy per scaricare immagini aggiornate (pull) per Podman:

  1. Nel server di tunneling usare un prompt dei comandi per eseguire il comando seguente per aprire un editor per il file di sostituzione per il servizio Microsoft Tunnel:

    systemctl edit --force mstunnel_monitor

  2. Aggiungere le tre righe seguenti al file. Sostituire ogni istanza di [address] con il DN o l'indirizzo proxy e quindi salvare il file:

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

  3. Eseguire quindi quanto segue al prompt dei comandi:

    systemctl restart mstunnel_monitor

  4. Infine, eseguire quanto segue al prompt dei comandi per verificare che la configurazione sia riuscita:

    systemctl show mstunnel_monitor | grep http_proxy

    Se la configurazione ha esito positivo, i risultati sono simili alle informazioni seguenti:

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

Aggiornare il server proxy in uso dal server di tunnel

Per modificare la configurazione del server proxy usata dall'host Linux del server di tunneling, seguire questa procedura:

  1. Nel server di tunnel modificare /etc/mstunnel/env.sh e specificare il nuovo server proxy.

  2. Eseguire mst-cli install.

    Questo comando ricompila i contenitori con i nuovi dettagli del server proxy. Durante questo processo viene chiesto di verificare il contenuto di /etc/mstunnel/env.sh e di assicurarsi che il certificato sia installato. Il certificato deve essere già presente dalla configurazione del server proxy precedente.

    Per confermare e completare la configurazione, immettere sì.

Piattaforme

I dispositivi devono essere registrati in Intune per essere supportati con Microsoft Tunnel. Sono supportate solo le piattaforme per dispositivi seguenti:

  • iOS/iPadOS

  • Android Enterprise:

    • Completamente gestito
    • profilo di lavoro Corporate-Owned
    • Personally-Owned Profilo di lavoro

    Nota

    I dispositivi dedicati Android Enterprise non sono supportati da Microsoft Tunnel.

Tutte le piattaforme supportano le funzionalità seguenti:

  • Microsoft Entra l'autenticazione al tunnel usando nome utente e password.
  • Active Directory Federation Services autenticazione (AD FS) al tunnel usando nome utente e password.
  • Supporto per app.
  • Tunnel manuale completo del dispositivo tramite un'app Tunnel, in cui l'utente avvia la VPN e seleziona Connetti.
  • Suddivisione del tunneling. Tuttavia, nelle regole di split tunneling iOS vengono ignorate quando il profilo VPN usa per vpn per app.

Il supporto per un proxy è limitato alle piattaforme seguenti:

  • Android 10 e versioni successive
  • iOS/iPadOS

Autorizzazioni

Per gestire Microsoft Tunnel, gli utenti devono disporre di autorizzazioni incluse nel gruppo di autorizzazioni Gateway di Microsoft Tunnel in Intune. Per impostazione predefinita, Intune amministratori e gli amministratori Microsoft Entra dispongono di queste autorizzazioni. È anche possibile aggiungerli ai ruoli personalizzati creati per il tenant Intune.

Durante la configurazione di un ruolo, nella pagina Autorizzazioni espandere Gateway di Microsoft Tunnel e quindi selezionare le autorizzazioni da concedere.

Screenshot delle autorizzazioni del gateway tunnel nell'interfaccia di amministrazione Microsoft Intune.

Il gruppo di autorizzazioni del gateway di Microsoft Tunnel concede le autorizzazioni seguenti:

  • Crea : configurare i server e i siti del gateway di Microsoft Tunnel. Le configurazioni del server includono le impostazioni per gli intervalli di indirizzi IP, i server DNS, le porte e le regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.

  • Aggiornamento (modifica): aggiornare le configurazioni e i siti del server del gateway di Microsoft Tunnel. Le configurazioni del server includono le impostazioni per gli intervalli di indirizzi IP, i server DNS, le porte e le regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.

  • Elimina : eliminare le configurazioni e i siti del server del gateway di Microsoft Tunnel. Le configurazioni del server includono le impostazioni per gli intervalli di indirizzi IP, i server DNS, le porte e le regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.

  • Lettura : visualizzare le configurazioni e i siti del server del gateway Di Microsoft Tunnel. Le configurazioni del server includono le impostazioni per gli intervalli di indirizzi IP, i server DNS, le porte e le regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.

Eseguire lo strumento di preparazione

Prima di avviare un'installazione del server, è consigliabile scaricare ed eseguire la versione più recente dello strumento mst-readiness . Lo strumento è uno script eseguito nel server Linux ed esegue le azioni seguenti:

  • Verifica che l'account Microsoft Entra usato per installare Microsoft Tunnel disponga dei ruoli necessari per completare la registrazione.

  • Conferma che la configurazione di rete consente a Microsoft Tunnel di accedere agli endpoint Microsoft necessari.

  • Verifica la presenza del modulo ip_tables nel server Linux. Questo controllo è stato aggiunto allo script l'11 febbraio 2022, quando è stato aggiunto il supporto per RHEL 8.5. RHEL 8.5 in un secondo momento non carica il modulo ip_tables per impostazione predefinita. Se mancano dopo l'installazione del server Linux, è necessario caricare manualmente il modulo ip_tables.

Importante

Lo strumento di preparazione non convalida le porte in ingresso, che è una configurazione errata comune. Dopo l'esecuzione dello strumento di preparazione, esaminare i prerequisiti del firewall e convalidare manualmente il passaggio del traffico in ingresso da parte dei firewall.

Lo strumento mst-readiness ha una dipendenza da jq, un processore JSON da riga di comando. Prima di eseguire lo strumento di preparazione, assicurarsi che jq sia installato. Per informazioni su come ottenere e installare jq, vedere la documentazione relativa alla versione di Linux usata.

Per usare lo strumento di preparazione:

  1. Ottenere la versione più recente dello strumento di preparazione usando uno dei metodi seguenti:

    • Scaricare lo strumento direttamente usando un Web browser. Passare a per https://aka.ms/microsofttunnelready scaricare un file denominato mst-readiness.

    • Accedere a Microsoft Intune'interfaccia> diamministrazione> Amministrazione tenantDi Microsoft Tunnel Gateway, selezionare la scheda Server, selezionare Crea per aprire il riquadro Crea un server e quindi selezionare Scarica strumento di preparazione.

    • Usare un comando Linux per ottenere direttamente lo strumento di preparazione. Ad esempio, è possibile usare wget o curl per aprire il collegamento https://aka.ms/microsofttunnelready.

      Ad esempio, per usare wget e registrare i dettagli per mst-readiness durante il download, eseguire wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

    Lo script può essere eseguito da qualsiasi server Linux nella stessa rete del server che si intende installare, che consente agli amministratori di rete di usare lo script per risolvere i problemi di rete in modo indipendente.

  2. Per convalidare la configurazione di rete e Linux, eseguire lo script con i comandi seguenti. Questi comandi impostano le autorizzazioni di esecuzione per lo script, convalidano che il tunnel possa connettersi agli endpoint corretti e quindi verificare la presenza di utilità usate da Tunnel:

    • sudo ./mst-readiness

    • sudo ./mst-readiness network - Questo comando esegue le azioni seguenti e quindi segnala l'esito positivo o l'errore per entrambi:

      • Prova a connettersi a ogni endpoint Microsoft che verrà usato dal tunnel.
      • Verifica che le porte necessarie siano aperte nel firewall.

    • sudo ./mst-readiness utils - Questo comando verifica che siano disponibili utilità usate da Tunnel come Docker o Podman e ip_tables.

  3. Per verificare che l'account che verrà usato per installare Microsoft Tunnel disponga dei ruoli e delle autorizzazioni necessari per completare la registrazione, eseguire lo script con la riga di comando seguente: ./mst-readiness account

    Lo script richiede di usare un computer diverso con un Web browser, che viene usato per eseguire l'autenticazione per Microsoft Entra ID e per Intune. Lo strumento segnala l'esito positivo o un errore.

Per altre informazioni su questo strumento, vedere Riferimento per mst-cli nell'articolo di riferimento per Microsoft Tunnel.

Caricare manualmente ip_tables

Anche se la maggior parte delle distribuzioni Linux carica automaticamente il modulo ip_tables, alcune distribuzioni potrebbero non essere disponibili. Ad esempio, RHEL 8.5 non carica il ip_tables per impostazione predefinita.

Per verificare la presenza di questo modulo, eseguire la versione più recente dello strumento mst-readiness nel server Linux. Il controllo per ip_tables è stato aggiunto allo script degli strumenti di preparazione l'11 febbraio 2022.

Se il modulo non è presente, lo strumento si arresta nel controllo del modulo ip_tables. In questo scenario è possibile eseguire i comandi seguenti per caricare manualmente il modulo.

Caricare manualmente il modulo ip_tables

Nel contesto di sudo eseguire i comandi seguenti nel server Linux:

  1. Convalidare la presenza di ip_tables nel server: lsmod |grep ip_tables

  2. Se ip_tables non è presente, eseguire quanto segue per caricare immediatamente il modulo nel kernel, senza riavviare: /sbin/modprobe ip_tables

  3. Eseguire di nuovo la convalida per verificare che le tabelle siano ora caricate: lsmod |grep ip_tables

Importante

Quando si aggiorna il server tunnel, un modulo ip_tables caricato manualmente potrebbe non essere persistente. Ciò può richiedere il ricaricamento del modulo al termine dell'aggiornamento. Al termine dell'aggiornamento del server, esaminare il server per verificare la presenza del modulo ip_tables.

Se le tabelle non sono presenti, usare i passaggi precedenti per ricaricare il modulo, con il passaggio aggiuntivo per riavviare il server dopo il caricamento del modulo.

Configurare Linux per caricare ip_tables all'avvio

Nel contesto di sudo eseguire il comando seguente nel server Linux per creare un file di configurazione che carica il ip_tables nel kernel durante l'avvio: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Caricare manualmente il modulo tun

Microsoft Tunnel richiede il modulo tun , tuttavia alcune distribuzioni Linux non caricano il modulo tun per impostazione predefinita.

Per convalidare il presente del modulo tun nel server, eseguire: lsmod |grep tun

  1. Se tun non è presente, eseguire quanto segue per caricare immediatamente il modulo nel kernel, senza riavviare: /sbin/modprobe tun

  2. Eseguire di nuovo la convalida per verificare che il modulo tun sia ora caricato: lsmod |grep tun

Importante

Quando si aggiorna il server tunnel, un modulo tun caricato manualmente potrebbe non essere persistente. Ciò può richiedere il ricaricamento del modulo dopo il completamento dell'aggiornamento. Al termine dell'aggiornamento del server, esaminare il server per verificare la presenza del modulo tun .

Se non è presente, usare i passaggi precedenti per ricaricare il modulo, con il passaggio aggiuntivo per riavviare il server dopo il caricamento del modulo.

Configurare Linux per il caricamento di tun all'avvio

Nel contesto di sudo eseguire il comando seguente nel server Linux per creare un file di configurazione che carica tun nel kernel durante l'avvio: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Passaggi successivi

Configurare Microsoft Tunnel