Ku janë regjistrat e Azure Point-to-Site VPN? Shikoni në Monitor

Një përdorues nuk mund të lidhet me gateway-n point-to-site, hapni panelin e gateway-t dhe nuk ka asnjë histori lidhjesh askund në faqe. Konfigurimi, certifikatat, statusi: gjithçka e pranishme, asnjë regjistër. Regjistrat ekzistojnë, por faqet e rrjetit nuk i prodhojnë fare. Ata vijnë nga një konfigurim diagnostik i bashkangjitur burimit të gateway-t, dhe ai konfigurim jeton nën Monitor; për këtë arsye kërkimi i parë në vendin e dukshëm nuk kthen asgjë, dhe njerëzit përfundojnë se shërbimi nuk mban asnjë gjurmë auditimi.

Pse dështon kërkimi i dukshëm

Udhëzuesit e vjetër thonë se Azure Point-to-Site VPN nuk ka auditim, dhe kjo ishte e vërtetë kur shërbimi nuk ekspozonte asnjë regjistër për çdo lidhje. Gateway-t aktuale publikojnë regjistra diagnostikë të tunelit, kështu që pyetja e dobishme ndryshoi: jo nëse ekzistojnë regjistra, por cili burim i lëshon ata dhe cilën kategori keni aktivizuar. Paneli i gateway-t është një sipërfaqe konfigurimi, dhe sipërfaqet e konfigurimit rrallë shërbejnë edhe si shikues regjistrash. Një konfigurim diagnostik është një objekt për çdo burim, kështu që burimi që zgjidhni përcakton gjithçka që vijon.

Gjysma tjetër e konfuzionit është vërtetimi. Lidhjet point-to-site të bazuara në certifikata nuk gjenerojnë një ngjarje hyrjeje për çdo përdorues siç bën një ofrues identiteti, kështu që nuk ka regjistër për një person të emërtuar që shkruan një fjalëkalim.

Bashkangjitni konfigurimin diagnostik burimit të gateway-t

Hapni Monitor, pastaj Diagnostic settings, dhe shtoni një konfigurim të ri, objektivi i të cilit është vetë gateway-i i rrjetit virtual dhe jo rrjeti virtual që e përmban. Zgjidhni kategorinë diagnostike point-to-site, atë të quajtur P2SDiagnosticLog, sepse ajo mbart regjistrat e lidhjes për çdo klient; shtoni kategoritë tunel, rrugë ose IKE vetëm për gabimet site-to-site që ato mbulojnë. Pastaj dërgoni të dhënat në një hapësirë pune Log Analytics që ju kontrolloni, me një periudhë mbajtjeje që keni zgjedhur me qëllim. Shumica e kërkimeve të dështuara janë një konfigurim i bashkangjitur burimit të gabuar, jo një funksion që mungon.

Listat e kategorive ndryshojnë sipas llojit dhe gjeneratës së gateway-t. Nëse kategoria point-to-site mungon, gateway-i mund të jetë më i vjetër se funksioni ose të ekzekutojë një SKU që nuk e lëshon kurrë, prandaj kontrolloni kategoritë e mbështetura përpara se të kërkoni një problem lejeje. Një gateway pa kategori point-to-site nuk është i prishur; thjesht nuk mund të jetë burimi i atij regjistri, dhe zëvendësuesi më i afërt është kategoria tunel ose IKE, e cila regjistron adresën e klientit edhe pse nuk përshkruan një sesion point-to-site. Konfirmoni listën e kategorive përpara se të hapni një rast mbështetjeje për regjistrat që mungojnë.

Lexoni regjistrat në tabelën që përdor modaliteti juaj

Në modalitetin e vjetër të grumbullimit, hyrjet përfundojnë në tabelën AzureDiagnostics dhe kategoria shfaqet si vlerë kolone; me tabelat specifike të burimit, gateway-i ka tabelën e vet. Në çdo rast, kërkoni sipas burimit të gateway-t dhe një dritareje rreth përpjekjes së dështuar, dhe më pas lexoni korrelacionin në vend të rreshtave individualë:

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

Grupi i kolonave ndjek modalitetin tuaj të grumbullimit, prandaj trajtojeni kërkesën si një formë dhe jo si një skript. Ajo që kërkoni është një adresë klienti që shfaqet dhe më pas zhduket, me një lloj rezultati që nuk është sukses.

Përputhni regjistrin e gateway-t me këndvështrimin e klientit

Regjistrat e gateway-t përshkruajnë tunelin, jo pse një laptop nuk arriti të ndërtojë një. Mblidhni anën e klientit në të njëjtën vulë kohe: regjistrin e ngjarjeve të Windows për klientin RAS, regjistrin e lidhjeve të macOS ose tekstin e gabimit që shfaqi aplikacioni i klientit. Një regjistër gateway pa një përpjekje përkatëse klienti tregon klientin; një klient që raporton sukses ndërsa gateway-i nuk regjistron asgjë zakonisht do të thotë që profili synon një gateway tjetër.

Mbajini të dyja gjysmat në të njëjtin biletë. Vetëm regjistri i gateway-t fton në përfundimin e gabuar, dhe vetëm regjistri i klientit nuk mund të tregojë nëse paketa arriti ndonjëherë.

Nëse asgjë nuk shfaqet në asnjë vend, kontrolloni orën në klient përpara se të dyshoni në platformë. Vulat e kohës të shtrembëruara bëjnë që korrelacioni të dështojë në një mënyrë që duket saktësisht si të dhëna që mungojnë.

Mbajtja, fushëveprimi dhe hyrja në runbook

Regjistrat e tunelit mbartin adresa klientësh dhe vula kohe lidhjesh, prandaj trajtojini si të dhëna personale me një plan fshirjeje në vend që të lini vlerën e paracaktuar të platformës. Kontrolloni gjithashtu që hapësira e punës nuk po thith çdo kategori nga çdo burim në abonim, sepse një hapësirë pune e zhurmshme e bën korrelacionin më të ngadaltë sesa leximi i drejtpërdrejtë i regjistrit të klientit.

Më në fund, shkruani emrin e konfigurimit, hapësirën e punës dhe kategoritë e zgjedhura në runbook-un e gateway-t. Personi tjetër që do të korrigjojë një klient do të shikojë fillimisht panelin e gateway-t, nuk do të gjejë asgjë dhe do të përfundojë se regjistrat nuk ekzistojnë.