Pré-requisitos para o Microsoft Tunnel no Intune

Antes de poder instalar o gateway de VPN do Microsoft Tunnel para o Microsoft Intune, reveja 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. Planeie também a configuração da sua rede, firewalls e proxies para suportar comunicações para o Túnel da Microsoft.

A um nível elevado, o Túnel Microsoft requer:

• Uma assinatura do Azure.

• Uma subscrição do Microsoft Intune Plano 1 .

• Um servidor Linux que executa contêineres. O servidor pode estar no local ou na cloud e suporta um dos seguintes tipos de contentor:

  • Podman para Red Hat Enterprise Linux (RHEL). Veja 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 execute a ferramenta de preparação para ajudar a validar que o seu ambiente está bem configurado para uma instalação com êxito.

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 Acesso Seguro Global (GSA) não podem ser utilizados em simultâneo no mesmo dispositivo.

Servidor Linux

Configure uma máquina virtual baseada em Linux ou um servidor físico no qual instalar o Gateway de Túnel da Microsoft.

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 também o SO atualizado com as atualizações de segurança.

• 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. O CentOS 8+ não é suportado
  Red Hat (RHEL) 7.4+	Docker CE	O suporte termina em junho de 2024
  Red Hat (RHEL) 8.6	O suporte termina em junho de 2024 Podman 4.0 (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.0. Se atualizar e alterar contentores da v3 para a v4.0, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 8.7	Podman 4.2 (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, 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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, 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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 8.10	Podman 4.9.4-rhel (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.0	O suporte termina em junho de 2024 Podman 4.4.1 (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel. O suporte termina em fevereiro de 2024.
  Red Hat (RHEL) 9.1	Podman 4.4.1 (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.2	Podman 4.4.1 (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.3	Podman 4.6.1. (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Red Hat (RHEL) 9.4	Podman 4.9.4-rhel (predefiniçã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 contentores criados pelo Podman v3 e anterior não são utilizáveis com o Podman v4.2 e posterior. Se atualizar e alterar contentores, planeie criar novos contentores e desinstalar e, em seguida, reinstalar o Microsoft Tunnel.
  Ubuntu 20.04	Docker CE
  Ubuntu 22.04	Docker CE

  Importante

  Em abril de 2023, o Ubuntu terminará o suporte para o Ubuntu 18.04. Com o fim do suporte do Ubuntu, o Intune também terminará o suporte para o Ubuntu 18.04 para utilização 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: consoante a versão do Linux que utiliza para o servidor de Túnel, instale um dos seguintes no servidor:

  • Docker versão 19.03 CE ou posterior.
  • Podman versão 3.0 ou 4.0 consoante a 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 Docker Engine no CentOS ou 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 Motor do Docker no Ubuntu.

  • Instale o Podman no Red Hat Enterprise Linux 8.4 e posterior (desloque-se para baixo 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 suporta a utilização de um contentor podman sem raiz.

    A utilização do Podman sem raiz requer pré-requisitos adicionais para os descritos neste artigo e a utilização de uma linha de comandos modificada quando inicia o script de instalação do Túnel. Para obter informações sobre os pré-requisitos adicionais e a linha de comandos de instalação, veja Utilizar um contentor podman sem raiz no artigo Configurar o Túnel Microsoft para o 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, adiciona ao servidor o certificado TLS e a cadeia de certificados fidedigna completa.

  • 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 superior a dois anos, não será aceite em dispositivos iOS.

  • O suporte de carateres universais é limitado. Por exemplo, *.contoso.com é suportado, mas a .com não é suportada.

  • 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 utilizar um certificado TLS que não seja publicamente fidedigno, tem de emitir toda a cadeia de fidedignidade para dispositivos com um perfil de certificado Fidedigno do Intune.

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

  • Para suportar a verificação do estado de funcionamento da revogação do certificado TLS , certifique-se de que o endereço do Protocolo OCSP (Online Certificate Status Protocol) ou da lista de revogação de certificados (CRL), conforme definido pelo certificado TLS, está acessível a partir do 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 ligação pode reverter para utilizar 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 bridge de contentores entra em conflito com uma rede empresarial, o Gateway de Túnel não consegue encaminhar com êxito o tráfego para essa rede empresarial.

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 a entrada "bip": estiver presente com um endereço IP, modifique-o ao adicionar um novo endereço IP na notação CIDR.
   • Quando a entrada "bip": não estiver presente, tem de adicionar o valor "bip": e o novo endereço IP na notação CIDR.

   O exemplo seguinte mostra a estrutura de um ficheiro daemon.json com uma entrada "bip" atualizada que utiliza um endereço IP modificado de "192.168.128.1/24".

   Exemplo de daemon.json:

   {
   "bip": "192.168.128.1/24"
   }
   

4. Se o ficheiro /etc/docker/daemon.json não estiver presente no servidor, execute um comando semelhante ao seguinte exemplo para criar o ficheiro e definir o IP de bridge que pretende utilizar.

   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. Ao utilizar permissões de raiz e um editor de ficheiros como vi ou nano, modifique /etc/cni/net.d como 87-podman-bridge.conflist para atualizar as predefinições de "sub-rede:" e "gateway:" ao substituir os valores predefinidos do Podman pelos endereços de sub-rede e gateway pretendidos. 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 desativa o reencaminhamento. 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árias NICs por servidor(Opcional): recomendamos a utilização de dois controladores de Interface de Rede (NICs) por servidor Linux para melhorar o desempenho, embora a utilização 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 optar por adicionar um balanceador de carga, consulte a documentação dos fornecedores para obter detalhes de 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 de túnel responde a pedidos GET com uma página estática. A resposta é utilizada como uma sonda por balanceadores de carga como forma de verificar a disponibilidade do servidor de Túnel. A resposta é estática e não contém informações confidenciais.

• VPN por aplicação e Suporte de domínio de nível superior – a utilização por aplicação-VPN com utilização interna de domínios de nível superior local não é suportada pelo 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
  • Outros URLs de ponto final de armazenamento: *.blob.storage.azure.net

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

• Configure regras de firewall para suportar as configurações detalhadas na Configuração de Regras de Firewall do Cliente do Registo de Artefactos da Microsoft (MAR).

Proxy

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

Observação

As configurações do servidor proxy não são suportadas com versões do Android anteriores à versão 10. Para obter mais informações, veja VpnService.Builder na documentação do programador Android.

Observação

Certifique-se de que as suas aplicações LOB android suportam o proxy direto ou a Configuração Automática de Proxy (PAC) para MDM e MAM.

Observação

Problema Conhecido: os utilizadores que estão a tentar iniciar sessão no Edge com as respetivas contas pessoais ou empresariais podem enfrentar problemas quando uma Configuração Automática (PAC) do Proxy está configurada. Neste cenário, o processo de início de sessão pode falhar, impedindo o utilizador de aceder aos recursos internos.

Soluções: para resolver este problema, o Microsoft Tunnel oferece túnel dividido como opção. O túnel dividido permite que os utilizadores incluam apenas as rotas que requerem um proxy, excluindo os servidores de início de sessão e os caminhos de autenticação do encaminhamento através do Túnel. Esta solução garante que o processo de início de sessão não é afetado pela configuração do PAC, permitindo ao utilizador aceder aos recursos internos e navegar na Internet.

O proxy direto também é uma opção sem dividir o túnel para que o início de sessão funcione no Edge com contas empresariais. Isto envolve configurar o Microsoft Tunnel para utilizar um proxy direto em vez de um URL de PAC.

Se não for necessário iniciar sessão de utilizador no Edge, o PAC é suportado para navegação normal e acesso a recursos internos.

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 consegue efetuar a interrupção e inspecionar porque o servidor Linux utiliza a autenticação mútua TLS ao ligar ao 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 suporta o proxy de aplicações do Microsoft Entra nem soluções de proxy semelhantes.

Configurar um proxy de saída para o Podman

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

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

• O proxy não consegue efetuar a interrupção e inspecionar porque o servidor Linux utiliza a autenticação mútua TLS ao ligar ao 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 adiciona essas duas linhas a http_proxy.sh antes de instalar o Gateway de Túnel da Microsoft ao executar o mstunnel-setup, o script configura automaticamente as variáveis de ambiente do proxy do Gateway de Túnel em /etc/mstunnel/env.sh.

  Para configurar um proxy após a conclusão da configuração do Gateway de Túnel da Microsoft, efetue 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. Tal como nas linhas anteriores, substitua o valor address:port de exemplo de 10.10.10.1:3128 pelos valores do endereço IP do 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 ver 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 numa porta SELinux para http_port_t como no exemplo anterior, tem de efetuar configurações adicionais.

    Se a porta de proxy não estiver listada parahttp_port_t, verifique se a porta de proxy é utilizada por outro serviço. Utilize o comando semanage para verificar primeiro a porta que o proxy utiliza e, mais tarde, 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 utilizar o proxy para transferir atualizações de imagens

Pode configurar o Podman para utilizar o proxy para transferir (solicitar) imagens atualizadas para o Podman:

1. No servidor de túnel, utilize uma linha de comandos para executar o seguinte comando para abrir um editor para o ficheiro de substituição do serviço Microsoft Tunnel:

   systemctl edit --force mstunnel_monitor

2. Adicione as quatro linhas seguintes ao ficheiro. Substitua cada instância de [endereço] pelo seu DN ou endereço proxy e, em seguida, guarde o ficheiro:

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

3. Em seguida, execute o seguinte na linha de comandos:

   systemctl restart mstunnel_monitor

4. Por fim, execute o seguinte na linha de comandos para confirmar que a configuração foi bem-sucedida:

   systemctl show mstunnel_monitor | grep http_proxy

   Se a configuração for bem-sucedida, os resultados assemelham-se à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 este processo, é-lhe pedido para verificar o conteúdo de /etc/mstunnel/env.sh e para se certificar de que 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 suportam as seguintes funcionalidades:

• Autenticação do Microsoft Entra no Túnel com o nome de utilizador e a palavra-passe.
• 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 predefinição, os Administradores do Intune e os administradores do Microsoft Entra têm estas 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 do Microsoft Entra que utiliza para instalar o Microsoft Tunnel tem as funções necessárias para concluir a inscrição.

• 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 predefiniçã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.

   • Inicie sessão no Centro de administração do> Microsoft IntuneAdministração> de inquilinosMicrosoft Tunnel Gateway, selecione o separador Servidores, selecione Criar para abrir o painel Criar um servidor e, em seguida, selecione Transferir 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 planeia instalar, o que permite que os administradores de rede utilizem o script para resolver problemas de rede de forma independente.

2. Para validar a configuração da rede e do Linux, execute o script com os seguintes comandos. Estes comandos definem as permissões de execução do script, validam se o Túnel pode ligar-se aos pontos finais corretos e, em seguida, verificam a presença de utilitários que o Túnel utiliza:

   • sudo chmod +x ./mst-readiness

   • sudo ./mst-readiness network - Este comando executa as seguintes ações e, em seguida, reporta ê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 estão disponíveis utilitários utilizados pelo Túnel, como o Docker ou o Podman e ip_tables.

3. Para validar que a conta que irá utilizar para instalar o Microsoft Tunnel tem as funções e permissões necessárias para concluir a inscrição, execute o script com a seguinte linha de comandos: ./mst-readiness account

   O script pede-lhe para utilizar um computador diferente com um browser, que utiliza para autenticar no Microsoft Entra ID e no Intune. A ferramenta comunica o êxito ou um 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 predefiniçã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 para na verificação do módulo ip_tables. 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 no servidor Linux para criar um ficheiro de configuração que carrega o ip_tables para o kernel durante o tempo de arranque: echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf

Carregar manualmente o módulo do tun

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

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

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

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

Importante

Ao atualizar o Servidor de túnel, um módulo do tun carregado manualmente poderá não persistir. Isto pode exigir que recarregue o módulo após a conclusão da atualização. Após a conclusão da atualização do servidor, reveja o servidor para obter a presença do módulo do tun .

Se não estiver presente, utilize os passos anteriores para recarregar o módulo, com o passo adicional para reiniciar o servidor após o carregamento do módulo.

Configurar o Linux para carregar o tun no arranque

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

Próximas etapas

Configurar o Microsoft Tunnel