Gdje su Azure Point-to-Site VPN zapisi? Pogledajte u Monitor

Korisnik se ne može povezati s Point-to-Site pristupnikom, otvorite gateway blade i nigdje na stranici nema povijesti veza. Konfiguracija, certifikati, status: sve je prisutno, nema zapisa. Zapisi postoje, ali ih mrežne stranice uopće ne proizvode. Dolaze iz dijagnostičke postavke pridružene resursu pristupnika, a ta postavka živi pod Monitorom; zato prva pretraga na očitom mjestu ne vraća ništa i ljudi zaključe da usluga ne vodi revizijski trag.

Zašto očita pretraga ne uspijeva

Starije smjernice tvrde da Azure Point-to-Site VPN nema reviziju i to je bilo točno kad usluga nije izlagala zapis po vezi. Suvremeni pristupnici objavljuju dijagnostičke zapise tunela, pa se korisno pitanje promijenilo: ne postoje li zapisi, nego koji ih resurs emitira i koju ste kategoriju uključili. Gateway blade je površina za konfiguraciju, a konfiguracijske površine rijetko služe i kao preglednici zapisa. Dijagnostička postavka je objekt po resursu, pa resurs koji odaberete određuje sve što slijedi.

Druga polovica zbrke je autentifikacija. Point-to-Site veze temeljene na certifikatima ne stvaraju događaj prijave po korisniku kao pružatelj identiteta, pa nema zapisa o imenovanoj osobi koja upisuje lozinku.

Pridružite dijagnostičku postavku resursu pristupnika

Otvorite Monitor, zatim Diagnostic settings i dodajte novu postavku čija je meta sam pristupnik virtualne mreže, a ne virtualna mreža koja ga sadrži. Odaberite dijagnostičku kategoriju Point-to-Site, onu nazvanu P2SDiagnosticLog, jer ona nosi zapise o vezama po klijentu; kategorije tunela, rute ili IKE dodajte samo za site-to-site pogreške koje pokrivaju. Zatim pošaljite podatke u radni prostor Log Analytics koji kontrolirate, s razdobljem zadržavanja koje ste svjesno odabrali. Većina neuspjelih pretraga je postavka pridružena pogrešnom resursu, a ne nedostajuća značajka.

Popisi kategorija razlikuju se prema vrsti i generaciji pristupnika. Ako kategorija Point-to-Site nedostaje, pristupnik je možda stariji od značajke ili radi na SKU koji je nikad ne emitira, pa provjerite podržane kategorije prije nego što počnete tražiti problem s dopuštenjima. Pristupnik bez kategorije Point-to-Site nije pokvaren; jednostavno ne može biti izvor tog zapisa, a najbliža zamjena je kategorija tunela ili IKE, koja bilježi adresu klijenta iako ne opisuje Point-to-Site sesiju. Potvrdite popis kategorija prije nego što otvorite slučaj podrške zbog nedostajućih zapisa.

Čitajte zapise u tablici koju koristi vaš način rada

U starom načinu prikupljanja unosi završavaju u tablici AzureDiagnostics i kategorija se pojavljuje kao vrijednost stupca; kod tablica specifičnih za resurs pristupnik ima vlastitu tablicu. U svakom slučaju, pretražujte po resursu pristupnika i vremenskom okviru oko neuspjelog pokušaja, a zatim čitajte korelaciju umjesto pojedinačnih redaka:

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

Skup stupaca slijedi vaš način prikupljanja, pa upit tretirajte kao oblik, a ne kao skriptu. Ono što tražite jest adresa klijenta koja se pojavi i zatim nestane, s tipom rezultata koji nije uspjeh.

Uparite zapis pristupnika s vlastitim pogledom klijenta

Zapisi pristupnika opisuju tunel, a ne zašto prijenosno računalo nije uspjelo izgraditi jedan. Prikupljajte stranu klijenta na istom vremenskom žigu: Windows dnevnik događaja za RAS klijenta, macOS dnevnik veza ili tekst pogreške koji je prikazala klijentska aplikacija. Zapis pristupnika bez odgovarajućeg klijentskog pokušaja upućuje na klijenta; klijent koji prijavljuje uspjeh dok pristupnik ništa ne bilježi obično znači da je profil usmjeren na drugi pristupnik.

Držite obje polovice u istoj prijavi. Samo zapis pristupnika navodi na pogrešan zaključak, a samo klijentski zapis ne može pokazati je li paket ikad stigao.

Ako se ništa ne pojavi na nijednom mjestu, provjerite sat na klijentu prije nego što posumnjate u platformu. Iskrivljeni vremenski žigovi čine da korelacija ne uspije na način koji izgleda točno kao nedostajući podaci.

Zadržavanje, opseg i unos u runbooku

Zapisi tunela nose adrese klijenata i vremenske žigove veza, pa ih tretirajte kao osobne podatke s rasporedom brisanja umjesto da ostavite zadanu postavku platforme. Provjerite i da radni prostor ne prima svaku kategoriju sa svakog resursa u pretplati, jer bučan radni prostor čini korelaciju sporijom od izravnog čitanja klijentskog zapisa.

Na kraju upišite naziv postavke, radni prostor i odabrane kategorije u runbook pristupnika. Sljedeća osoba koja bude otklanjala pogreške na klijentu prvo će pogledati u gateway blade, neće naći ništa i zaključiti da zapisi ne postoje.