Kvar er Azure Point-to-Site VPN-loggene? Sjå i Monitor

Ein brukar får ikkje kopla til Point-to-Site-gatewayen, du opnar gateway-bladet, og det finst ingen tilkoplingshistorikk nokon stad på sida. Konfigurasjon, sertifikat, status: alt er der, ingen postar. Loggene finst, men dei blir ikkje produserte av nettverkssidene i det heile. Dei kjem frå ei diagnostikkinnstilling som er knytt til gateway-ressursen, og den innstillinga bur under Monitor; difor gir det første søket på den openberre staden ingenting, og folk konkluderer med at tenesta ikkje fører noko revisjonsspor.

Kvifor det openberre søket mislukkast

Eldre rettleiingar seier at Azure Point-to-Site VPN ikkje har revisjon, og det var sant då tenesta ikkje eksponerte nokon post per tilkoping. Dagens gatewayar publiserer diagnostiske tunnelpostar, så det nyttige spørsmålet endra seg: ikkje om det finst loggar, men kva ressurs som sender dei ut og kva kategori du slo på. Gateway-bladet er ei konfigurasjonsflate, og konfigurasjonsflater fungerer sjeldan også som loggvisarar. Ei diagnostikkinnstilling er eit objekt per ressurs, så ressursen du vel bestemmer alt som følgjer.

Den andre halvdelen av forvirringa er autentisering. Sertifikatbaserte Point-to-Site-tilkoplingar genererer ikkje ei påloggingshending per brukar slik ein identitetsleverandør gjer, så det finst ingen post om ein namngitt person som skriv inn eit passord.

Knyt diagnostikkinnstillinga til gateway-ressursen

Opne Monitor, deretter Diagnostic settings, og legg til ei ny innstilling der målet er sjølve den virtuelle nettverksgatewayen og ikkje det virtuelle nettverket som inneheld han. Vel Point-to-Site-diagnostikkategorien, den som heiter P2SDiagnosticLog, fordi det er den som ber tilkoplingspostane per klient; legg berre til tunnel-, rute- eller IKE-kategoriane for dei site-to-site-feila dei dekkjer. Send deretter dataa til eit Log Analytics-arbeidsområde du kontrollerer, med ein oppbevaringsperiode du medvite har valt. Dei fleste mislukka søka er ei innstilling knytt til feil ressurs, ikkje ein manglande funksjon.

Kategorilistene varierer etter gatewaytype og generasjon. Viss Point-to-Site-kategorien manglar, kan gatewayen vere eldre enn funksjonen eller køyre ein SKU som aldri sender han ut, så sjekk dei støtta kategoriane før du leitar etter eit tillatingsproblem. Ein gateway utan Point-to-Site-kategori er ikkje øydelagd; han kan rett og slett ikkje vere kjelda til den posten, og den nærmaste erstatninga er tunnel- eller IKE-kategorien, som registrerer klientadressa sjølv om han ikkje skildrar ein Point-to-Site-økt. Stadfest kategorilista før du opnar ei støttesak om manglande loggar.

Les postane i tabellen modusen din brukar

I den eldre innsamlingsmodusen hamnar oppføringane i tabellen AzureDiagnostics, og kategorien blir vist som ein kolonneverdi; med ressurs-spesifikke tabellar har gatewayen sin eigen tabell. Uansett skal du spørje etter gateway-ressursen og eit vindauge rundt det mislukka forsøket, og deretter lese korrelasjonen i staden for dei 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ølgjer innsamlingsmodusen din, så handsam spørjinga som ei form, ikkje som eit skript. Det du ser etter, er ei klientadresse som dukkar opp og deretter forsvinn, med ein resultattype som ikkje er suksess.

Pare gateway-posten med klienten sitt eige syn

Gateway-loggar skildrar tunnelen, ikkje kvifor ein berbar PC ikkje klarte å byggje ein. Samle klientsida på same tidsstempel: Windows-hendingsloggen for RAS-klienten, macOS-tilkoplingsloggen eller feilteksten klientappen viste. Ein gateway-post utan eit samsvarande klientforsøk peikar på klienten; ein klient som rapporterer suksess medan gatewayen ikkje registrerer noko, betyr vanlegvis at profilen er retta mot ein annan gateway.

Hald begge halvdelane i same sak. Ein gateway-logg åleine inviterer til feil konklusjon, og ein klientlogg åleine kan ikkje vise om pakken nokon gong kom fram.

Viss ingenting dukkar opp nokon av stadene, sjekk klokka på klienten før du tvilar på plattforma. Skjeve tidsstempel får korrelasjonen til å svikte på ein måte som ser nøyaktig ut som manglande data.

Oppbevaring, omfang og runbook-oppføringa

Tunnelpostar ber klientadresser og tilkoplingstidsstempel, så handsam dei som personopplysningar med ein sletteplan i staden for å la standarden til plattforma stå. Kontroller også at arbeidsområdet ikkje tar inn kvar kategori frå kvar ressurs i abonnementet, fordi eit støyande arbeidsområde gjer korrelasjonen langsammare enn å lese klientloggen direkte.

Til slutt skriv du innstillinga sitt namn, arbeidsområdet og dei valde kategoriane i runbooken til gatewayen. Den neste som feilsøkjer ein klient, vil først sjå i gateway-bladet, ikkje finne noko og konkludere med at loggene ikkje finst.