Kje so dnevniki Azure Point-to-Site VPN? Poglejte v Monitor

Uporabnik se ne more povezati s prehodom Point-to-Site, odprete rezino prehoda in nikjer na strani ni zgodovine povezav. Konfiguracija, potrdila, stanje: vse prisotno, nobenih zapisov. Dnevniki obstajajo, vendar jih omrežne strani sploh ne ustvarjajo. Prihajajo iz diagnostične nastavitve, pritrjene na vir prehoda, in ta nastavitev živi pod Monitorjem; zato prvo iskanje na očitnem mestu ne vrne ničesar in ljudje sklepajo, da storitev ne vodi nobene revizijske sledi.

Zakaj očitno iskanje spodleti

Starejša navodila trdijo, da Azure Point-to-Site VPN nima revizije, in to je veljalo, ko storitev ni razkrila nobenega zapisa na povezavo. Sedanji prehodi objavljajo diagnostične zapise predora, zato se je koristno vprašanje spremenilo: ne ali dnevniki obstajajo, ampak kateri vir jih oddaja in katero kategorijo ste vklopili. Rezina prehoda je konfiguracijska površina, konfiguracijske površine pa le redko služijo tudi kot pregledovalniki dnevnikov. Diagnostična nastavitev je objekt na vir, zato izbrani vir določa vse, kar sledi.

Druga polovica zmede je preverjanje pristnosti. Povezave Point-to-Site na podlagi potrdil ne ustvarijo dogodka prijave na uporabnika, kot to počne ponudnik identitete, zato ni zapisa o imenovani osebi, ki bi vnašala geslo.

Pritrdite diagnostično nastavitev na vir prehoda

Odprite Monitor, nato Diagnostic settings, in dodajte novo nastavitev, katere cilj je sam prehod virtualnega omrežja in ne virtualno omrežje, ki ga vsebuje. Izberite diagnostično kategorijo Point-to-Site, tisto z imenom P2SDiagnosticLog, ker prav ta nosi zapise o povezavah na odjemalca; kategorije predora, poti ali IKE dodajte samo za napake site-to-site, ki jih pokrivajo. Nato pošljite podatke v delovni prostor Log Analytics, ki ga nadzorujete, z obdobjem hrambe, ki ste ga izbrali namerno. Večina neuspešnih iskanj je nastavitev, pritrjena na napačen vir, ne manjkajoča funkcija.

Seznami kategorij se razlikujejo glede na vrsto in generacijo prehoda. Če kategorije Point-to-Site ni, je prehod morda starejši od funkcije ali teče na SKU, ki je nikoli ne odda, zato pred iskanjem težave z dovoljenji preverite podprte kategorije. Prehod brez kategorije Point-to-Site ni pokvarjen; preprosto ne more biti vir tega zapisa, najbližja zamenjava pa je kategorija predora ali IKE, ki zabeleži naslov odjemalca, čeprav ne opisuje seje Point-to-Site. Potrdite seznam kategorij, preden odprete primer podpore zaradi manjkajočih dnevnikov.

Berite zapise v tabeli, ki jo uporablja vaš način

V starejšem načinu zbiranja vnosi pristanejo v tabeli AzureDiagnostics in kategorija se prikaže kot vrednost stolpca; pri tabelah, specifičnih za vir, ima prehod svojo tabelo. V vsakem primeru poizvedujte po viru prehoda in časovnem oknu okoli neuspešnega poskusa, nato pa berite korelacijo namesto posameznih vrstic:

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

Nabor stolpcev sledi vašemu načinu zbiranja, zato poizvedbo obravnavajte kot obliko in ne kot skript. Iščete naslov odjemalca, ki se pojavi in nato izgine, z vrsto rezultata, ki ni uspeh.

Povežite zapis prehoda z lastnim pogledom odjemalca

Dnevniki prehoda opisujejo predor, ne zakaj prenosniku ni uspelo zgraditi enega. Zberite stran odjemalca ob istem časovnem žigu: dnevnik dogodkov Windows za odjemalca RAS, dnevnik povezav macOS ali besedilo napake, ki jo je prikazala odjemalska aplikacija. Zapis prehoda brez ustreznega poskusa odjemalca kaže na odjemalca; odjemalec, ki poroča o uspehu, medtem ko prehod ničesar ne zabeleži, običajno pomeni, da je profil usmerjen na drug prehod.

Obe polovici hranite v isti prijavi. Samo dnevnik prehoda vabi k napačnemu sklepu, samo dnevnik odjemalca pa ne more pokazati, ali je paket sploh prispel.

Če se nikjer ne pojavi nič, preverite uro na odjemalcu, preden podvomite v platformo. Popppačeni časovni žigi povzročijo, da korelacija spodleti na način, ki je videti natanko kot manjkajoči podatki.

Hramba, obseg in vnos v runbook

Zapisi predora nosijo naslove odjemalcev in časovne žige povezav, zato jih obravnavajte kot osebne podatke z načrtom izbrisa, namesto da pustite privzeto nastavitev platforme. Preverite tudi, da delovni prostor ne sprejema vsake kategorije iz vsakega vira v naročnini, ker hrupni delovni prostor naredi korelacijo počasnejšo od neposrednega branja odjemalčevega dnevnika.

Nazadnje zapišite ime nastavitve, delovni prostor in izbrane kategorije v runbook prehoda. Naslednja oseba, ki bo odpravljala napake pri odjemalcu, bo najprej pogledala v rezino prehoda, ničesar ne bo našla in sklenila, da dnevnikov ni.