Дзе знайсці журналы Azure Point-to-Site VPN? Загляньце ў Monitor

Карыстальнік не можа падключыцца да шлюза Point-to-Site, вы адкрываеце блок шлюза, і нідзе на старонцы няма гісторыі злучэнняў. Канфігурацыя, сертыфікаты, стан: усё на месцы, запісаў няма. Журналы існуюць, але сеткавыя старонкі іх зусім не ствараюць. Яны паходзяць з дыягнастычнай налады, далучанай да рэсурсу шлюза, і гэтая налада жыве ў Monitor; таму першы пошук у відавочным месцы нічога не вяртае, і людзі робяць выснову, што служба не вядзе аўдытарскі след.

Чаму відавочны пошук не спраўджваецца

Старыя інструкцыі сцвярджаюць, што Azure Point-to-Site VPN не мае аўдыту, і гэта было праўдай, калі служба не паказвала ніякага запісу на злучэнне. Сучасныя шлюзы публікуюць дыягнастычныя запісы тунеля, таму карыснае пытанне змянілася: не ці існуюць журналы, а які рэсурс іх выдае і якую катэгорыю вы ўключылі. Блок шлюза — гэта паверхня канфігурацыі, а паверхні канфігурацыі рэдка служаць адначасова праглядальнікамі журналаў. Дыягнастычная налада — гэта аб'ект на рэсурс, таму абраны рэсурс вызначае ўсё далейшае.

Другая палова блытаніны — гэта аўтэнтыфікацыя. Злучэнні Point-to-Site на аснове сертыфікатаў не ствараюць падзеі ўваходу на карыстальніка, як гэта робіць пастаўшчык ідэнтычнасці, таму няма запісу пра названую асобу, якая ўводзіць пароль.

Далучыце дыягнастычную наладу да рэсурсу шлюза

Адкрыйце Monitor, затым Diagnostic settings і дадайце новую наладу, мэтай якой з'яўляецца сам шлюз віртуальнай сеткі, а не віртуальная сетка, якая яго змяшчае. Выберыце дыягнастычную катэгорыю Point-to-Site, тую, што называецца P2SDiagnosticLog, бо менавіта яна змяшчае запісы злучэнняў па кожным кліенце; дадавайце катэгорыі тунеля, маршруту або IKE толькі для памылак site-to-site, якія яны пакрываюць. Затым адпраўце даныя ў працоўную прастору Log Analytics, якой вы кіруеце, з тэрмінам захавання, які вы абралі свядома. Большасць няўдалых пошукаў — гэта налада, далучаная да няправільнага рэсурсу, а не адсутная функцыя.

Спісы катэгорый адрозніваюцца ў залежнасці ад тыпу шлюза і пакалення. Калі катэгорыя Point-to-Site адсутнічае, шлюз можа быць старэйшым за гэтую функцыю або працаваць на SKU, які ніколі яе не выдае, таму праверце падтрымліваемыя катэгорыі, перш чым шукаць праблему з дазволамі. Шлюз без катэгорыі Point-to-Site не зламаны; ён проста не можа быць крыніцай гэтага запісу, а найбліжэйшая замена — катэгорыя тунеля або IKE, якая фіксуе адрас кліента, хоць і не апісвае сеанс Point-to-Site. Пацвердзіце спіс катэгорый, перш чым адкрываць зварот у падтрымку пра адсутныя журналы.

Чытайце запісы ў той табліцы, якую выкарыстоўвае ваш рэжым

У старым рэжыме збору запісы трапляюць у табліцу AzureDiagnostics, а катэгорыя паказваецца як значэнне слупка; у табліцах, спецыфічных для рэсурсу, шлюз мае ўласную табліцу. У любым выпадку запытвайце па рэсурсе шлюза і акне вакол няўдалай спробы, а затым чытайце карэляцыю, а не асобныя радкі:

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

Набор слупкоў залежыць ад вашага рэжыму збору, таму стаўцеся да запыту як да формы, а не да скрыпта. Вы шукаеце адрас кліента, які з'яўляецца і потым знікае, з тыпам выніку, які не з'яўляецца поспехам.

Спалучыце запіс шлюза з уласным поглядам кліента

Журналы шлюза апісваюць тунель, а не тое, чаму ноўтбук не здолеў яго пабудаваць. Сабярыце бок кліента з той жа адзнакай часу: журнал падзей Windows для кліента RAS, журнал злучэнняў macOS або тэкст памылкі, які паказаў кліенцкі дадатак. Запіс шлюза без адпаведнай спробы кліента паказвае на кліента; калі кліент паведамляе пра поспех, а шлюз нічога не запісвае, гэта звычайна азначае, што профіль накіраваны на іншы шлюз.

Трымайце абедзве паловы ў адной заяўцы. Адзін журнал шлюза схіляе да няправільнай высновы, а адзін журнал кліента не можа паказаць, ці пакет наогул дайшоў.

Калі нічога не з'яўляецца ні ў адным месцы, праверце гадзіннік на кліенце, перш чым сумнявацца ў платформе. Ссунутыя адзнакі часу прыводзяць да таго, што карэляцыя не ўдаецца гэтак жа, як пры адсутных даных.

Захаванне, абсяг і запіс у runbook

Запісы тунеля ўтрымліваюць адрасы кліентаў і адзнакі часу злучэнняў, таму стаўцеся да іх як да персанальных даных з графікам выдалення, а не пакідайце стандарт платформы. Праверце таксама, што працоўная прастора не прымае кожную катэгорыю ад кожнага рэсурсу ў падпісцы, бо шумная прастора робіць карэляцыю павольнейшай, чым чытанне журнала кліента напрамую.

Нарэшце, запішыце назву налады, працоўную прастору і абраныя катэгорыі ў runbook шлюза. Наступная асоба, якая будзе адладжваць кліента, спачатку зірне ў блок шлюза, нічога не знойдзе і вырашыць, што журналаў не існуе.