Де журнали 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 шлюзу. Наступна людина, яка відлагоджуватиме клієнта, спершу загляне в колонку шлюзу, нічого не знайде і вирішить, що журналів немає.