Где су логови Azure Point-to-Site VPN? Погледајте у Monitor-у

Корисник не може да се повеже са гејтвејом Point-to-Site, отворите панел гејтвеја, и нигде на страници нема историје веза. Конфигурација, сертификати, статус: све је присутно, нема записа. Логови постоје, али их мрежне странице уопште не стварају. Долазе из дијагностичког подешавања повезаног са ресурсом гејтвеја, и то подешавање живи под Monitor-ом; зато прва претрага на очигледном месту ништа не враћа, и људи закључују да услуга не води никакав траг ревизије.

Зашто очигледна претрага не успева

Старија упутства тврде да Azure Point-to-Site VPN нема ревизију, и то је било тачно када услуга није излагала ниједан запис по вези. Тренутне гејтвејe објављују дијагностичке записе тунела, па се корисно питање променило: не да ли логови постоје, већ који ресурс их емитује и коју категорију сте укључили. Панел гејтвеја је површина за конфигурацију, а конфигурационе површине ретко служе и као прегледачи логова. Дијагностичко подешавање је објекат по ресурсу, па изабрани ресурс одређује све што следи.

Друга половина забуне је аутентификација. Везе 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 гејтвеја. Следећа особа која буде отклањала грешке на клијенту прво ће погледати у панел гејтвеја, ништа неће наћи и закључити да логови не постоје.