Var finns Azure Point-to-Site VPN-loggarna? Titta i Monitor

En användare kan inte ansluta till Point-to-Site-gatewayen, du öppnar gateway-bladet, och det finns ingen anslutningshistorik någonstans på sidan. Konfiguration, certifikat, status: allt finns, inga poster. Loggarna finns, men de produceras inte alls av nätverkssidorna. De kommer från en diagnostikinställning som är kopplad till gateway-resursen, och den inställningen bor under Monitor; därför ger den första sökningen på den uppenbara platsen ingenting, och folk drar slutsatsen att tjänsten inte för någon granskningsspår.

Varför den uppenbara sökningen misslyckas

Äldre vägledningar säger att Azure Point-to-Site VPN inte har någon granskning, och det var sant när tjänsten inte exponerade någon post per anslutning. Nuvarande gateways publicerar diagnostiska tunnelposter, så den användbara frågan ändrades: inte om loggar finns, utan vilken resurs som sänder ut dem och vilken kategori du slog på. Gateway-bladet är en konfigurationsyta, och konfigurationsytor fungerar sällan också som loggvisare. En diagnostikinställning är ett objekt per resurs, så resursen du väljer avgör allt som följer.

Den andra hälften av förvirringen är autentisering. Certifikatbaserade Point-to-Site-anslutningar genererar inte en inloggningshändelse per användare som en identitetsleverantör gör, så det finns ingen post om en namngiven person som skriver ett lösenord.

Koppla diagnostikinställningen till gateway-resursen

Öppna Monitor, sedan Diagnostic settings, och lägg till en ny inställning vars mål är själva den virtuella nätverksgatewayen och inte det virtuella nätverk som innehåller den. Välj Point-to-Site-diagnostikkategorin, den som heter P2SDiagnosticLog, eftersom det är den som bär anslutningsposterna per klient; lägg bara till tunnel-, rutt- eller IKE-kategorierna för de site-to-site-fel de täcker. Skicka sedan data till en Log Analytics-arbetsyta som du kontrollerar, med en lagringsperiod som du medvetet har valt. De flesta misslyckade sökningar är en inställning kopplad till fel resurs, inte en saknad funktion.

Kategorilistorna varierar beroende på gatewaytyp och generation. Om Point-to-Site-kategorin saknas kan gatewayen vara äldre än funktionen eller köra en SKU som aldrig sänder ut den, så kontrollera de kategorier som stöds innan du letar efter ett behörighetsproblem. En gateway utan Point-to-Site-kategori är inte trasig; den kan helt enkelt inte vara källan till den posten, och den närmaste ersättningen är tunnel- eller IKE-kategorin, som registrerar klientadressen även om den inte beskriver en Point-to-Site-session. Bekräfta kategorilistan innan du öppnar ett supportärende om saknade loggar.

Läs posterna i tabellen som ditt läge använder

I det äldre insamlingsläget hamnar posterna i tabellen AzureDiagnostics och kategorin visas som ett kolumnvärde; med resursspecifika tabeller har gatewayen en egen tabell. Oavsett vilket, fråga efter gateway-resursen och ett fönster runt det misslyckade försöket, och läs sedan korrelationen i stället för de enskilda raderna:

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

Kolumnuppsättningen följer ditt insamlingsläge, så behandla frågan som en form och inte som ett skript. Det du letar efter är en klientadress som dyker upp och sedan försvinner, med en resultattyp som inte är framgång.

Para ihop gateway-posten med klientens egen vy

Gateway-loggarna beskriver tunneln, inte varför en bärbar dator inte kunde bygga en. Samla klientsidan vid samma tidsstämpel: Windows-händelseloggen för RAS-klienten, macOS-anslutningsloggen eller feltexten som klientappen visade. En gateway-post utan ett matchande klientförsök pekar på klienten; en klient som rapporterar framgång medan gatewayen inte registrerar något betyder vanligtvis att profilen riktas mot en annan gateway.

Håll båda halvorna i samma ärende. En gateway-logg ensam bjuder in till fel slutsats, och en klientlogg ensam kan inte visa om paketet någonsin kom fram.

Om ingenting dyker upp på någon av platserna, kontrollera klockan på klienten innan du tvivlar på plattformen. Skeva tidsstämplar får korrelationen att misslyckas på ett sätt som ser precis ut som saknade data.

Lagring, omfattning och runbook-posten

Tunnelposter bär klientadresser och anslutningstidsstämplar, så behandla dem som personuppgifter med ett raderingsschema i stället för att låta plattformens standardvärde stå kvar. Kontrollera också att arbetsytan inte tar in varje kategori från varje resurs i prenumerationen, eftersom en bullrig arbetsyta gör korrelationen långsammare än att läsa klientloggen direkt.

Skriv till sist in inställningens namn, arbetsytan och de valda kategorierna i gatewayens runbook. Nästa person som felsöker en klient kommer först att titta i gateway-bladet, inte hitta något och dra slutsatsen att loggarna inte finns.