Hvor er Azure Point-to-Site VPN-logfilerne? Kig i Monitor

En bruger kan ikke oprette forbindelse til Point-to-Site-gatewayen, du åbner gatewaybladet, og der er ingen forbindelseshistorik noget sted på siden. Konfiguration, certifikater, status: alt til stede, ingen poster. Logfilerne findes, men de bliver slet ikke produceret af netværkssiderne. De kommer fra en diagnostic-indstilling, der er knyttet til gatewayressourcen, og den indstilling ligger under Monitor; derfor giver den første søgning det oplagte sted intet, og folk konkluderer, at tjenesten ikke fører noget revisionsspor.

Hvorfor den oplagte søgning fejler

Ældre vejledninger siger, at Azure Point-to-Site VPN ikke har revision, og det var sandt, da tjenesten ikke viste nogen post per forbindelse. Nuværende gateways offentliggør diagnostiske tunnelposter, så det nyttige spørgsmål ændrede sig: ikke om der findes logfiler, men hvilken ressource der udsender dem, og hvilken kategori du slog til. Gatewaybladet er en konfigurationsflade, og konfigurationsflader fungerer sjældent også som logfremvisere. En diagnostic-indstilling er et objekt per ressource, så den ressource, du vælger, bestemmer alt det følgende.

Den anden halvdel af forvirringen er godkendelse. Certifikatbaserede Point-to-Site-forbindelser genererer ikke en loginbegivenhed per bruger, som en identitetsudbyder gør, så der er ingen post om en navngivet person, der taster en adgangskode.

Knyt diagnostic-indstillingen til gatewayressourcen

Åbn Monitor, derefter Diagnostic settings, og tilføj en ny indstilling, hvis mål er selve det virtuelle netværks-gateway og ikke det virtuelle netværk, der indeholder det. Vælg Point-to-Site-diagnostikkategorien, den der hedder P2SDiagnosticLog, fordi den bærer forbindelsesposterne per klient; tilføj kun tunnel-, rute- eller IKE-kategorierne for de site-to-site-fejl, de dækker. Send derefter dataene til et Log Analytics-arbejdsområde, du kontrollerer, med en opbevaringsperiode, du bevidst har valgt. De fleste mislykkede søgninger er en indstilling knyttet til den forkerte ressource, ikke en manglende funktion.

Kategorilister varierer efter gatewaytype og generation. Hvis Point-to-Site-kategorien mangler, kan gatewayen være ældre end funktionen eller køre en SKU, der aldrig udsender den, så kontroller de understøttede kategorier, før du leder efter et tilladelsesproblem. En gateway uden Point-to-Site-kategori er ikke i stykker; den kan simpelthen ikke være kilden til den post, og den nærmeste erstatning er tunnel- eller IKE-kategorien, som registrerer klientadressen, selv om den ikke beskriver en Point-to-Site-session. Bekræft kategorilisten, før du åbner en supportsag om manglende logfiler.

Læs posterne i den tabel, din tilstand bruger

I den ældre indsamlingstilstand havner posterne i tabellen AzureDiagnostics, og kategorien vises som en kolonneværdi; med ressourcespecifikke tabeller har gatewayen sin egen tabel. Under alle omstændigheder skal du forespørge på gatewayressourcen og et vindue omkring det mislykkede forsøg og derefter læse korrelationen i stedet for de enkelte rækker:

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

Kolonnensættet følger din indsamlingstilstand, så behandl forespørgslen som en form, ikke som et script. Det, du leder efter, er en klientadresse, der dukker op og derefter forsvinder, med en resultattype, der ikke er succes.

Par gatewayposten med klientens eget syn

Gatewaylogfiler beskriver tunnelen, ikke hvorfor en bærbar computer ikke kunne bygge en. Indsaml klientsiden på samme tidsstempel: Windows-hændelsesloggen for RAS-klienten, macOS-forbindelsesloggen eller den fejltekst, klientappen viste. En gatewaypost uden et matchende klientforsøg peger på klienten; en klient, der rapporterer succes, mens gatewayen intet registrerer, betyder normalt, at profilen er rettet mod en anden gateway.

Hold begge halvdele i samme sag. En gatewaylog alene indbyder til den forkerte konklusion, og en klientlog alene kan ikke vise, om pakken nogensinde ankom.

Hvis der ikke dukker noget op nogen af stederne, skal du kontrollere uret på klienten, før du betvivler platformen. Skæve tidsstempler får korrelationen til at fejle på en måde, der ligner præcis manglende data.

Opbevaring, omfang og runbook-posten

Tunnelposter bærer klientadresser og forbindelsestidsstempler, så behandl dem som personoplysninger med en sletteplan i stedet for at lade platformens standard stå. Kontroller også, at arbejdsområdet ikke indtager hver kategori fra hver ressource i abonnementet, fordi et støjende arbejdsområde gør korrelationen langsommere end at læse klientloggen direkte.

Skriv til sidst indstillingens navn, arbejdsområdet og de valgte kategorier i gatewayens runbook. Den næste, der fejlretter en klient, vil først kigge i gatewaybladet, intet finde og konkludere, at logfilerne ikke findes.