Къде са логовете на 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 на шлюза. Следващият човек, който ще отстранява проблем на клиент, първо ще погледне в панела на шлюза, няма да намери нищо и ще заключи, че логовете не съществуват.