Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Prima di installare il gateway VPN di Microsoft Tunnel per Microsoft Intune, rivedere 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 il tunnel Microsoft.
A livello generale, Microsoft Tunnel richiede:
Una sottoscrizione di Azure.
Un abbonamento a Microsoft Intune (piano 1).
Nota
Questo prerequisito è per Microsoft Tunnel e non include Microsoft Tunnel per la gestione delle applicazioni per dispositivi mobili, che è una funzionalità avanzata di Microsoft Intune che richiede licenze aggiuntive oltre a Microsoft Intune.
Per completare la configurazione di Microsoft Tunnel, all'account che verrà usato per registrare Tunnel Gateway con Microsoft Intune e il tenant di Intune deve essere assegnato il ruolo Microsoft Entra ID di amministratore di Intune e ricevere una licenza di Intune.
Un server Linux che esegue contenitori. Il server può essere locale o nel cloud e supporta uno dei seguenti tipi di contenitore:
- 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 Tunnel Gateway.
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 descrivono in dettaglio i prerequisiti per Microsoft Tunnel e forniscono indicazioni sull'uso dello strumento di preparazione.
Nota
Tunnel e Global Secure Access (GSA) non possono essere usati contemporaneamente nello stesso dispositivo.
Supporto del cloud per enti pubblici
Microsoft Tunnel è supportato con i seguenti ambienti cloud sovrani:
- U.S. Government Community Cloud (GCC) High
Microsoft Tunnel non è supportato in Microsoft Azure gestito da 21Vianet.
Per ulteriori informazioni, vedere Descrizione del servizio GCC di Microsoft Intune per il governo degli Stati Uniti.
Server Linux
Configurare una macchina virtuale basata su Linux o un server fisico in cui installare Microsoft Tunnel Gateway.
Nota
Sono supportati solo i sistemi operativi e le versioni del contenitore elencati nella tabella seguente. Le versioni non elencate non sono supportate. Solo dopo aver verificato i test e la supportabilità, le nuove versioni vengono aggiunte a questo elenco. Mantieni aggiornato il sistema operativo anche con gli aggiornamenti della sicurezza.
Distribuzioni Linux supportate: la tabella seguente illustra in dettaglio quali versioni di Linux sono supportate per il server Tunnel e il contenitore necessario:
Versione di distribuzione Requisiti del contenitore Considerazioni Red Hat (RHEL) 8.9 Podman 4.4.1 Il supporto termina a novembre 2025. Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi 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. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.3 Podman 4.6.1. (impostazione predefinita) Il supporto termina a novembre 2025. Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.4 Podman 4.9.4-rhel (impostazione predefinita) Il supporto termina a novembre 2025. Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.5 Podman 5.2.2 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.6 Podman 5.4.0 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.7 Podman 5.8.2 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 9.8 Podman 5.8.2+ (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Red Hat (RHEL) 10.0 Podman 5.4.0 (impostazione predefinita) Questa versione di RHEL non carica automaticamente il modulo ip_tables nel kernel Linux. Se si utilizza 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 quindi reinstallare Microsoft Tunnel.Ubuntu 24.04 Docker CE Ubuntu 26.04 Docker CE Importante
Nell'aprile del 2023, Ubuntu terminerà il supporto per Ubuntu 18.04. Con la fine del supporto da parte 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 linee guida seguenti per soddisfare l'uso previsto:
# Dispositivi # CPU Memoria GB # 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 Il supporto è scalabile linearmente. 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 uno dei seguenti dispositivi sul 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 forniscono un ambiente di esecuzione coerente, monitoraggio dell'integrità e correzione proattiva e un'esperienza di aggiornamento pulita.
Per informazioni sull'installazione e la configurazione di Docker o Podman, vedere:
Installare Docker Engine in CentOS o Red Hat Enterprise Linux 7.
Nota
Il collegamento precedente ti indirizza alle istruzioni per il download e l'installazione di CentOS. Usare le stesse istruzioni per RHEL 7.4. La versione installata in RHEL 7.4 per impostazione predefinita è troppo vecchia per supportare Microsoft Tunnel Gateway.
-
Queste versioni di RHEL non supportano Docker. Invece, queste versioni usano Podman, e podman fa parte di un modulo chiamato "container-tools". In questo contesto, un modulo è un insieme di pacchetti RPM che rappresentano un componente e che di solito si installano insieme. Un tipico modulo contiene pacchetti con un'applicazione, pacchetti con le librerie di dipendenze specifiche dell'applicazione, pacchetti con la documentazione per l'applicazione e pacchetti con utilità helper. Per maggiori informazioni, consultate Introduzione ai moduli nella documentazione di Red Hat.
Nota
Rootless Podman: Microsoft Tunnel supporta l'uso di un contenitore Podman rootless.
L'uso di rootless Podman richiede prerequisiti aggiuntivi rispetto a quelli descritti in questo articolo e l'uso di una riga di comando modificata quando si avvia lo script di installazione del tunnel. Per informazioni sui prerequisiti aggiuntivi e sulla riga di comando di installazione, vedere Usare un contenitore Podman rootless nell'articolo Configurare Microsoft Tunnel per Intune.
Certificato TLS (Transport Layer Security): il server Linux richiede un certificato TLS attendibile per proteggere la connessione tra i dispositivi e il server Tunnel Gateway. Durante l'installazione di Tunnel Gateway, si aggiunge al server il certificato TLS e l'intera catena di certificati attendibili.
Il nome alternativo soggetto (SAN) del certificato TLS utilizzato per proteggere l'endpoint Tunnel Gateway deve corrispondere all'indirizzo IP o al nome di dominio completo del server Tunnel Gateway.
Per i dispositivi iOS, i certificati TLS pubblici devono essere emessi dalla CA radice e avere una data di scadenza massima di 398 giorni. I certificati emessi dalle CA radice aggiunte dall'utente o aggiunte dall'amministratore possono avere una data di scadenza massima fino a due anni (730 giorni). Per altre informazioni su questi requisiti per i certificati TLS, vedere Informazioni sui prossimi limiti per i certificati attendibili in support.apple.com.
Per i dispositivi Android, è consigliabile che i certificati TLS pubblici emessi dalla CA radice abbiano una data di scadenza massima di 398 giorni.
Il supporto dei caratteri jolly è limitato. Ad esempio, *.contoso.com è supportato, ma cont*.com non è supportato.
Durante l'installazione del server Tunnel Gateway, è necessario copiare l'intera catena di certificati attendibili nel server Linux. Lo script di installazione fornisce il percorso in cui si copiano i file dei certificati e richiede di eseguire questa operazione.
Se si usa un certificato TLS che non è pubblicamente attendibile, è necessario eseguire il push dell'intera catena di attendibilità ai dispositivi che usano un profilo di certificato attendibile di Intune.
Il certificato TLS può essere in formato PEM o pfx .
Per supportare il controllo dello stato di revoca del certificato TLS , verificare che l'indirizzo OCSP (Online Certificate Status Protocol) o dell'elenco di revoche di certificati (CRL), definito dal certificato TLS, sia accessibile dal server.
Configurare il certificato dei client Tunnel con una chiave a 2048 bit o superiore. Consigliamo chiavi più grandi per aiutare la tua distribuzione a rimanere a supporto dei requisiti SSL/TLS futuri e in evoluzione da varie soluzioni di libreria SSL/TLS.
Consiglio
Rivedi periodicamente i requisiti della libreria SSL/TLS scelta per garantire che l'infrastruttura e i certificati rimangano supportati e conformi alle recenti modifiche per tale libreria e riemetti nuovamente i certificati client Tunnel quando necessario per rimanere aggiornato con i requisiti in evoluzione delle soluzioni.
Versione TLS: Per impostazione predefinita, le connessioni tra client e server di Microsoft Tunnel usano TLS 1.3. Quando TLS 1.3 non è disponibile, la connessione può eseguire il fallback per usare TLS 1.2.
Rete bridge predefinita
Entrambi i container Podman e Docker utilizzano una rete bridge per inoltrare il traffico attraverso l'host Linux. Quando la rete di bridge dei container è in conflitto con una rete aziendale, Tunnel Gateway non può instradare correttamente il traffico verso quella 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 l'utilizzo di una rete bridge specificata.
Importante
Il server Tunnel Gateway deve essere installato prima di poter modificare la configurazione di rete del bridge.
Modificare la rete bridge predefinita usata da Docker
Docker utilizza il file /etc/docker/daemon.json per configurare un nuovo indirizzo IP del bridge predefinito. Nel file, l'indirizzo IP del bridge deve essere specificato in notazione CIDR (Classless inter-domain routing), un modo compatto per rappresentare un indirizzo IP insieme alla subnet mask e al prefisso di routing associati.
Importante
L'indirizzo IP usato nei passaggi seguenti è un esempio. Assicurati che l'indirizzo IP utilizzato non sia in conflitto con la rete aziendale.
Utilizzare il comando seguente per arrestare il contenitore MS Tunnel Gateway:
sudo mst-cli server stop ; sudo mst-cli agent stopQuindi, esegui il comando seguente per rimuovere il dispositivo bridge Docker esistente:
sudo ip link del docker0Se il file /etc/docker/daemon.json è presente sul tuo server, usa un editor di file come vi o nano per modificare il file. Esegui l'editor di file con autorizzazioni root o sudo:
- Quando la voce "bip": è presente con un indirizzo IP, modificarlo aggiungendo un nuovo indirizzo IP in notazione CIDR.
- Quando la voce "bip": non è presente, è necessario aggiungere sia il valore "bip": che il nuovo indirizzo IP in notazione CIDR.
L'esempio seguente mostra la struttura di un file daemon.json con una voce "bip" aggiornata che usa l'indirizzo IP modificato "192.168.128.1/24".
Esempio di daemon.json:
{ "bip": "192.168.128.1/24" }Se il file /etc/docker/daemon.json non è presente sul server, eseguire un comando simile all'esempio seguente per creare il file e definire l'IP del bridge che si desidera utilizzare.
Esempio:
sudo echo '{ "bip":"192.168.128.1/24" }' > /etc/docker/daemon.jsonUtilizzare il comando seguente per avviare il contenitore MS Tunnel Gateway:
sudo mst-cli agent start ; sudo mst-cli server start
Per ulteriori informazioni, consulta Utilizzo di reti bridge nella documentazione di Docker.
Modificare la rete bridge predefinita utilizzata da Podman
Podman utilizza il file /etc/cni/net.d come 87-podman-bridge.conflist per configurare un nuovo indirizzo IP del bridge predefinito.
Utilizzare il comando seguente per arrestare il contenitore MS Tunnel Gateway:
sudo mst-cli server stop ; sudo mst-cli agent stopQuindi, esegui il seguente comando per rimuovere il dispositivo bridge Podman esistente:
sudo ip link del cni-podman0Utilizzando i permessi di root e un editor di file come vi o nano, modificare /etc/cni/net.d come 87-podman-bridge.conflist per aggiornare i valori predefiniti per "subnet:" e "gateway:" sostituendo i valori predefiniti di Podman con gli indirizzi di subnet e gateway desiderati. L'indirizzo della subnet deve essere specificato in notazione CIDR.
Le impostazioni predefinite di Podman sono:
- Subnet: 10.88.0.0/16
- Gateway: 10.88.0.1
Utilizzare il comando seguente per riavviare i contenitori di MS Tunnel Gateway:
sudo mst-cli agent start ; sudo mst-cli server start
Per ulteriori informazioni, consultate Configurazione della rete di container con Podman nella documentazione di Red Hat.
Controllo del sistema Linux
Il controllo del sistema Linux consente di identificare informazioni rilevanti per la sicurezza o 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 del sistema, un server Linux deve avere il pacchetto auditd installato in /etc/audit/auditd.conf.
Ogni volta che si esegue lo strumento mst-readiness , lo strumento potrebbe visualizzare un avviso che indica che auditd manca. Per abilitare il controllo di directory specifiche del tunnel, assicurarsi di installare il pacchetto auditd prima di eseguire mstunnel-setup.
I dettagli su come implementare il controllo dipendono dalla piattaforma Linux usata:
Red Hat: le versioni di Red Had Enterprise Linux 7 e successive installano il pacchetto auditd per impostazione predefinita. Tuttavia, se il pacchetto non è installato, puoi usare la seguente riga di comando sul server Linux per installarlo:
sudo dnf install audit audispd-pluginsIn genere, il pacchetto verificato è disponibile nell'archivio predefinito di ciascuna versione REHL.
Per ulteriori informazioni sull'utilizzo del controllo del sistema su RHEL, vedere Configurare il controllo del sistema Linux con auditd nel blog di Red Hat.
Ubuntu: Per usare l'auditing del sistema con Ubuntu è necessario installare manualmente il pacchetto auditd . A tale scopo, usare la riga di comando seguente nel server Linux:
sudo apt install auditd audispd-pluginsIn genere, il pacchetto auditd è 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 sul sito Web di dev.to originariamente pubblicato su kubefront.com.
Rete
Abilita l'inoltro dei pacchetti per IPv4: ogni server Linux che ospita il software del server Tunnel deve avere abilitato l'inoltro IP per IPv4. Per verificare lo stato dell'inoltro IP, sul server eseguire uno dei seguenti comandi generici come root o sudo. Entrambi i comandi restituiscono un valore pari a 0 per disabled e un valore pari a 1 per enabled:
sysctl net.ipv4.ip_forwardcat /proc/sys/net/ipv4/ip_forward
Se non è abilitato, è possibile abilitare temporaneamente l'inoltro IP eseguendo uno dei seguenti comandi generici come root o sudo sul server. Questi comandi possono modificare la configurazione dell'inoltro IP fino al riavvio del server. Dopo un riavvio, il server riporta il comportamento di inoltro IP allo stato precedente. Per entrambi i comandi, utilizzare il valore 1 per abilitare l'inoltro. Il valore 0 disabilita l'inoltro. Gli esempi di comando seguenti utilizzano il valore 1 per abilitare l'inoltro:
sysctl -w net.ipv4.ip_forward=1echo 1 > /proc/sys/net/ipv4/ip_forward
Per rendere permanente l'inoltro IP, su 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=1Affinché questa modifica abbia effetto, è necessario riavviare il server o eseguire
sysctl -p.Se la voce prevista non è presente nel file sysctl.conf, consultare la documentazione della distribuzione utilizzata per informazioni su come abilitare l'inoltro IP. In genere, è possibile modificare sysctl.conf per aggiungere la riga mancante alla fine del file per abilitare permanentemente 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.
NIC 1 - Questa NIC gestisce il traffico proveniente 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.
NIC 2 - Questa NIC gestisce il traffico verso le risorse locali e deve trovarsi nella rete interna privata senza segmentazione della 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.
Load balancers(Optional): Se si sceglie di aggiungere un load balancer, consultare la documentazione del fornitore per i dettagli di configurazione. Prendi in considerazione il traffico di rete e le porte del firewall specifiche di Intune e Microsoft Tunnel.
Il server Tunnel risponde alle richieste GET con una pagina statica. La risposta viene utilizzata come probe dai servizi di bilanciamento del carico per verificare la disponibilità del server Tunnel. La risposta è statica e non contiene informazioni sensibili.
Supporto per VPN per app e domini di primo livello - L'uso per VPN per app con uso interno di domini di primo livello locali non è supportato da Microsoft Tunnel.
Firewall
Per impostazione predefinita, il tunnel Microsoft e il server utilizzano le porte seguenti:
Porte in entrata:
- TCP 443 - Richiesto da Microsoft Tunnel.
- UDP 443 - Richiesto da Microsoft Tunnel.
- TCP 22 - Facoltativo. Utilizzato per SSH/SCP al server Linux.
Porte in uscita:
- TCP 443 - Necessario per accedere ai servizi Intune. Richiesto da Docker o Podman per estrarre le immagini.
Quando si crea la configurazione del server per il tunnel, è possibile specificare una porta diversa da quella predefinita di 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 di dominio completi 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 delle regole del firewall client del Registro artefatti Microsoft (MAR).
Proxy
È possibile usare un server proxy con Microsoft Tunnel.
Nota
Assicurarsi che le applicazioni line-of-business Android supportino il proxy diretto o la configurazione automatica del proxy (PAC) sia per MDM che per MAM.
Nota
Problema noto: gli utenti che tentano di accedere a Edge utilizzando il proprio account personale o aziendale possono riscontrare problemi quando viene configurata una configurazione automatica del proxy (PAC). In questo scenario, il processo di accesso potrebbe non riuscire, impedendo all'utente di accedere alle risorse interne.
Soluzioni alternative: per risolvere il problema, Microsoft Tunnel offre l'opzione di split tunneling. Lo split tunneling 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 della configurazione PAC, consentendo all'utente di accedere alle risorse interne ed esplorare Internet.
Il proxy diretto è anche un'opzione senza split tunneling per il funzionamento dell'accesso in Edge con gli account aziendali. Ciò comporta la configurazione di Microsoft Tunnel per l'uso di un proxy diretto anziché di un URL PAC.
Se non è richiesto l'accesso di alcun utente in Edge, PAC è supportata per la normale esplorazione e accesso alle risorse interne.
Le seguenti considerazioni possono aiutarti a configurare il server Linux e il tuo ambiente per il successo:
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 tramite le variabili di ambiente. Per utilizzare le variabili, modificare il file /etc/environment sul server Linux e aggiungere le seguenti righe, sostituendo l'indirizzo in ogni riga con l'indirizzo IP del proxy:porta:
http_proxy=address
https_proxy=addressI proxy autenticati non sono supportati.
Il proxy non può eseguire l'interruzione e l'ispezione perché il server Linux usa l'autenticazione reciproca TLS durante la connessione a Intune.
Configurare Docker per l'uso del proxy per estrarre le immagini. Per fare ciò, modificare il file /etc/systemd/system/docker.service.d/http-proxy.conf sul server Linux e aggiungere le seguenti righe:
[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 il proxy dell'applicazione Microsoft Entra o soluzioni proxy simili.
Configurare un proxy in uscita per Podman
I seguenti dettagli possono aiutarti a configurare un proxy interno quando utilizzi Podman:
I proxy autenticati non sono supportati.
Il proxy non può eseguire l'interruzione e l'ispezione perché il server Linux usa l'autenticazione reciproca TLS durante la connessione a Intune.
Podman legge le informazioni del proxy HTTP memorizzate in /etc/profile.d/http_proxy.sh. Se il file non esiste nel server, crearlo. Modificare http_proxy.sh per aggiungere le due righe seguenti. Nelle righe seguenti, 10.10.10.1:3128 è un esempio di indirizzo:voce porta. Quando si aggiungono queste righe, sostituire 10.10.10.1:3128 con i valori per l'indirizzo IP del proxy :porta:
export HTTP_PROXY=http://10.10.10.1:3128
export HTTPS_PROXY=http://10.10.10.1:3128Se si ha accesso al Red Hat Customer Portal, è possibile visualizzare l'articolo della Knowledge Base associato a questa soluzione. Consultate 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 di Tunnel Gateway in /etc/mstunnel/env.sh.
Per configurare un proxy al termine dell'installazione di Microsoft Tunnel Gateway, effettuare le operazioni seguenti:
Modifica o crea il file /etc/profile.d/http_proxy.sh e aggiungi le due righe del punto elenco precedente.
Modificare /etc/mstunnel/env.sh e aggiungere le due righe seguenti alla fine del file. Come nelle righe precedenti, sostituire il valore di esempio indirizzo:porta10.10.10.1:3128 con i valori per l'indirizzo IP del proxy :porta:
HTTP_PROXY=http://10.10.10.1:3128
HTTPS_PROXY=http://10.10.10.1:3128Riavviare il server Tunnel Gateway: Esegui
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, controllare l'uso delle porte gestite da 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:
Se il proxy viene eseguito su una delle porte SELinux per http_port_t, è possibile continuare con il processo di installazione di Tunnel Gateway.
Se il proxy non viene eseguito su una porta SELinux per http_port_t come nell'esempio precedente, è necessario effettuare 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 utilizzata dal proxy e poi, se necessario, per modificarla. Per controllare la porta usata dal proxy, esegui:
sudo semanage port -l | grep "your proxy port"Esempio dei risultati del controllo di un servizio che potrebbe usare la porta:
Nell'esempio, la porta prevista (3128) viene utilizzata da squid, che è un servizio proxy OSS. Proxy di Squid Le policy di SELinux fanno parte di molte distribuzioni comuni. Poiché squid utilizza la porta 3128 (la nostra porta di esempio), dobbiamo modificare le porte http_port_t e aggiungere la porta 3128 per essere consentita tramite SELinux per il proxy utilizzato da Tunnel. Per modificare l'utilizzo della porta, esegui il comando seguente:
sudo semanage port -m -t http_port_t -p tcp "your proxy port"Esempio del comando per modificare la porta:
Dopo aver eseguito il comando per modificare la porta, eseguire il comando seguente per verificare se la porta è 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:
Nell'esempio, la porta 3128 è ora associata sia a http_port-t che a squid_port_t. Questo risultato è previsto. Se la porta proxy non è elencata quando si esegue il comando sudo semanage port -l | grep "your_proxy_port", esegui il comando per modificare nuovamente la porta, ma la -m nel comando semanage con -a:
sudo semanage port -a -t http_port_t -p tcp "your proxy port"
Configurare Podman per utilizzare il proxy per scaricare gli aggiornamenti delle immagini
È possibile configurare Podman per utilizzare il proxy per scaricare (estrarre) immagini aggiornate per Podman. Questa configurazione è importante per gli aggiornamenti futuri. Poiché deve essere configurato dopo l'installazione di Tunnel Gateway, lo menzioniamo qui, ma abbiamo aggiunto la guida alla configurazione a Configure Podman per utilizzare il proxy per scaricare gli aggiornamenti delle immagini nell'articolo Configurare Microsoft Tunnel come attività da completare dopo l'installazione del server Tunnel Gateway.
Piattaforme
I dispositivi devono essere registrati in Intune per essere supportati con Microsoft Tunnel. Sono supportate solo le piattaforme di dispositivi seguenti:
iOS/iPadOS
Android Enterprise:
- Completamente gestito
- Corporate-Owned profilo di lavoro
- Personally-Owned Profilo di lavoro
Nota
I dispositivi dedicati Android Enterprise non sono supportati dal tunnel Microsoft.
Importante
Il supporto per Android 10 su Microsoft Tunnel è terminato il 31 marzo 2026. I dispositivi che eseguono Android 10 devono eseguire l'aggiornamento ad Android 11 o versione successiva per continuare a usare Microsoft Tunnel.
Tutte le piattaforme supportano le funzionalità seguenti:
- Autenticazione di Microsoft Entra al tunnel tramite nome utente e password.
- Autenticazione di Active Directory Federation Services (AD FS) nel tunnel utilizzando nome utente e password.
- Supporto per app.
- Tunnel manuale per l'intero dispositivo attraverso l'app Tunnel, in cui l'utente avvia la VPN e seleziona Connetti.
- Split tunneling. In iOS, tuttavia, le regole di split tunneling vengono ignorate quando il profilo VPN usa una VPN per app.
Il supporto per un proxy è limitato alle piattaforme seguenti:
- Android 11 e versioni successive
- iOS/iPadOS
Autorizzazioni
Per gestire Microsoft Tunnel, gli utenti devono disporre delle autorizzazioni incluse nel gruppo di autorizzazioni Microsoft Tunnel Gateway in Intune. Per impostazione predefinita, gli amministratori di Intune e gli amministratori di Microsoft Entra dispongono di queste autorizzazioni. È anche possibile aggiungerli ai ruoli personalizzati creati per il tenant di Intune.
Durante la configurazione di un ruolo, nella pagina Autorizzazioni espandere Microsoft Tunnel Gateway e quindi selezionare le autorizzazioni che si desidera concedere.
Il gruppo di autorizzazioni Microsoft Tunnel Gateway concede le autorizzazioni seguenti:
Creare - Configurare i server e isiti di Microsoft Tunnel Gateway. Le configurazioni dei server includono impostazioni per intervalli di indirizzi IP, server DNS, porte e regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.
Aggiorna (modifica) - Aggiorna le configurazioni e i siti del server Microsoft Tunnel Gateway. Le configurazioni dei server includono impostazioni per intervalli di indirizzi IP, server DNS, porte e regole di split tunneling. I siti sono raggruppamenti logici di più server che supportano Microsoft Tunnel.
Elimina : consente di eliminare le configurazioni e i siti del server Microsoft Tunnel Gateway. Le configurazioni dei server includono impostazioni per intervalli di indirizzi IP, server DNS, porte e 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 Microsoft Tunnel Gateway. Le configurazioni dei server includono impostazioni per intervalli di indirizzi IP, server DNS, porte e 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 che viene eseguito sul tuo server Linux ed esegue le seguenti azioni:
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 sul server Linux. Questo controllo è stato aggiunto allo script l'11 febbraio 2022, quando è stato aggiunto il supporto per RHEL 8.5. Versioni successive di RHEL 8.5, non caricare il modulo ip_tables per impostazione predefinita. Se dopo l'installazione del server Linux non sono presenti, è necessario caricare manualmente il modulo ip_tables.
Importante
Lo strumento di preparazione non convalida le porte in ingresso, il che è una configurazione errata comune. Dopo l'esecuzione dello strumento di conformità, esaminare i prerequisiti del firewall e verificare manualmente che i firewall passino il traffico in ingresso.
Lo strumento mst-readiness ha una dipendenza da jq, un processore JSON da riga di comando. Prima di eseguire lo strumento di conformità, verifica che jq sia installato. Per informazioni su come ottenere e installare jq, vedere la documentazione per la versione di Linux in uso.
Per usare lo strumento di preparazione:
Ottenere la versione più recente dello strumento di preparazione usando uno dei metodi seguenti:
Scarica lo strumento direttamente usando un Web browser. Vai a https://aka.ms/microsofttunnelready per scaricare un file denominato mst-readiness.
Accedere all Microsoft Intune interfaccia> di amministrazioneAmministrazione> tenantMicrosoft Tunnel Gateway, selezionare la scheda Server, selezionare Crea per aprire il riquadro Crea un server e quindi selezionare Scarica strumento di conformità.
Usare un comando di Linux per ottenere direttamente lo strumento di prontezza. Ad esempio, potete usare wget o curl per aprire il collegamento https://aka.ms/microsofttunnelready.
Ad esempio, per usare wget e log details 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 che si trova sulla stessa rete del server che si intende installare, in modo da consentire agli amministratori di rete di usare lo script per risolvere i problemi di rete in modo indipendente.
Per convalidare la configurazione di rete e di Linux, eseguire lo script con i comandi seguenti. Questi comandi impostano le autorizzazioni di esecuzione per lo script, verificano che il tunnel possa connettersi agli endpoint corretti e quindi verificano la presenza di utilità utilizzate dal tunnel:
sudo ./mst-readinesssudo ./mst-readiness network- Questo comando esegue le azioni seguenti e quindi segnala l'esito positivo o negativo per entrambe:- Prova a connettersi a ogni endpoint Microsoft usato dal tunnel.
- Verifica che le porte necessarie siano aperte nel firewall.
sudo ./mst-readiness utils- Questo comando convalida che le utilità utilizzate da Tunnel come Docker o Podman e ip_tables sono disponibili.
Per verificare che l'account che si userà 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 accountLo script richiede di usare un computer diverso con un Web browser, che si usa per eseguire l'autenticazione in Microsoft Entra ID e in Intune. Lo strumento segnala un esito positivo o un errore.
Per altre informazioni su questo strumento, vedere Informazioni di riferimento per mst-cli nell'articolo di riferimento per Microsoft Tunnel.
Installazione manuale di auditd per il controllo del sistema Linux
Lo strumento di preparazione verifica la presenza del pacchetto auditd per il controllo del sistema Linux. Poiché auditd è facoltativo e non obbligatorio, lo script di preparazione restituirà un avviso quando questo pacchetto non viene rilevato.
Auditd è installato per impostazione predefinita da RHEL 7 e versioni successive, ma potrebbe non essere installato per impostazione predefinita dalle distribuzioni Ubuntu. Quando non è presente, è possibile installarlo manualmente nel server Linux.
Per informazioni su come installarlo manualmente prima di installare il server Tunnel, vedere Controllo del sistema Linux più indietro in questo articolo.
Per installare auditd dopo aver installato Microsoft Tunnel, vedere Installare il controllo del sistema Linux dopo l'installazione del server Tunnel in Configurazione di Micrfosoft Tunnel.
Caricare manualmente ip_tables
Mentre la maggior parte delle distribuzioni Linux carica automaticamente il modulo ip_tables, alcune distribuzioni potrebbero non caricarlo. Ad esempio, RHEL 8.5 non carica il ip_tables per impostazione predefinita.
Per verificare la presenza di questo modulo, esegui la versione più recente dello strumento mst-readiness sul server Linux. Il controllo di ip_tables è stato aggiunto allo script degli strumenti di preparazione l'11 febbraio 2022.
Se il modulo non è presente, lo strumento si arresta al ip_tables controllo del modulo. In questo scenario è possibile eseguire i comandi seguenti per caricare manualmente il modulo.
Caricare manualmente il modulo ip_tables
Nel contesto di sudo, esegui i seguenti comandi sul tuo server Linux:
Verificare la presenza di ip_tables nel server:
lsmod |grep ip_tablesSe ip_tables non è presente, eseguire il comando seguente per caricare immediatamente il modulo nel kernel, senza riavvio:
/sbin/modprobe ip_tablesEseguire nuovamente 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. Questa operazione può richiedere di ricaricare il 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 caricare ip_tables all'avvio
Nel contesto di sudo, esegui il comando seguente sul server Linux per creare un file di configurazione che carichi 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 la presenza del modulo tun sul server, eseguire: lsmod |grep tun
Se tun non è presente, eseguire il seguente comando per caricare immediatamente il modulo nel kernel, senza riavvio:
/sbin/modprobe tunEseguire nuovamente 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 di ricaricare il modulo al termine dell'aggiornamento. Al termine dell'aggiornamento del server, esamina 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.
Configura Linux per caricare tun all'avvio
Nel contesto di sudo, esegui il seguente comando sul tuo server Linux per creare un file di configurazione che carichi tun nel kernel durante l'avvio:echo tun > /etc/modules-load.d/mstunnel_tun.conf