Kus on Azure Point-to-Site VPN-i logid? Vaadake Monitoris

Kasutaja ei saa Point-to-Site'i lüüsiga ühendust luua, te avate lüüsi paneeli ja lehel pole kuskil ühenduste ajalugu. Konfiguratsioon, sertifikaadid, olek: kõik olemas, kirjeid pole. Logid on olemas, kuid võrgulehed ei tooda neid üldse. Need pärinevad lüüsi ressursile lisatud diagnostikaseadest ja see seade elab Monitori all; seetõttu ei tagasta esimene otsing ilmses kohas midagi ja inimesed järeldavad, et teenus ei pea mingit auditijälge.

Miks ilmne otsing ebaõnnestub

Vanemad juhised väidavad, et Azure Point-to-Site VPN-il pole auditit, ja see oli tõsi, kui teenus ei näidanud ühtegi kirjet ühenduse kohta. Praegused lüüsid avaldavad tunneli diagnostikakirjeid, seega on kasulik küsimus muutunud: mitte kas logid on olemas, vaid milline ressurss neid väljastab ja millise kategooria te sisse lülitasite. Lüüsi paneel on konfiguratsioonipind ja konfiguratsioonipinnad on harva ka logivaaturid. Diagnostikaseade on objekt ressursi kohta, seega teie valitud ressurss määrab kõik järgneva.

Teine pool segadusest on autentimine. Sertifikaadipõhised Point-to-Site'i ühendused ei tekita kasutajapõhist sisselogimissündmust nagu identiteedipakkuja, seega pole kirjet nimelisest isikust, kes parooli sisestab.

Lisage diagnostikaseade lüüsi ressursile

Avage Monitor, seejärel Diagnostic settings, ja lisage uus seade, mille siht on virtuaalvõrgu lüüs ise, mitte seda sisaldav virtuaalvõrk. Valige Point-to-Site'i diagnostikakategooria, see, mille nimi on P2SDiagnosticLog, sest just see kannab kliendipõhiseid ühenduskirjeid; lisage tunneli, marsruudi või IKE kategooriad ainult nende kaetavate site-to-site-vigade jaoks. Seejärel saatke andmed Log Analyticsi tööruumi, mida te kontrollite, teadlikult valitud säilitusajaga. Enamik ebaõnnestunud otsinguid on vale ressursi külge lisatud seade, mitte puuduv funktsioon.

Kategooriate loendid erinevad lüüsi tüübi ja põlvkonna järgi. Kui Point-to-Site'i kategooriat pole, võib lüüs olla funktsioonist vanem või töötada SKU-ga, mis seda kunagi ei väljasta, seega kontrollige toetatud kategooriaid enne, kui hakkate õiguste probleemi otsima. Point-to-Site'i kategooriata lüüs ei ole katki; see lihtsalt ei saa olla selle kirje allikas, ja lähim asendus on tunneli või IKE kategooria, mis salvestab kliendi aadressi, kuigi ei kirjelda Point-to-Site'i seanssi. Kinnitage kategooriate loend enne, kui avate puuduvate logide kohta tugijuhtumi.

Lugege kirjeid tabelis, mida teie režiim kasutab

Vanemas kogumisrežiimis satuvad kirjed tabelisse AzureDiagnostics ja kategooria kuvatakse veeru väärtusena; ressursipõhiste tabelite puhul on lüüsil oma tabel. Mõlemal juhul pärige lüüsi ressursi ja ebaõnnestunud katse ümber oleva ajavahemiku järgi ning seejärel lugege korrelatsiooni, mitte üksikuid ridu:

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

Veergude kogum järgib teie kogumisrežiimi, seega käsitlege päringut kujuna, mitte skriptina. See, mida otsite, on kliendi aadress, mis ilmub ja seejärel kaob, tulemuse tüübiga, mis ei ole edukas.

Siduge lüüsi kirje kliendi enda vaatega

Lüüsi logid kirjeldavad tunnelit, mitte seda, miks sülearvuti ei suutnud seda luua. Koguge kliendi pool samal ajatemplil: Windowsi sündmuselogi RAS-kliendi jaoks, macOS-i ühenduselogi või veatekst, mille kliendirakendus kuvas. Lüüsi kirje ilma vastava kliendikatseta osutab kliendile; kui klient teatab edust, samal ajal kui lüüs ei registreeri midagi, tähendab see tavaliselt, et profiil on suunatud teisele lüüsile.

Hoidke mõlemad pooled samas pileti. Ainult lüüsi log kutsub esile vale järelduse ja ainult kliendi log ei saa näidata, kas pakett kunagi kohale jõudis.

Kui kummaski kohas ei ilmu midagi, kontrollige kliendi kella enne, kui platvormi kahtlustate. Kaldus ajatemplid panevad korrelatsiooni ebaõnnestuma viisil, mis näeb täpselt välja nagu puuduvad andmed.

Säilitamine, ulatus ja runbooki kirje

Tunneli kirjed kannavad kliendi aadresse ja ühenduse ajatempleid, seega käsitlege neid isikuandmetena koos kustutamise ajakavaga, selle asemel et jätta platvormi vaikeväärtus kehtima. Kontrollige ka, et tööruum ei võta vastu iga kategooriat igalt tellimuse ressursilt, sest mürane tööruum muudab korrelatsiooni aeglasemaks kui kliendilogi otse lugemine.

Lõpuks kirjutage seadme nimi, tööruum ja valitud kategooriad lüüsi runbooki. Järgmine inimene, kes klienti silub, vaatab kõigepealt lüüsi paneeli, ei leia midagi ja järeldab, et logisid pole olemas.