Waar is die Azure Point-to-Site VPN-logboeke? Kyk in Monitor

’n Gebruiker kan nie aan die Point-to-Site-gateway koppel nie, jy maak die gateway-blad oop, en daar is nêrens op die bladsy ’n verbindingsgeskiedenis nie. Konfigurasie, sertifikate, status: alles teenwoordig, geen rekords nie. Die logboeke bestaan, maar hulle word glad nie deur die netwerkblaaie geproduseer nie. Hulle kom van ’n diagnostiese instelling wat aan die gateway-hulpbron gekoppel is, en daardie instelling woon onder Monitor; daarom lewer die eerste soektog op die ooglopende plek niks, en mense lei af dat die diens geen ouditspoor hou nie.

Waarom die ooglopende soektog misluk

Ouer riglyne sê dat Azure Point-to-Site VPN geen oudit het nie, en dit was waar toe die diens geen rekord per verbinding blootgestel het nie. Huidige gateways publiseer tonnel-diagnostiese rekords, so die nuttige vraag het verander: nie of logboeke bestaan nie, maar watter hulpbron hulle uitstuur en watter kategorie jy aangeskakel het. Die gateway-blad is ’n konfigurasie-oppervlak, en konfigurasie-oppervlaktes dien selde ook as logboekkykers. ’n Diagnostiese instelling is ’n objek per hulpbron, so die hulpbron wat jy kies, bepaal alles wat volg.

Die ander helfte van die verwarring is verifikasie. Sertifikaatgebaseerde Point-to-Site-verbindings genereer nie ’n aanmeldgebeurtenis per gebruiker soos ’n identiteitsverskaffer nie, so daar is geen rekord van ’n genoemde persoon wat ’n wagwoord intik om te vind nie.

Koppel die diagnostiese instelling aan die gateway-hulpbron

Maak Monitor oop, dan Diagnostiese instellings, en voeg ’n nuwe instelling by waarvan die teiken die virtuele netwerk-gateway self is, nie die virtuele netwerk wat dit bevat nie. Kies die Point-to-Site-diagnostiese kategorie, die een met die naam P2SDiagnosticLog, want dit dra die verbindingsrekords per kliënt; voeg die tonnel-, roete- of IKE-kategorieë net by vir die site-to-site-foute wat hulle dek. Stuur die data dan na ’n Log Analytics-werkspasie wat jy beheer, met ’n bewaartermyn wat jy doelbewus gekies het. Die meeste mislukte soektogte is ’n instelling wat aan die verkeerde hulpbron gekoppel is, nie ’n ontbrekende funksie nie.

Kategorielyste verskil per gateway-tipe en generasie. As die Point-to-Site-kategorie ontbreek, is die gateway dalk ouer as die funksie of het dit ’n SKU wat dit nooit uitstuur nie; kontroleer dus die ondersteunde kategorieë voordat jy na ’n toestemmingsprobleem soek. ’n Gateway sonder ’n Point-to-Site-kategorie is nie stukkend nie; dit kan eenvoudig nie die bron van daardie rekord wees nie, en die naaste plaasvervanger is die tonnel- of IKE-kategorie, wat die kliëntadres aanteken selfs al beskryf dit nie ’n Point-to-Site-sessie nie. Bevestig die kategorielys voordat jy ’n ondersteuningsgeval oor ontbrekende logboeke oopmaak.

Lees die rekords in watter tabel jou modus ook al gebruik

Met die ouer versamelmodus beland inskrywings in die AzureDiagnostics-tabel en verskyn die kategorie as ’n kolomwaarde; met hulpbron-spesifieke tabelle het die gateway ’n tabel van sy eie. Vra in elk geval op die gateway-hulpbron en ’n venster rondom die mislukte poging, en lees dan die korrelasie eerder as die individuele rye:

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

Die kolomstel volg jou versamelmodus, so behandel die navraag as ’n vorm eerder as ’n skrip. Waarna jy soek, is ’n kliëntadres wat verskyn en dan verdwyn, met ’n resultaat-tipe wat nie sukses is nie.

Pas die gateway-rekord by die kliënt se eie siening

Gateway-logboeke beskryf die tonnel, nie waarom ’n skootrekenaar nie een kon bou nie. Versamel die kliëntkant op dieselfde tydstempel: die Windows-gebeurtenislogboek vir die RAS-kliënt, die macOS-verbindingslogboek, of die foutteks wat die kliënttoepassing gewys het. ’n Gateway-rekord sonder ’n ooreenstemmende kliëntpoging wys op die kliënt; as ’n kliënt sukses rapporteer terwyl die gateway niks aanteken nie, beteken dit gewoonlik die profiel mik op ’n ander gateway.

Hou albei helftes in dieselfde kaartjie. ’n Gateway-logboek alleen nooi die verkeerde gevolgtrekking uit, en ’n kliëntlogboek alleen kan nie wys of die pakkie ooit aangekom het nie.

As niks op enige van die twee plekke verskyn nie, kontroleer die horlosie op die kliënt voordat jy die platform betwyfel. Skeef tydstempels laat korrelasie misluk op ’n manier wat presies soos ontbrekende data lyk.

Bewaring, omvang en die runbook-inskrywing

Tonnel-rekords dra kliëntadresse en verbindingstydstempels, so behandel hulle as persoonlike data met ’n skedule vir verwydering eerder as om die platform-verstek te laat staan. Kontroleer ook dat die werkspasie nie elke kategorie van elke hulpbron in die intekening inneem nie, want ’n raserige werkspasie maak korrelasie stadiger as om die kliëntlogboek direk te lees.

Skryf laastens die instelling se naam, die werkspasie en die gekose kategorieë in die gateway se runbook. Die volgende persoon wat ’n kliënt ontfout, sal eerste in die gateway-blad kyk, niks vind en aflei dat die logboeke nie bestaan nie.