Hvor er Azure Point-to-Site VPN-loggene? Se i Monitor

En bruker får ikke koblet til Point-to-Site-gatewayen, du åpner gateway-bladet, og det finnes ingen tilkoblingshistorikk noe sted på siden. Konfigurasjon, sertifikater, status: alt er der, ingen poster. Loggene finnes, men de produseres ikke av nettverkssidene i det hele tatt. De kommer fra en diagnostikkinnstilling som er knyttet til gateway-ressursen, og den innstillingen bor under Monitor; derfor gir den første søket på det åpenbare stedet ingenting, og folk konkluderer med at tjenesten ikke fører noe revisjonsspor.

Hvorfor det åpenbare søket mislykkes

Eldre veiledninger sier at Azure Point-to-Site VPN ikke har revisjon, og det var sant da tjenesten ikke eksponerte noen post per tilkobling. Dagens gatewayer publiserer diagnostiske tunnelposter, så det nyttige spørsmålet endret seg: ikke om det finnes logger, men hvilken ressurs som sender dem ut og hvilken kategori du slo på. Gateway-bladet er en konfigurasjonsflate, og konfigurasjonsflater fungerer sjelden også som loggvisere. En diagnostikkinnstilling er et objekt per ressurs, så ressursen du velger bestemmer alt som følger.

Den andre halvparten av forvirringen er autentisering. Sertifikatbaserte Point-to-Site-tilkoblinger genererer ikke en påloggingshendelse per bruker slik en identitetsleverandør gjør, så det finnes ingen post om en navngitt person som skriver inn et passord.

Knytt diagnostikkinnstillingen til gateway-ressursen

Åpne Monitor, deretter Diagnostic settings, og legg til en ny innstilling der målet er selve den virtuelle nettverksgatewayen og ikke det virtuelle nettverket som inneholder den. Velg Point-to-Site-diagnostikkategorien, den som heter P2SDiagnosticLog, fordi det er den som bærer tilkoblingspostene per klient; legg bare til tunnel-, rute- eller IKE-kategoriene for de site-to-site-feilene de dekker. Send deretter dataene til et Log Analytics-arbeidsområde du kontrollerer, med en oppbevaringsperiode du bevisst har valgt. De fleste mislykkede søk er en innstilling knyttet til feil ressurs, ikke en manglende funksjon.

Kategorilistene varierer etter gatewaytype og generasjon. Hvis Point-to-Site-kategorien mangler, kan gatewayen være eldre enn funksjonen eller kjøre en SKU som aldri sender den ut, så sjekk de støttede kategoriene før du leter etter et tillatelsesproblem. En gateway uten Point-to-Site-kategori er ikke ødelagt; den kan rett og slett ikke være kilden til den posten, og den nærmeste erstatningen er tunnel- eller IKE-kategorien, som registrerer klientadressen selv om den ikke beskriver en Point-to-Site-økt. Bekreft kategorilisten før du åpner en støttesak om manglende logger.

Les postene i tabellen modusen din bruker

I den eldre innsamlingsmodusen havner oppføringene i tabellen AzureDiagnostics, og kategorien vises som en kolonneverdi; med ressurs-spesifikke tabeller har gatewayen sin egen tabell. Uansett skal du spørre etter gateway-ressursen og et vindu rundt det mislykkede forsøket, og deretter lese korrelasjonen i stedet for de enkelte radene:

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

Kolonnesettet følger innsamlingsmodusen din, så behandle spørringen som en form, ikke som et skript. Det du ser etter, er en klientadresse som dukker opp og deretter forsvinner, med en resultattype som ikke er suksess.

Pare gateway-posten med klientens eget syn

Gateway-logger beskriver tunnelen, ikke hvorfor en bærbar PC ikke klarte å bygge en. Samle klientsiden på samme tidsstempel: Windows-hendelsesloggen for RAS-klienten, macOS-tilkoblingsloggen eller feilteksten klientappen viste. En gateway-post uten et samsvarende klientforsøk peker på klienten; en klient som rapporterer suksess mens gatewayen ikke registrerer noe, betyr vanligvis at profilen er rettet mot en annen gateway.

Hold begge halvdelene i samme sak. En gateway-logg alene inviterer til feil konklusjon, og en klientlogg alene kan ikke vise om pakken noen gang kom frem.

Hvis ingenting dukker opp noen av stedene, sjekk klokken på klienten før du tviler på plattformen. Skjeve tidsstempler får korrelasjonen til å svikte på en måte som ser nøyaktig ut som manglende data.

Oppbevaring, omfang og runbook-oppføringen

Tunnelposter bærer klientadresser og tilkoblingstidsstempler, så behandle dem som personopplysninger med en sletteplan i stedet for å la plattformens standard stå. Kontroller også at arbeidsområdet ikke tar inn hver kategori fra hver ressurs i abonnementet, fordi et støyende arbeidsområde gjør korrelasjonen langsommere enn å lese klientloggen direkte.

Til slutt skriver du innstillingens navn, arbeidsområdet og de valgte kategoriene i gatewayens runbook. Den neste som feilsøker en klient, vil først se i gateway-bladet, ikke finne noe og konkludere med at loggene ikke finnes.