Pré-requisitos para o Microsoft Tunnel no Intune

Antes de instalar o gateway de VPN do Microsoft Tunnel para Microsoft Intune, examine e configure os pré-requisitos. Os pré-requisitos incluem o uso de um servidor Linux que executa os contêineres para hospedar o software do servidor do Tunnel. Planeje também configurar sua rede, firewalls e proxies para dar suporte a comunicações para o Microsoft Tunnel.

Em alto nível, o Microsoft Tunnel requer:

• Uma assinatura do Azure.

• Uma assinatura Microsoft Intune Plano 1.

• Um servidor Linux que executa contêineres. O servidor pode ser local ou na nuvem e dá suporte a um dos seguintes tipos de contêiner:

  • Podman para RHEL (Red Hat Enterprise Linux). Consulte os requisitos do servidor Linux .
  • Docker para todas as outras distribuições do Linux.

• Um certificado TLS para o servidor Linux, para proteger as conexões de dispositivos com o servidor de Gateway do Tunnel.

• Dispositivos que executam Android ou iOS/iPadOS.

Depois de configurar os pré-requisitos, recomendamos que você execute a ferramenta de preparação para ajudar a validar se seu ambiente está bem configurado para uma instalação bem-sucedida.

As seções a seguir detalham os pré-requisitos para o Microsoft Tunnel e fornecem orientações sobre o uso da ferramenta de preparação.

Observação

O Túnel e o GSA (Acesso Seguro Global) não podem ser usados simultaneamente no mesmo dispositivo.

Servidor Linux

Configure uma máquina virtual baseada em Linux ou um servidor físico no qual instalar o Gateway do Microsoft Tunnel.

Observação

Há suporte apenas para os sistemas operacionais e versões de contêiner listados na tabela a seguir. Não há suporte para as versões não listadas. Apenas depois que os testes e a capacidade de suporte forem verificados, as versões mais recentes serão adicionadas a essa lista. Mantenha o sistema operacional atualizado com atualizações de segurança também.

• Distribuições Linux com suporte - A tabela a seguir detalha quais versões do Linux têm suporte para o servidor Tunnel e o contêiner necessário:

  Versão de distribuição	Requisitos de contêiner	Considerações
  CentOS 7.4+	Docker CE	O suporte termina em junho de 2024. Não há suporte para o CentOS 8+
  Red Hat (RHEL) 7.4+	Docker CE	O suporte termina em junho de 2024
  Red Hat (RHEL) 8.6	Podman 4.0 (padrão) Podman 3.0	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.0. Se atualizar e alterar contêineres de v3 para v4.0, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 8.7	Podman 4.2 (padrão)	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 8.8	Podman 4.4.1	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 8.9	Podman 4.4.1	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.0	Podman 4.4.1 (padrão)	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel. O suporte termina em fevereiro de 2024.
  Red Hat (RHEL) 9.1	Podman 4.4.1 (padrão)	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.2	Podman 4.4.1 (padrão)	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.3	Podman 4.6.1. (padrão)	Esta versão do RHEL não carrega automaticamente o módulo ip_tables no kernel do Linux. Ao usar essa versão, planeje manuamente carregar o ip_tables antes que o Tunnel seja instalado. Os contêineres criados pelo Podman v3 e anteriores não podem ser utilizáveis com o Podman v4.2 e posteriores. Se atualizar e alterar contêineres, planeje criar novos contêineres e desinstalar e reinstalar o Microsoft Tunnel.
  Ubuntu 20.04	Docker CE
  Ubuntu 22.04	Docker CE

  Importante

  Em abril de 2023, o Ubuntu encerrará o suporte ao Ubuntu 18.04. Com o fim do suporte do Ubuntu, Intune também encerrará o suporte ao Ubuntu 18.04 para uso com o Microsoft Tunnel. Para obter mais informações, confira https://wiki.ubuntu.com/Releases.

• Tamanho do servidor Linux: use as seguintes diretrizes para atender ao uso esperado:

  Nº de dispositivos	Nº de CPUs	Memória (GB)	Nº de servidores	Nº de Sites	Espaço em 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

  O suporte é dimensionado linearmente. Embora cada Microsoft Tunnel seja compatível com até 64.000 conexões simultâneas, os dispositivos individuais podem abrir várias conexões.

• CPU: processador AMD/Intel de 64 bits.

• Instalar o Docker CE ou o Podman: dependendo da versão do Linux que você usa para o servidor tunnel, instale um dos seguintes no servidor:

  • Docker versão 19.03 CE ou posterior.
  • Podman versão 3.0 ou 4.0 dependendo da versão do RHEL.

  O Microsoft Tunnel requer Docker ou Podman no servidor Linux para fornecer suporte a containers. Os contêineres fornecem um ambiente de execução consistente, monitoramento de integridade e correção proativa e uma experiência de atualização limpa.

  Para obter mais informações sobre como instalar e configurar o Docker ou Podman, confira:

  • Instale o Mecanismo do Docker no CentOS ou no Red Hat Enterprise Linux 7.

    Observação

    O link anterior direciona você para as instruções de download e instalação do CentOS. Use essas mesmas instruções para RHEL 7.4. A versão instalada no RHEL 7.4 por padrão é muito antiga para dar suporte ao Microsoft Tunnel Gateway.

  • Instale o Docker Engine no Ubuntu.

  • Instale o Podman no Red Hat Enterprise Linux 8.4 e posterior (role até RHEL8).

    Essas versões do RHEL não dão suporte ao Docker. Em vez disso, essas versões usam Podman e podman faz parte de um módulo chamado "container-tools". Nesse contexto, um módulo é um conjunto de pacotes RPM que representam um componente e geralmente são instalados juntos. Um módulo típico contém pacotes com um aplicativo, pacotes com bibliotecas de dependência específicas do aplicativo, pacotes com documentação do aplicativo e pacotes com utilitários auxiliares. Para obter mais informações, consulte Introdução aos módulos na documentação da Red Hat.

    Observação

    Podman sem raiz: o Microsoft Tunnel dá suporte ao uso de um contêiner podman sem raiz.

    O uso do Podman sem raiz requer pré-requisitos adicionais para aqueles detalhados neste artigo e o uso de uma linha de comando modificada quando você inicia o script de instalação do Túnel. Para obter informações sobre os pré-requisitos adicionais e a linha de comando de instalação, consulte Usar um contêiner podman sem raiz no artigo Configurar o Microsoft Tunnel para Intune.

• Certificado TLS (Transport Layer Security): O servidor Linux requer um certificado TLS confiável para proteger a conexão entre os dispositivos e o servidor de Gateway de Túnel. Durante a instalação do Gateway de Túnel, você adiciona ao servidor o certificado TLS e a cadeia de certificados confiáveis completos.

  • O SAN (nome alternativo da entidade) do certificado TLS que você usa para proteger o ponto de extremidade do Gateway de Tunnel deve corresponder ao endereço IP ou ao FQDN do servidor de Gateway de Tunnel.

  • O certificado TLS não pode ter uma data de validade superior a dois anos. Se a data for maior que dois anos, ela não será aceita em dispositivos iOS.

  • O suporte de curingas é limitado. Por exemplo, há suporte para *.contoso.com , mas não há suporte para .com cont* .

  • Durante a instalação do servidor de Gateway de Túnel, você deverá copiar toda a cadeia de certificados confiáveis para o servidor Linux. O script de instalação fornece o local em que você copia os arquivos de certificado e solicita que você faça isso.

  • Se você usar um certificado TLS não confiável publicamente, deverá enviar toda a cadeia de confiança para dispositivos usando um Intune perfil de certificado confiável.

  • O certificado TLS pode estar em formato PEM ou pfx.

  • Para dar suporte ao marcar de integridade de revogação de certificado TLS, verifique se o endereço OCSP (Protocolo de Status do Certificado Online) ou o endereço CRL (lista de revogação de certificado), conforme definido pelo certificado TLS, está acessível no servidor.

• Versão do TLS: Por padrão, as conexões entre os clientes do Microsoft Tunnel e os servidores usam o TLS 1.3. Quando o TLS 1.3 não está disponível, a conexão pode voltar a usar o TLS 1.2.

Rede de ponte padrão

Os contêineres Podman e Docker usam uma rede de ponte para encaminhar o tráfego por meio do host Linux. Quando a rede de ponte de contêineres entra em conflito com uma rede corporativa, o Gateway de Túnel não pode rotear com êxito o tráfego para essa rede corporativa.

As redes de ponte padrão são:

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

Para evitar conflitos, você pode reconfigurar o Podman e o Docker para usar uma rede de ponte que você especificar.

Importante

O servidor Tunnel Gateway deve ser instalado antes da alteração da configuração de rede de ponte.

Alterar a rede de ponte padrão usada pelo Docker

O Docker usa o arquivo /etc/docker/daemon.json para configurar um novo endereço IP de ponte padrão. No arquivo, o endereço IP de ponte deve ser especificado na notação CIDR (Roteamento entre domínios sem classificação), uma forma compacta de representar um endereço IP junto com sua máscara de sub-rede e prefixo de roteamento associados.

Importante

O endereço IP usado nas etapas a seguir é um exemplo. Certifique-se de que o endereço IP que usado não está em conflito com sua rede corporativa.

1. Use o seguinte comando para parar o contêiner do MS Tunnel Gateway: sudo mst-cli server stop ; sudo mst-cli agent stop

2. Em seguida, execute o seguinte comando para remover o dispositivo de ponte do Docker existente: sudo ip link del docker0

3. Se o arquivo /etc/docker/daemon.json estiver presente no servidor, use um editor de arquivos como o vi ou nano para modificar o arquivo. Execute o editor de arquivos com permissões raiz ou sudo:

   • Quando o "bip": a entrada estiver presente com um endereço IP, modifique-o adicionando um novo endereço IP na notação CIDR.
   • Quando a entrada "bip": não estiver presente, você deve adicionar o valor "bip": e o novo endereço IP na notação CIDR.

   O exemplo a seguir mostra a estrutura de um arquivo daemon.json com um "bip" atualizado: entrada que usa um endereço IP modificado de "192.168.128.1/24".

   Exemplo de daemon.json:

   {
   "bip": "192.168.128.1/24"
   }
   

4. Se o arquivo /etc/docker/daemon.json não estiver presente no servidor, execute um comando semelhante ao exemplo a seguir para criar o arquivo e definir o IP de ponte que você deseja usar.

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

5. Use o seguinte comando para iniciar o contêiner do MS Tunnel Gateway: sudo mst-cli agent start ; sudo mst-cli server start

Para obter mais informações, confira Usar redes de ponte na documentação do Docker.

Alterar a rede de ponte padrão usada pelo Podman

O Podman usa o arquivo /etc/cni/net.d como 87-podman-bridge.conflist para configurar um novo endereço IP de ponte padrão.

1. Use o seguinte comando para parar o contêiner do MS Tunnel Gateway: sudo mst-cli server stop ; sudo mst-cli agent stop

2. Em seguida, execute o seguinte comando para remover o dispositivo de ponte Podman existente: sudo ip link del cni-podman0

3. Usando permissões raiz e um editor de arquivos como vi ou nano, modifique /etc/cni/net.d como 87-podman-bridge.conflist para atualizar os padrões de "sub-rede:" e "gateway:" substituindo os valores padrão do Podman por sua sub-rede e endereços de gateway desejados. O endereço de sub-rede deve ser especificado na notação CIDR.

   Os padrões do Podman são:

   • sub-rede.10.88.0.0/16
   • gateway: 10.88.0.1

4. Use o seguinte comando para reiniciar os contêineres do MS Tunnel Gateway: sudo mst-cli agent start ; sudo mst-cli server start

Para obter mais informações, confira Configurando a rede de contêineres com o Podman na documentação do Red Hat.

Rede

• Habilite o encaminhamento de pacotes para ipv4: cada servidor Linux que hospeda o software de servidor de túnel deve ter o encaminhamento de IP para IPv4 habilitado. Para verificar o status do encaminhamento de IP, no servidor, execute um dos seguintes comandos genéricos como root ou sudo. Os dois comandos retornam um valor de 0 para desabilitado e um valor de 1 para habilitado:

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

  Se não estiver habilitado, você poderá habilitar temporariamente o encaminhamento de IP executando um dos seguintes comandos genéricos como root ou sudo no servidor. Esses comandos podem alterar a configuração de encaminhamento de IP até que o servidor seja reiniciado. Após uma reinicialização, o servidor retorna o comportamento de encaminhamento de IP para seu estado anterior. Para ambos os comandos, use um valor de 1 para habilitar o encaminhamento. Um valor de 0 desabilita o encaminhamento. Os seguintes exemplos de comando usam um valor de 1 para habilitar o encaminhamento:

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

  Para tornar o encaminhamento de IP permanente, em cada servidor Linux, edite o arquivo /etc/sysctl.conf e remova a hashtag principal (#) de #net.ipv4.ip_forward=1 para habilitar o encaminhamento de pacotes. Após a edição, a entrada deverá ser exibida da seguinte maneira:

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

  Para que essa alteração tenha efeito, é necessário reinicializar o servidor ou executar sysctl -p.

  Se a entrada esperada não estiver presente no arquivo sysctl.conf, confira a documentação da distribuição usada para saber como habilitar o encaminhamento de IP. Geralmente, você pode editar sysctl.conf para adicionar a linha ausente no final do arquivo e habilitar permanentemente o encaminhamento de IP.

• Configurar vários NICs por servidor(Opcional): recomendamos usar dois NICs (controladores de Interface de Rede) por servidor Linux para melhorar o desempenho, embora o uso de dois seja opcional.

  • NIC 1 – Esse NIC lida com o tráfego dos dispositivos gerenciados e deve estar em uma rede pública, com endereço IP público.  Esse endereço IP é o endereço que você configura na Configuração do Site. Esse endereço pode representar um único servidor ou um balanceador de carga.

  • NIC 2 – Esse NIC lida com o tráfego para recursos locais e deve estar na rede interna privada sem segmentação de rede.

• Certifique-se de que as VMs Linux baseadas em nuvem podem acessar sua rede local: se você executar o Linux como uma VM em uma nuvem, certifique-se de que o servidor pode acessar sua rede local. Por exemplo, para uma VM no Azure, você poderá usar o Azure ExpressRoute ou algo semelhante para fornecer acesso. O Azure ExpressRoute não é necessário quando você executa o servidor em uma VM local.

• Balanceadores de carga(opcional): se você optar por adicionar um balanceador de carga, consulte a documentação dos fornecedores para obter detalhes da configuração. Leve em consideração o tráfego de rede e as portas de firewall específicas para o Intune e para o Microsoft Tunnel.

  O servidor tunnel responde às solicitações GET com uma página estática. A resposta é usada como uma investigação por balanceadores de carga como uma forma de marcar para a vida útil do servidor tunnel. A resposta é estática e não contém informações confidenciais.

• Vpn por aplicativo e suporte de domínio de nível superior – O uso por aplicativo-VPN com o uso interno de domínios de nível superior local não é compatível com o Microsoft Tunnel.

Firewall

Por padrão, o Microsoft Tunnel e o servidor usam as seguintes portas:

Portas de entrada:

• TCP 443 – Exigida pelo Microsoft Tunnel.
• UDP 443 – Exigida pelo Microsoft Tunnel.
• TCP 22 – Opcional. Usada para SSH/SCP pelo servidor Linux.

Portas de saída:

• TCP 443 – Exigida para acessar os serviços do Intune. Exigido pelo Docker ou Podman para efetuar pull de imagens.

Ao criar a configuração de Servidor para o túnel, você pode especificar uma porta diferente da padrão (443). Se você especificar uma porta diferente, lembre-se de configurar os firewalls para darem suporte à sua configuração.

Mais requisitos:

• Para acessar o serviço de token de segurança e o armazenamento do Azure para logs, forneça acesso aos seguintes FQDNs:

  • Serviço de Token de Segurança: *.sts.windows.net
  • Armazenamento do Azure para logs de túnel: *.blob.core.windows.net
  • Outras urls de ponto de extremidade de armazenamento: *.blob.storage.azure.net

• O Túnel compartilha os mesmos requisitos que os pontos de extremidade de rede para Microsoft Intune, com a adição da porta TCP 22 e graph.microsoft.com.

• Configure regras de firewall para dar suporte às configurações detalhadas na Configuração de Regras de Firewall do Cliente de Registro de Artefato da Microsoft (MAR).

Proxy

Você pode usar um servidor proxy com o Microsoft Tunnel.

Observação

Não há suporte para configurações de servidor proxy com versões do Android antes da versão 10. Para obter mais informações, consulte VpnService.Builder nessa documentação do desenvolvedor do Android.

Observação

Verifique se seus aplicativos LOB Android dão suporte a proxy direto ou PAC (Configuração Automática de Proxy) para MDM e MAM.

Observação

Problema conhecido: os usuários que estão tentando entrar no Edge usando suas contas pessoais ou corporativas podem enfrentar problemas quando um PAC (Configuração Automática de Proxy) é configurado. Nesse cenário, o processo de entrada pode falhar, impedindo que o usuário acesse recursos internos.

Soluções alternativas: para resolve esse problema, o Microsoft Tunnel oferece o túnel dividido como uma opção. O túnel dividido permite que os usuários incluam apenas as rotas que exigem um proxy, excluindo servidores de logon e caminhos de autenticação do roteamento pelo Túnel. Essa solução alternativa garante que o processo de entrada não seja afetado pela configuração do PAC, permitindo que o usuário acesse recursos internos e navegue pela Internet.

O proxy direto também é uma opção sem túnel dividido para que a entrada funcione no Edge usando contas corporativas. Isso envolve configurar o Microsoft Tunnel para usar um proxy direto em vez de uma URL PAC.

Se nenhum usuário entrar necessário no Edge, o PAC terá suporte para navegar e acessar recursos internos normais.

As seguintes considerações podem ajudar você a configurar o servidor Linux e o ambiente para o sucesso:

Configurar um proxy de saída para o Docker

• Se você usar um proxy interno, talvez seja necessário configurar o host do Linux para usar o servidor proxy adotando variáveis de ambiente. Para usar as variáveis, edite o arquivo /etc/environment no servidor Linux e adicione as seguintes linhas:

  http_proxy=[address]
https_proxy=[address]

• Proxies autenticados não são compatíveis.

• O proxy não pode executar interrupções e inspeções porque o servidor Linux usa a autenticação mútua TLS ao se conectar a Intune.

• Configure o Docker para usar o proxy para efetuar pull de imagens. Para fazer isso, edite o arquivo /etc/systemd/system/docker.service.d/http-proxy.conf no servidor Linux e adicione as seguintes linhas:

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

  Observação

  O Microsoft Tunnel não dá suporte a Microsoft Entra proxy de aplicativo ou soluções de proxy semelhantes.

Configurar um proxy de saída para o Podman

Os detalhes a seguir podem ajudá-lo a configurar um proxy interno ao usar o Podman:

• Proxies autenticados não são compatíveis.

• O proxy não pode executar interrupções e inspeções porque o servidor Linux usa a autenticação mútua TLS ao se conectar a Intune.

• O Podman lê informações de Proxy HTTP armazenadas em /etc/profile.d/http_proxy.sh. Se esse arquivo não existir no servidor, crie-o. Edite http_proxy.sh para adicionar as duas linhas a seguir. Nas linhas a seguir, 10.10.10.1:3128 é um exemplo de endereço:entrada de porta. Ao adicionar essas linhas, substitua 10.10.10.1:3128 com os valores para seu IP proxy address:port:

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

  Se você tiver acesso ao Portal do Cliente do Red Hat, poderá exibir o artigo da base de dados de conhecimento associado a essa solução. Consulte configuração de variáveis de Proxy HTTP para Podman – Portal do Cliente do Red Hat.

• Quando você adiciona essas duas linhas ao http_proxy.sh antes de instalar o Microsoft Tunnel Gateway executando a instalação do mstunnel, o script configura automaticamente as variáveis de ambiente proxy do Tunnel Gateway em /etc/mstunnel/env.sh.

  Para configurar um proxy após a conclusão da instalação do Microsoft Tunnel Gateway, execute as seguintes ações:

  1. Modifique ou crie o arquivo /etc/profile.d/http_proxy.sh e adicione as duas linhas do ponto de marcador anterior.

  2. Edite /etc/mstunnel/env.sh e adicione as duas linhas a seguir ao final do arquivo. Assim como as linhas anteriores, substitua o valor de endereço:porta de exemplo de 10.10.10.1:3128 pelos valores do endereço IP proxy :porta:

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

  3. Reinicie o servidor gateway de túnel: Execute mst-cli server restart

  Lembre-se de que o RHEL usa SELinux. Como um proxy que não é executado em uma porta SELinux para http_port_t pode exigir configuração adicional, verifique o uso de portas gerenciadas SELinux para http. Para exibir as configurações, execute o seguinte comando: sudo semanage port -l | grep "http_port_t"

  Exemplo dos resultados do comando de verificação de porta. Neste exemplo, o proxy usa 3128 e não está listado:

  

  • Se o proxy for executado em uma das portas SELinux para http_port_t, você poderá continuar com o processo de instalação do Gateway do Microsoft Tunnel.

  • Se o proxy não for executado em uma porta SELinux para http_port_t como no exemplo anterior, você deverá fazer configurações extras.

    Se sua porta proxy não estiver listada parahttp_port_t, marcar se a porta proxy for usada por outro serviço. Use o comando semanage para primeiro marcar a porta que seu proxy usa e, em seguida, posteriormente, se necessário, para alterá-la. Para verificar a porta usada pelo proxy, execute: sudo semanage port -l | grep "your proxy port"

    Exemplo dos resultados da verificação de um serviço que pode usar a porta:

    

    • No exemplo, a porta esperada (3128) é usada por squid, que é um serviço de proxy OSS. As políticas SELinux de proxy são parte de muitas distribuições comuns. Como squid usa a porta 3128 (nossa porta de exemplo), devemos modificar as portas http_port_t e adicionar a porta 3128 para ser permitida via SELinux para o proxy usado pelo Tunnel. Para modificar o uso da porta, execute o seguinte comando: sudo semanage port -m -t http_port_t -p tcp "your proxy port"

      Exemplo do comando para modificar a porta:

      

      Depois de executar o comando para alterar a porta, execute o seguinte comando para verificar se a porta é usada por outro serviço: sudo semanage port -l | grep "your proxy port"

      Exemplo do comando para verificar a porta depois de modificar a porta:

      

      Neste exemplo, a porta 3128 agora está associada a http_port-t e squid_port_t. Esse resultado é esperado. Se a porta proxy não estiver listada ao executar o comando sudo semanage -l | grep "your_proxy_port" e, em seguida, executar o comando para modificar a porta novamente, mas o -m no comandosemanage com -a: sudo semanage port -a -t http_port_t -p tcp "your proxy port"

Configurar o Podman para usar o proxy para baixar atualizações de imagem

Você pode configurar o Podman para usar o proxy para baixar (pull) imagens atualizadas para Podman:

1. No servidor de túnel, use um prompt de comando para executar o seguinte comando para abrir um editor para o arquivo de substituição do serviço microsoft tunnel:

   systemctl edit --force mstunnel_monitor

2. Adicione as quatro linhas a seguir ao arquivo. Substitua cada instância de [endereço] pelo DN ou endereço do proxy e salve o arquivo:

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

3. Em seguida, execute o seguinte no prompt de comando:

   systemctl restart mstunnel_monitor

4. Por fim, execute o seguinte no prompt de comando para confirmar se a configuração foi bem-sucedida:

   systemctl show mstunnel_monitor | grep http_proxy

   Se a configuração for bem-sucedida, os resultados se assemelham às seguintes informações:

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

Atualizar o servidor proxy em uso pelo servidor de túnel

Para alterar a configuração do servidor proxy que está em uso pelo host Linux do servidor do túnel, use o seguinte procedimento:

1. No servidor de túnel, edite /etc/mstunnel/env.sh e especifique o novo servidor proxy.

2. Execute mst-cli install.

   Esse comando recria os contêineres com os novos detalhes do servidor proxy. Durante esse processo, você deve verificar o conteúdo de /etc/mstunnel/env.sh e verificar se o certificado está instalado. O certificado já deve estar presente na configuração anterior do servidor proxy.

   Para confirmar e concluir a configuração, insira sim.

Plataformas

Os dispositivos devem ser inscritos no Intune para terem suporte do Microsoft Tunnel. Apenas as seguintes plataformas de dispositivos são compatíveis:

• iOS/iPadOS

• Android Enterprise:

  • Totalmente gerenciado
  • Perfil de Trabalho de Propriedade Corporativa
  • Perfil de Trabalho de Propriedade Pessoal

  Observação

  Os dispositivos Android Enterprise dedicados não possuem suporte do Microsoft Tunnel.

Todas as plataformas dão suporte à seguinte funcionalidade:

• Microsoft Entra autenticação no Túnel usando nome de usuário e senha.
• Autenticação dos Serviços de Federação do Active Directory (AD FS) no Túnel usando nome de usuário e senha.
• Compatibilidade por aplicativo.
• Túnel de dispositivo completo manual por meio de um aplicativo de túnel, no qual o usuário inicia a VPN e seleciona Conectar.
• Túnel dividido. No entanto, no iOS as regras de túnel dividido são ignoradas quando o perfil VPN usa VPN por aplicativo.

A compatibilidade de um proxy é limitada às seguintes plataformas:

• Android 10 e posteriores
• iOS/iPadOS

Permissões

Para gerenciar o Microsoft Tunnel, os usuários precisam ter permissões incluídas no grupo de permissões Gateway do Microsoft Tunnel no Intune. Por padrão, administradores Intune e administradores de Microsoft Entra têm essas permissões. Você também pode adicioná-las a funções personalizadas criadas para o locatário do Intune.

Ao configurar uma função, na página Permissões, expanda Gateway do Microsoft Tunnel e selecione as permissões que deseja conceder.

O grupo de permissões do Gateway do Microsoft Tunnel concede as seguintes permissões:

• Criar – configure Servidores e Sites do Gateway do Microsoft Tunnel. As configurações do servidor incluem configurações de intervalos de endereços IP, servidores DNS, portas e regras de túnel dividido. Os sites são agrupamentos lógicos de vários servidores que dão suporte ao Microsoft Tunnel.

• Atualizar (modificar) – atualize os sites e configurações do servidor de Gateway do Microsoft Tunnel. As configurações do servidor incluem configurações de intervalos de endereços IP, servidores DNS, portas e regras de túnel dividido. Os sites são agrupamentos lógicos de vários servidores que dão suporte ao Microsoft Tunnel.

• Excluir – exclua os sites e configurações do servidor de Gateway do Microsoft Tunnel. As configurações do servidor incluem configurações de intervalos de endereços IP, servidores DNS, portas e regras de túnel dividido. Os sites são agrupamentos lógicos de vários servidores que dão suporte ao Microsoft Tunnel.

• Ler – veja os sites e configurações do servidor de Gateway do Microsoft Tunnel. As configurações do servidor incluem configurações de intervalos de endereços IP, servidores DNS, portas e regras de túnel dividido. Os sites são agrupamentos lógicos de vários servidores que dão suporte ao Microsoft Tunnel.

Executar a ferramenta de preparação

Antes de iniciar a instalação de um servidor, recomendamos que você faça o download e execute a versão mais recente da ferramenta mst-readiness. A ferramenta é um script executado no servidor Linux e realiza as seguintes ações:

• Valida que a conta Microsoft Entra que você usa para instalar o Microsoft Tunnel tem as funções necessárias para concluir o registro.

• Verifique se a configuração de rede permite que o Microsoft Tunnel acesse os pontos de extremidade obrigatórios da Microsoft.

• Verifica a presença do módulo ip_tables no servidor Linux. Essa verificação foi adicionada ao script em 11 de fevereiro de 2022, quando o suporte para RHEL 8.5 foi adicionado. O RHEL 8.5 posterior não carrega o módulo ip_tables por padrão. Se eles estiverem ausentes após a instalação do servidor Linux, você deve carregar o módulo ip_tables manualmente.

Importante

A ferramenta de preparação não valida as portas de entrada, o que é um erro de configuração comum. Após a execução da ferramenta de preparação, examine os pré-requisitos do firewall e valide manualmente a passagem do tráfego de entrada pelos firewalls.

A ferramenta de preparação do MST tem uma dependência do JQ, um processador JSON de linha de comando. Antes de executar a ferramenta de preparação, verifique se o JQ está instalado. Para mais informações sobre como obter e instalar o JQ, confira a documentação da versão do Linux que você usa.

Para usar a ferramenta de preparação:

1. Obtenha a versão mais recente da ferramenta de preparação usando um dos seguintes métodos:

   • Baixe a ferramenta diretamente usando um navegador da Web. Vá para https://aka.ms/microsofttunnelready a fim de baixar um arquivo chamado Preparação do MST.

   • Entre no Microsoft Intune centro de administração do centro> deadministração> do administradorMicrosoft Tunnel Gateway, selecione a guia Servidores, selecione Criar para abrir o painel Criar um servidor e selecione Baixar ferramenta de preparação.

   • Use um comando do Linux para obter a ferramenta de preparação diretamente. Por exemplo, você pode usar wget ou curl para abrir o link https://aka.ms/microsofttunnelready.

     Por exemplo, para usar wget e registrar detalhes em mst-readiness durante o download, execute wget --output-document=mst-readiness https://aka.ms/microsofttunnelready

   O script pode ser executado a partir de qualquer servidor Linux que esteja na mesma rede que o servidor que você planeja instalar, o que permite que os administradores de rede usem o script para solucionar problemas de rede de forma independente.

2. Para validar sua rede e a configuração do Linux, execute o script com os comandos a seguir. Esses comandos definem as permissões de execução para o script, validam que o Túnel pode se conectar aos pontos de extremidade corretos e, em seguida, marcar para a presença de utilitários que o Tunnel usa:

   • sudo chmod +x ./mst-readiness

   • sudo ./mst-readiness network - Este comando executa as seguintes ações e, em seguida, relata êxito ou erro para ambos:

     • Tenta se conectar a cada ponto de extremidade da Microsoft que o túnel usará.
     • Verifica se as portas obrigatórias estão abertas no firewall.

   • sudo ./mst-readiness utils - Este comando valida que utilitários usados pelo Tunnel como Docker ou Podman e ip_tables estão disponíveis.

3. Para validar que a conta que você usará para instalar o Microsoft Tunnel tem as funções e permissões necessárias para concluir o registro, execute o script com a seguinte linha de comando: ./mst-readiness account

   O script solicita que você use um computador diferente com um navegador da Web, que você usa para autenticar para Microsoft Entra ID e para Intune. A ferramenta relata êxito ou erro.

Para obter mais informações sobre essa ferramenta, confira Referência para MST-CLI no artigo de referência do Microsoft Tunnel.

Carregar ip_tables manualmente

Enquanto a maioria das distribuições Linux carregam automaticamente o módulo ip_tables, algumas distribuições podem não carregar. Por exemplo, o RHEL 8.5 não carrega o ip_tables por padrão.

Para verificar a presença deste módulo, execute a versão mais recente da ferramenta mst-readiness no servidor Linux. A verificação de ip_tables foi adicionada ao script de ferramentas de preparação em 11 de fevereiro de 2022.

Se o módulo não estiver presente, a ferramenta será interrompida no módulo ip_tables marcar. Nesse cenário, você pode executar os comandos a seguir para carregar manualmente o módulo.

Carregar o módulo ip_tables manualmente:

No contexto do sudo, execute os seguintes comandos no servidor Linux:

1. Valide a presença de ip_tables no servidor: lsmod |grep ip_tables

2. Se ip_tables não estiver presente, execute o seguinte para carregar o módulo no kernel imediatamente, sem uma reinicialização: /sbin/modprobe ip_tables

3. Realize novamente a validação para confirmar que as tabelas estão agora carregadas: lsmod |grep ip_tables

Importante

Ao atualizar o servidor do Tunnel, um módulo ip_tables carregado manualmente pode não persistir. Isso pode exigir que você recarregue o módulo após a conclusão da atualização. Depois que a atualização do servidor for concluída, examine o servidor para localizar o módulo ip_tables.

Se as tabelas não estiverem presentes, use as etapas anteriores para recarregar o módulo, com a etapa adicional para reiniciar o servidor depois que o módulo for carregado.

Configurar o Linux para carregar ip_tables na inicialização

No contexto do sudo, execute o seguinte comando em seu servidor Linux para criar um arquivo de configuração que carregue o ip_tables no kernel durante o tempo de inicialização: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Carregar manualmente o módulo tun

O Microsoft Tunnel requer o módulo tun , no entanto, algumas distribuições do Linux não carregam o módulo tun por padrão.

Para validar o presente do módulo tun no servidor, execute: lsmod |grep tun

1. Se o tun não estiver presente, execute o seguinte para carregar o módulo no kernel imediatamente, sem uma reinicialização: /sbin/modprobe tun

2. Execute novamente a validação para confirmar que o módulo tun agora está carregado: lsmod |grep tun

Importante

Ao atualizar o servidor tunnel, um módulo tun carregado manualmente pode não persistir. Isso pode exigir que você recarregue o módulo após a conclusão da atualização. Depois que a atualização do servidor for concluída, examine o servidor para obter a presença do módulo tun .

Se não estiver presente, use as etapas anteriores para recarregar o módulo, com a etapa adicional para reiniciar o servidor depois que o módulo for carregado.

Configurar o Linux para carregar o tun na inicialização

No contexto do sudo, execute o seguinte comando em seu servidor Linux para criar um arquivo de configuração que carrega tun no kernel durante o tempo de inicialização: echo tun > /etc/modules-load.d/mstunnel_tun.conf

Próximas etapas

Configurar o Microsoft Tunnel