Partilhar via

Monitora o Microsoft Tunnel

  • Artigo

Após a instalação do Microsoft Tunnel, pode ver a configuração do servidor e o estado de funcionamento do servidor no centro de administração do Microsoft Intune.

Usar a interface do usuário do Centro de Administração

Inicie sessão no centro de administração do Microsoft Intune e aceda a Administração> de inquilinos doMicrosoft Tunnel Gateway>Health status.

Em seguida, selecione um servidor e, em seguida, abra o separador marcar de estado de funcionamento para ver que os servidores status métricas. Por padrão, cada métrica usa valores de limite predefinidos que determinam o status. As métricas a seguir dão suporte à personalização desses limites:

  • Uso da CPU
  • Uso da memória
  • Uso de espaço em disco
  • Latência

Valores padrão para as métricas de integridade do servidor:

  • Último check-in: quando o servidor do Gateway do Tunnel fez o último check-in com o Intune.

    • Íntegro – O último check-in foi nos últimos cinco minutos.
    • Mau estado de funcionamento – o último marcar foi há mais de cinco minutos.

  • Conexões atuais – O número de conexões exclusivas que estavam ativas no último check-in do servidor.

    • Íntegro – Havia 4.990 ou menos conexões
    • Não íntegro – Havia mais de 4.990 conexões ativas

  • Taxa de transferência – Os megabits por segundo de tráfego passando pela NIC do Gateway do Tunnel no último check-in do servidor.

  • Uso da CPU – A média de uso da CPU pelo servidor do Gateway do Tunnel a cada cinco minutos.

    • Íntegro – 95% ou menos
    • Aviso – 96% a 99%
    • Não íntegro – 100% de uso

  • Núcleos de CPU – o número de núcleos de CPU disponíveis neste servidor.

    • Bom estado de funcionamento - 4 ou mais núcleos
    • Aviso - 1, 2 ou 3 núcleos
    • Núcleos -0 em mau estado de funcionamento

  • Uso de memória – A média de uso de memória pelo servidor do Gateway do Tunnel a cada cinco minutos.

    • Íntegro – 95% ou menos
    • Aviso – 96% a 99%
    • Não íntegro – 100% de uso

  • Utilização do espaço em disco – a quantidade de espaço em disco que o servidor do Gateway de Túnel utiliza.

    • Bom Estado de Funcionamento - Acima de 5 GB
    • Aviso - 3-5 GB
    • Mau estado de funcionamento – abaixo dos 3 GB

  • Latência – A quantidade média de tempo necessário para que os pacotes de IP cheguem e, depois, saiam da interface de rede.

    • Íntegro – Menos de 10 milissegundos
    • Aviso – De 10 milissegundos a 20 milissegundos
    • Não íntegro – Mais de 20 milissegundos

  • Certificado do agente de gestão – o certificado do agente de gestão é utilizado pelo Gateway de Túnel para autenticar com Intune, pelo que é importante renová-lo antes de expirar. No entanto, deve renovar-se automaticamente.

    • Bom estado de funcionamento – a expiração do certificado está a mais de 30 dias de distância.
    • Aviso – a expiração do certificado é inferior a 30 dias.
    • Mau estado de funcionamento – o certificado expirou.

  • Certificado TLS – o número de dias até que o certificado TLS (Transport Layer Security) que protege o tráfego entre os clientes e o servidor do Gateway de Túnel expire.

    • Íntegro – Mais de 30 dias
    • Aviso – 30 dias ou menos
    • Não íntegro: o certificado expirou

  • Revogação do certificado TLS – o Gateway de Túnel tenta marcar a status de revogação do certificado TLS (Transport Layer Security) com um endereço OCSP (Online Certificate Status Protocol) ou uma lista de revogação de certificados (CRL), conforme definido pelo certificado TLS. Este marcar requer que o servidor tenha acesso ao ponto final OCSP ou ao endereço CRL, conforme definido no certificado.

    • Bom estado de funcionamento – o certificado TLS não é revogado.
    • Aviso – não é possível marcar se o certificado TLS for revogado. Certifique-se de que os pontos finais definidos no certificado podem ser acedidos a partir do servidor de Túnel.
    • Mau estado de funcionamento – o certificado TLS é revogado.

    Planeie substituir um certificado TLS revogado.

    Para saber mais sobre o Protocolo OCSP (Online Certificate Status Protocol), consulte Online Certificate Status Protocol em wikipedia.org.

  • Acessibilidade de rede interna – Status da verificação mais recente da URL interna. Configure a URL como parte de uma Configuração de Site do Tunnel.

    • Íntegro: o servidor pode acessar a URL especificada nas propriedades do site.
    • Não íntegro: o servidor não pode acessar a URL especificada nas propriedades do site.
    • Desconhecido – esse status é exibido quando você não define uma URL nas propriedades do site. Esse status não afeta o status geral do site.

  • Capacidade de atualização – a capacidade do servidor de contactar o Repositório de Contentor da Microsoft, que permite que o Gateway de Túnel atualize quando as versões ficam disponíveis.

    • Bom estado de funcionamento – o servidor não contactou o Repositório de Contentor da Microsoft nos últimos 5 minutos.
    • Mau estado de funcionamento – o servidor não contacta o Repositório de Contentor da Microsoft há mais de 5 minutos.

  • Versão do servidor: o status do software do servidor de gateway de túnel, em relação à versão mais recente.

    • Íntegro – atualizado com a versão mais recente do software
    • Aviso – uma versão anterior
    • Não íntegro – duas ou mais versões anteriores e sem suporte

    Quando a Versão do servidor não estiver Íntegra, planeje instalar atualizações do Microsoft Tunnel.

  • Contentor de servidor – determina se o contentor que aloja o servidor do Microsoft Tunnel está em execução.

    • Bom estado de funcionamento – o status do contentor do servidor está em bom estado de funcionamento.
    • Mau estado de funcionamento – o status do contentor do servidor não está em bom estado de funcionamento.

  • Configuração do servidor – determina se a configuração do servidor é aplicada com êxito ao servidor de Túnel a partir Microsoft Intune definições do site.

    • Bom estado de funcionamento – a configuração do servidor foi aplicada com êxito.
    • Mau estado de funcionamento – não foi possível aplicar a configuração do servidor.

  • Registos do servidor – determina se os registos foram carregados para o servidor nos últimos 60 minutos.

    • Bom estado de funcionamento – os registos do servidor foram carregados nos últimos 60 minutos.
    • Mau estado de funcionamento – os registos do servidor não foram carregados nos últimos 60 minutos.

Gerenciar limites de status de integridade

Você pode personalizar as seguintes métricas de status de integridade do Microsoft Tunnel para alterar os limites usados por cada uma delas para relatar seu status. As personalizações são para todo o locatário e se aplicam a todos os servidores do Tunnel. As métricas de verificação de integridade que podem ser personalizadas incluem:

  • Uso da CPU
  • Uso da memória
  • Uso de espaço em disco
  • Latência

Para modificar um valor de limite de métricas:

Captura de ecrã de como selecionar e configurar limiares de status de estado de funcionamento.

  1. Inicie sessão no centro de administração do Microsoft Intune e aceda a Administração> de inquilinos doMicrosoft Tunnel Gateway>Health status.

  2. Selecione Configurar limites.

  3. Na página Limiares configurados, defina novos limiares para cada categoria de marcar de estado de funcionamento que pretende personalizar.

    • Os valores de limite se aplicam a todos os servidores em todos os sites.
    • Selecione Reverter para o padrão para restaurar todos os limites de volta para os valores padrão.

  4. Selecione Salvar.

  5. No painel status de integridade, selecione Atualizar para atualizar o status de todos os servidores com base nos valores de limite personalizados.

Depois de modificar os limites, os valores na guia Verificação de integridade serão atualizados automaticamente para refletir o status deles com base nos limites atuais.

Captura de tela de uma exibição de Verificação de integridade de um servidor.

Visualize as tendências do status da integridade de métricas de integridade do Gateway do Microsoft Tunnel na forma de um gráfico. Os dados para os gráficos são calculados em um bloco de três horas e, por isso, podem ter um atraso de até três horas.

Os gráficos de tendência do status de integridade estão disponíveis para as seguintes métricas:

  • Conexões
  • Uso da CPU
  • Uso de espaço em disco
  • Uso da memória
  • Latência média
  • Taxa de transferência

Para exibir gráficos de tendência:

  1. Entre no Centro de administração do Microsoft Intune.

  2. Acesse Administração de locatários>Gateway do Microsoft Tunnel>Status da integridade>Selecionar um servidor e selecione Tendências

  3. Use a lista suspensa Métrica para selecionar o gráfico de métrica que você deseja exibir.

Usar a ferramenta de linha de comando mst-cli

Use a ferramenta de linha de comando mst-cli para obter informações sobre o servidor do Microsoft Tunnel. Esse arquivo é adicionado ao servidor Linux quando o Microsoft Tunnel é instalado. A ferramenta está localizada em: /usr/sbin/mst-cli.

Para obter mais informações e exemplos de linha de comando, confira ferramenta de linha de comando mst-cli para o Microsoft Tunnel.

Ver logs do Microsoft Tunnel

O Microsoft Tunnel registrará informações nos logs do servidor Linux no formato syslog. Para ver as entradas de log, use o comando journalctl -t seguido por uma ou mais marcas que são específicas para entradas do Microsoft Tunnel:

  • mstunnel-agent: exibir logs do agente.

  • mstunnel_monitor: exibir logs de tarefas de monitoramento.

  • ocserv - Apresentar registos do servidor.

  • ocserv-access - Exibir logs de acesso.

    Por padrão, o log de acesso está desabilitado. A ativação dos logs de acesso pode reduzir o desempenho, dependendo do número de conexões ativas e dos padrões de uso no servidor. O registro de conexões DNS aumenta o detalhamento dos logs, o que pode se tornar barulhento.

    Os logs de acesso têm o seguinte formato: <Server timestamp><Server Name><ProcessID on Server><userId><deviceId><protocol><src IP and port><dst IP and port><bytes sent><bytes received><connection time in seconds> Por exemplo:

    • 25 de fevereiro 16:37:56 MSTunnelTest-VM ocserv-access[9528]: ACCESS_LOG,41150dc4-238x-4dwv-9q89-55e987f30c32,f5132455-ef2dd-225a-a693-afbbqed482dce,tcp,169.254.54.149:49462,10.88.0.5:80,112,60,10

    Importante

    No ocserv-access, o valor deviceId identifica a instância de instalação exclusiva do Microsoft Defender que é executada num dispositivo e não identifica o ID do dispositivo Intune ou Microsoft Entra ID do dispositivo. Se o Defender for desinstalado e, em seguida, reinstalado num dispositivo, será gerada uma nova instância para DeviceId*.

    Para habilitar o log de acesso:

    1. definir TRACE_SESSIONS=1 in /etc/mstunnel/env.sh
    2. definir TRACE_SESSIONS=2 para incluir o registro de conexões DNS
    3. Executar mst-cli server restart para reiniciar o servidor.

    Se os logs de acesso forem muito barulhentos, você poderá desativar o log de conexão DNS definindo TRACE_SESSIONS=1 e reiniciar o servidor.

  • OCSERV_TELEMETRY - Apresentar detalhes de telemetria para ligações ao Túnel.

    Os registos de telemetria têm o seguinte formato, com os valores para bytes_in, bytes_out e duração a serem utilizados apenas para operações de desconexão: <operation><client_ip><server_ip><gateway_ip><assigned_ip><user_id><device_id><user_agent><bytes_in><bytes_out><duration> por exemplo:

    • 20 de outubro 19:32:15 mstunnel ocserv[4806]: OCSERV_TELEMETRY,connect,31258,73.20.85.75.172.17.0.3,3169.254.0.1,169.254.107.209,3780e1fc-3ac2-4268-a1fd-dd910ca8c13c, 5A683ECC-D909-4E5F-9C67-C0F595A4A70E,MobileAccess iOS 1.1.34040102

    Importante

    No OCSERV_TELEMETRY, o valor deviceId identifica a instância de instalação exclusiva do Microsoft Defender que é executada num dispositivo e não identifica o ID do dispositivo Intune nem Microsoft Entra ID do dispositivo. Se o Defender for desinstalado e, em seguida, reinstalado num dispositivo, será gerada uma nova instância para DeviceId*.

Exemplos de linha de comando para journalctl:

  • Para visualizar informações apenas para o servidor de túnel, execute journalctl -t ocserv.
  • Para ver o registo de telemetria, execute journalctl -t ocserv | grep TELEMETRY
  • Para visualizar informações de todas as opções de log, você pode executar journalctl -t ocserv -t ocserv-access -t mstunnel-agent -t mstunnel_monitor.
  • Adicionar -f ao comando para exibir uma visualização ativa e contínua do arquivo de log. Por exemplo, para monitorar ativamente os processos em andamento para o Microsoft Tunnel, execute journalctl -t mstunnel_monitor -f.

Mais opções para journalctl:

  • journalctl -h: exibir a ajuda de comando para journalctl.
  • man journalctl – Exibir informações adicionais.
  • man journalctl.conf – Exibir informações sobre a configuração. Para obter mais informações sobre journalctl, confira a documentação para a versão do Linux que você usa.

Carregamento fácil de registos de diagnóstico para servidores de Túnel

Como auxiliar de diagnóstico, pode utilizar um único clique no centro de administração do Intune para ter Intune ativar, recolher e submeter registos verbosos de um Servidor de Gateway de Túnel diretamente para a Microsoft. Estes registos verbosos estão então disponíveis diretamente para a Microsoft quando estiver a trabalhar com a Microsoft para identificar ou resolve problemas com um servidor de Túnel.

Pode recolher e carregar registos verbosos de um evento antes de abrir um incidente de suporte ou, mediante pedido, caso já esteja a trabalhar com a Microsoft para examinar uma operação de servidores de Túnel.

Para utilizar esta capacidade:

  1. Abra o centro de administração do Microsoft Intune aceda a Administração> de inquilinos OGateway> de Túnel da Microsoft seleciona um servidor> e, em seguida, seleciona o separador Registos.

  2. No separador Registos , localize a secção Enviar registos verbosos do servidor e selecione Enviar registos.

Quando seleciona Enviar registos para um servidor de Túnel, é iniciado o seguinte processo:

  • Em primeiro lugar, Intune captura o conjunto atual de registos do servidor de Túnel e carrega-os diretamente para a Microsoft. Estes registos são recolhidos com o nível de verbosidade de registo atual dos servidores. Por predefinição, o nível de verbosidade do servidor é zero (0).
  • Em seguida, Intune ativa um nível de verbosidade de quatro (4) para os registos do servidor do Túnel. Este nível de detalhe de verbosidade é recolhido durante oito horas.
  • Durante as oito horas de recolha de registos verbosos, o problema ou a operação que está a ser investigado deve ser reproduzido para capturar os detalhes verbosos nos registos.
  • Após oito horas, Intune recolhe um segundo conjunto de registos do servidor que incluem os detalhes verbosos e carrega-os para a Microsoft. No momento do carregamento, o Intune também repõe os registos do servidor do Túnel para utilizar o nível de verbosidade predefinido de zero (0). Se tiver aumentado anteriormente o nível de verbosidade do Servidor, depois de Intune repor a verbosidade para zero, pode restaurar o nível de verbosidade personalizado.

Cada conjunto de registos que Intune recolhe e carrega é identificado como um conjunto separado com os seguintes detalhes apresentados no centro de administração abaixo do botão Enviar registos:

  • Uma hora de início e de fim da coleção de registos
  • Quando o carregamento foi gerado
  • O registo define o nível de verbosidade
  • Um ID de Incidente que pode ser utilizado para identificar esse conjunto de registos específico

Captura de ecrã que mostra a interface Enviar registos de servidor verboso.

Depois de capturar um problema durante a execução da recolha de registos verboso, pode fornecer o ID do Incidente desse registo definido à Microsoft para ajudar na investigação.

Acerca da recolha de registos

  • Intune não para nem reinicia o servidor de Túnel para ativar ou desativar o registo verboso.
  • O período de registo verboso de oito horas não pode ser prolongado ou parado mais cedo.
  • Pode utilizar o processo Enviar registos com a frequência necessária para capturar um problema com o registo verboso. No entanto, o aumento da verbosidade do registo adiciona tensão ao Servidor de Túnel e não é recomendado como uma configuração normal.
  • Após o fim do registo verboso, o nível de verbosidade predefinido de zero é definido para os registos do servidor do Túnel, independentemente dos níveis de verbosidade definidos anteriormente.
  • Os seguintes registos são recolhidos através deste processo:
    • mstunnel-agent (Registos do agente)
    • mstunnel_monitor (Monitorizar registos de tarefas)
    • ocserv (Registos do servidor)

Os registos ocserv-access não são recolhidos ou carregados.

Problemas conhecidos

A seguir estão os problemas conhecidos do Microsoft Tunnel.

Integridade do servidor

Os clientes podem utilizar o Túnel com êxito quando o estado de funcionamento do servidor status é apresentado como offline

Problema: no separador status Estado de Funcionamento do Túnel, o estado de funcionamento de um servidor status comunica como offline indicando que está desligado, embora os utilizadores possam aceder ao servidor de túnel e ligar aos recursos da organização.

Solução: para resolve este problema, tem de reinstalar o Microsoft Tunnel, que volta a inscrever o agente do servidor do Túnel com Intune. Para evitar este problema, instale as atualizações para o agente do Túnel e o servidor logo após serem lançadas. Utilize as métricas de estado de funcionamento do servidor de túnel no centro de administração do Microsoft Intune para monitorizar o estado de funcionamento do servidor.

Com o Podman, verá "Erro ao executar a verificação" no registo de mstunnel_monitor

Problema: o Podman não consegue identificar ou ver que os contentores ativos estão em execução e comunica "Erro ao executar a verificação" no registo mstunnel_monitor do servidor do Túnel. Seguem-se exemplos dos erros:

  • Agente:

    Error executing Checkup
Error details
\tscript: 561 /usr/sbin/mst-cli
\t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger)
\tstack:
\t\t<> Checkup /usr/sbin/mst-cli Message: NA
\t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-agent
\t\t<> main /usr/sbin/mstunnel_monitor Message: NA

  • Servidor:

    Error executing Checkup
Error details
\tscript: 649 /usr/sbin/mst-cli
\t\tcommand: $ctr_cli exec $agent_name mstunnel checkup 2> >(FailLogger)
\tstack:
\t\t<> Checkup /usr/sbin/mst-cli Message: NA
\t\t<> MonitorServices /usr/sbin/mst-cli Message: Failure starting service mstunnel-server
\t\t<> main /usr/sbin/mstunnel_monitor Message: NA

Solução: para resolve este problema, reinicie manualmente os contentores do Podman. Em seguida, o Podman deverá conseguir identificar os contentores. Se o problema persistir ou devolver, considere utilizar cron para criar uma tarefa que reinicia automaticamente os contentores quando este problema é visto.

Com o Podman, verá erros System.DateTime no registo mstunnel-agent

Problema: quando utiliza o Podman, o registo mstunnel-agent pode conter erros semelhantes às seguintes entradas:

  • Failed to parse version-info.json for version information.
  • System.Text.Json.JsonException: The JSON value could not be converted to System.DateTime

Este problema ocorre devido a diferenças nas datas de formatação entre o Podman e o Agente de Túnel. Estes erros não indicam um problema fatal nem impedem a conectividade. A partir dos contentores lançados após outubro de 2022, os problemas de formatação devem ser resolvidos.

Solução: para resolve estes problemas, atualize o contentor do agente (Podman ou Docker) para a versão mais recente. À medida que forem detetadas novas origens destes erros, continuaremos a corrigi-los nas atualizações de versões subsequentes.

Conectividade ao Túnel

Falha na conexão dos dispositivos ao servidor do Tunnel

Problema: os dispositivos não conseguem ligar ao servidor e o ficheiro de registo ocserv do servidor de túnel contém uma entrada semelhante à seguinte entrada: main: tun.c:655: Can't open /dev/net/tun: Operation not permitted

Para obter orientações sobre como visualizar os logs do Túnel, consulte Exibir logs do Túnel da Microsoft neste artigo.

Solução: reinicie o servidor com mst-cli server restart o após o servidor Linux reiniciar.

Se este problema persistir, considere automatizar o comando de reinicialização usando o utilitário de agendamento cron. Confira Como usar o cron no Linux em opensource.com.

Próximas etapas

Referência para o Microsoft Tunnel