Где журналы 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 шлюза. Следующий человек, который будет отлаживать клиента, сначала заглянет в колонку шлюза, ничего не найдёт и решит, что журналов нет.