Onde estão os registos do Azure Point-to-Site VPN? Veja no Monitor

Um utilizador não consegue ligar-se ao gateway de ponto a site, abre o painel do gateway e não há qualquer histórico de ligações na página. Configuração, certificados, estado: tudo presente, nenhum registo. Os registos existem, mas não são de todo produzidos pelas páginas de rede. Vêm de uma definição de diagnóstico associada ao recurso do gateway, e essa definição vive no Monitor; por isso a primeira pesquisa no local óbvio não devolve nada e as pessoas concluem que o serviço não guarda qualquer rasto de auditoria.

Porque falha a pesquisa óbvia

Guias mais antigos afirmam que o Azure Point-to-Site VPN não tem auditoria, e isso era verdade quando o serviço não expunha qualquer registo por ligação. Os gateways atuais publicam registos de diagnóstico do túnel, pelo que a pergunta útil mudou: não se existem registos, mas que recurso os emite e que categoria ativou. O painel do gateway é uma superfície de configuração, e as superfícies de configuração raramente servem também como visualizadores de registos. Uma definição de diagnóstico é um objeto por recurso, pelo que o recurso que escolher determina tudo o que se segue.

A outra metade da confusão é a autenticação. As ligações de ponto a site baseadas em certificados não geram um evento de início de sessão por utilizador como um fornecedor de identidade, pelo que não há registo de uma pessoa nomeada a escrever uma palavra-passe.

Associe a definição de diagnóstico ao recurso do gateway

Abra o Monitor, depois Diagnostic settings, e adicione uma nova definição cujo destino seja o próprio gateway de rede virtual e não a rede virtual que o contém. Selecione a categoria de diagnóstico de ponto a site, a chamada P2SDiagnosticLog, porque é a que transporta os registos de ligação por cliente; adicione as categorias de túnel, rota ou IKE apenas para os erros de site a site que cobrem. Depois envie os dados para uma área de trabalho do Log Analytics que controla, com um período de retenção que escolheu de propósito. A maioria das pesquisas falhadas é uma definição associada ao recurso errado, não uma funcionalidade em falta.

As listas de categorias variam consoante o tipo e a geração do gateway. Se a categoria de ponto a site estiver ausente, o gateway pode ser anterior à funcionalidade ou executar um SKU que nunca a emite, por isso verifique as categorias suportadas antes de procurar um problema de permissões. Um gateway sem categoria de ponto a site não está avariado; simplesmente não pode ser a origem desse registo, e o substituto mais próximo é a categoria de túnel ou IKE, que registra o endereço do cliente embora não descreva uma sessão de ponto a site. Confirme a lista de categorias antes de abrir um caso de suporte sobre registos em falta.

Leia os registos na tabela que o seu modo utiliza

No modo de recolha antigo, as entradas vão para a tabela AzureDiagnostics e a categoria aparece como valor de coluna; com tabelas específicas do recurso, o gateway tem a sua própria tabela. Em qualquer caso, consulte pelo recurso do gateway e por uma janela em torno da tentativa falhada, e depois leia a correlação em vez das linhas individuais:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

O conjunto de colunas segue o seu modo de recolha, por isso trate a consulta como uma forma e não como um script. O que procura é um endereço de cliente que aparece e depois desaparece, com um tipo de resultado que não é sucesso.

Combine o registo do gateway com a visão do cliente

Os registos do gateway descrevem o túnel, não porque um portátil não conseguiu construir um. Recolha o lado do cliente no mesmo carimbo de data/hora: o registo de eventos do Windows para o cliente RAS, o registo de ligações do macOS ou o texto de erro que a aplicação cliente mostrou. Um registo do gateway sem uma tentativa de cliente correspondente aponta para o cliente; um cliente que relata sucesso enquanto o gateway não registra nada normalmente significa que o perfil aponta para outro gateway.

Mantenha as duas metades no mesmo ticket. Um registo do gateway sozinho convida à conclusão errada, e um registo do cliente sozinho não pode mostrar se o pacote chegou alguma vez.

Se não aparecer nada em nenhum dos locais, verifique o relógio do cliente antes de duvidar da plataforma. Carimbos de data/hora desviados fazem a correlação falhar de uma forma que parece exatamente dados em falta.

Retenção, âmbito e a entrada do runbook

Os registos do túnel contêm endereços de cliente e carimbos de data/hora de ligação, por isso trate-os como dados pessoais com um calendário de eliminação em vez de deixar o padrão da plataforma. Verifique também que a área de trabalho não está a ingerir todas as categorias de todos os recursos da subscrição, porque uma área de trabalho ruidosa torna a correlação mais lenta do que ler diretamente o registo do cliente.

Por fim, escreva o nome da definição, a área de trabalho e as categorias escolhidas no runbook do gateway. A próxima pessoa a depurar um cliente olhará primeiro para o painel do gateway, não encontrará nada e concluirá que os registos não existem.