Устранение неполадок с VPN-шлюзом Azure с помощью журналов диагностики

  • Статья

В этой статье содержатся сведения о различных журналах, доступных для диагностики VPN-шлюза, а также об их использовании для эффективного устранения неполадок VPN-шлюза.

Если проблема Azure не устранена в этой статье, посетите форумы Azure на форумах Microsoft Q и A и Stack Overflow. Описание своей проблемы можно опубликовать на этих форумах или написать в Twitter (@AzureSupport). Также можно отправить запрос в службу поддержки Azure. Чтобы отправить такой запрос, на странице поддержки Azure щелкните Получить поддержку.

Следующие журналы доступны* в Azure:

Имя Description
GatewayDiagnosticLog Содержит журналы диагностики для событий конфигурации шлюза, основных изменений и событий обслуживания.
TunnelDiagnosticLog Содержит события изменения состояния туннеля. События подключения и отключения туннеля имеют обобщенную причину изменения состояния, если это применимо.
RouteDiagnosticLog Регистрирует изменения статических маршрутов и события BGP, происходящие на шлюзе.
IKEDiagnosticLog Регистрирует сообщения и события управления протокола IKE на шлюзе.
P2SDiagnosticLog Регистрирует сообщения и события управления "точка — сеть" на шлюзе.

*для шлюзов на основе политик доступны только шлюзы GatewayDiagnosticLog и RouteDiagnosticLog.

Обратите внимание: в этих таблицах имеется несколько столбцов. Для удобства восприятия в этой статье мы сосредоточимся только на наиболее важных из них.

Настройка ведения журнала

Выполните следующую процедуру, чтобы узнать, как настроить события журнала диагностики из Azure VPN-шлюз с помощью Azure Log Analytics:

  1. Создайте рабочую область Log Analytics с помощью этой статьи.

  2. Найдите VPN-шлюз в колонке параметров диагностики монитора > .

Screenshot of the Diagnostic settings blade.

  1. Выберите шлюз и нажмите кнопку "Добавить параметр диагностики".

Screenshot of the Add diagnostic setting interface.

  1. Введите имя параметра диагностики, выберите все категории журналов и выберите рабочую область Log Analytics.

Detailed screenshot of the Add diagnostic setting properties.

Примечание.

Для первоначального отображения данных может потребоваться несколько часов.

GatewayDiagnosticLog

В таблице GatewayDiagnosticLog осуществляется аудит изменений конфигурации. На отражение внесенных изменений в журналах может потребоваться несколько минут.

Вот пример запроса:

AzureDiagnostics  
| where Category == "GatewayDiagnosticLog"  
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup  
| sort by TimeGenerated asc

Этот запрос к GatewayDiagnosticLog возвращает несколько столбцов.

Имя Description
TimeGenerated Метка времени каждого события в часовом поясе UTC.
OperationName Произошедшее событие. Это может быть одно из таких событий: SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration.
Сообщение Подробные сведения о выполняемой операции и список успешных и неудачных результатов.

В этом примере показано действие, зарегистрированное при применении новой конфигурации:

Example of a Set Gateway Operation seen in GatewayDiagnosticLog.

Обратите внимание: операция SetGatewayConfiguration регистрируется при каждом изменении конфигурации как на VPN-шлюзе, так и на шлюзе локальной сети. Сопоставив результаты из таблиц GatewayDiagnosticLog и TunnelDiagnosticLog, можно понять, начался ли сбой подключения туннеля в момент, когда была изменена конфигурация, или в это время выполнялось обслуживание. Эти сведения могут сыграть важную роль в определении первопричины.

TunnelDiagnosticLog

Таблица TunnelDiagnosticLog очень полезна для проверки состояния подключения туннеля за тот или иной период.

Вот пример запроса:

AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
//| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc

Этот запрос к TunnelDiagnosticLog возвращает несколько столбцов.

Имя Description
TimeGenerated Метка времени каждого события в часовом поясе UTC.
OperationName Произошедшее событие. Это может быть событие TunnelConnected или TunnelDisconnected.
remoteIP_s IP-адрес локального VPN-устройства. В реальных сценариях удобно выполнять фильтрацию по IP-адресу соответствующего локального устройства, если их несколько.
Instance_s Экземпляр роли шлюза, который активировал событие. Это может быть GatewayTenantWorker_IN_0 или GatewayTenantWorker_IN_1 (имена двух экземпляров шлюза).
Ресурс Имя VPN-шлюза.
ResourceGroup Группа ресурсов, в которой находится шлюз.

Пример результата:

Example of a Tunnel Connected Event seen in TunnelDiagnosticLog.

Таблица TunnelDiagnosticLog очень полезна для устранения неполадок, связанных с прошлыми событиями непредвиденного отключения VPN. Данные представлены в простой форме, что дает возможность с минимальными усилиями анализировать большие диапазоны времени через несколько дней. Только после того, как вы определите метку времени отключения, можно перейти к более подробному анализу таблицы IKEdiagnosticLog, чтобы тщательно изучить причины отключения, если они связаны с IPSec.

Советы по устранению неполадок

  • Если вы видите событие отключения на одном экземпляре шлюза, а за ним через несколько секунд следует событие подключения на другом экземпляре, это означает, что вы просматриваете отработку отказа шлюза. Как правило, это ожидаемое поведение, связанное с обслуживанием экземпляра шлюза. Дополнительные сведения об этом см. в разделе Избыточность VPN-шлюзов Azure.
  • Такое же поведение будет наблюдаться, если вы намеренно запустите сброс шлюза на стороне Azure, так как это приведет к перезагрузке активного экземпляра шлюза. Дополнительные сведения об этом см. в статье Сброс VPN-шлюза.
  • Если вы видите событие отключения на одном экземпляре шлюза, а за ним через несколько секунд следует событие подключения на том же экземпляре, это может означать сбой сети, вызвавший тайм-аут DPD, или событие отключения, по ошибке отправленное локальным устройством.

RouteDiagnosticLog

В таблице RouteDiagnosticLog отслеживаются действия для статически измененных маршрутов или маршрутов, полученных по протоколу BGP.

Вот пример запроса:

AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup

Этот запрос к RouteDiagnosticLog возвращает несколько столбцов.

Имя Description
TimeGenerated Метка времени каждого события в часовом поясе UTC.
OperationName Произошедшее событие. Это может быть событие StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent или BgpDisconnectedEvent.
Сообщение Сведения о выполняемой операции.

В выходных данных отображаются полезные сведения о подключенных и отключенных узлах BGP, а также об измененных маршрутах.

Пример:

Example of BGP route exchange activity seen in RouteDiagnosticLog.

IKEDiagnosticLog

В таблице IKEDiagnosticLog содержатся подробные данные журнала отладки для IKE/IPSec. Они очень полезны при устранении неполадок, связанных с отключениями, или сбоя подключения к сценариям VPN.

Вот пример запроса:

AzureDiagnostics  
| where Category == "IKEDiagnosticLog" 
| extend Message1=Message
| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2
| extend Event = iif(Message has "SESSION_ID",Message2,Message1)
| project TimeGenerated, RemoteIP, LocalIP, Event, Level 
| sort by TimeGenerated asc

Этот запрос к IKEDiagnosticLog возвращает несколько столбцов.

Имя Description
TimeGenerated Метка времени каждого события в часовом поясе UTC.
RemoteIP IP-адрес локального VPN-устройства. В реальных сценариях удобно выполнять фильтрацию по IP-адресу соответствующего локального устройства, если их несколько.
LocalIP IP-адрес VPN-шлюза, для которого выполняется устранение неполадок. В реальных сценариях удобно выполнять фильтрацию по IP-адресу соответствующего VPN-шлюза, если в подписке их несколько.
Событие Содержит диагностическое сообщение, полезное для устранения неполадок. Обычно начинается с ключевого слова и описывает действия, выполненные шлюзом Azure. SEND указывает на событие, вызванное пакетом IPSec, который отправлен шлюзом Azure. RECEIVED указывает на событие, вызванное пакетом, который получен от локального устройства. LOCAL означает действие, выполненное локально шлюзом Azure.

Обратите внимание: столбцы RemoteIP, LocalIP и Event отсутствуют в исходном списке столбцов в базе данных AzureDiagnostics, но добавляются в запрос путем анализа выходных данных столбца Message для упрощения анализа.

Советы по устранению неполадок

  • Чтобы определить начало согласования IPSec, необходимо найти исходное сообщение SA_INIT. Такое сообщение может быть отправлено любой из сторон туннеля. Отправитель первого пакета называется в терминологии IPsec называется инициатором, а вторая сторона становится отвечающим устройством. Первым сообщением SA_INIT всегда является то, в котором rCookie = 0.

  • Если не удается установить туннель IPsec, Azure повторяет попытку каждые несколько секунд. По этой причине для устранения неполадок, связанных с "зависанием" VPN, очень удобно использовать таблицу IKEdiagnosticLog, так как нет необходимости дожидаться определенного времени, чтобы воспроизвести проблему. Кроме того, теоретически эта ошибка будет всегда одинаковой при каждой попытке, поэтому можно рассмотреть подробно одно согласование в качестве примера в любое время.

  • Сообщение SA_INIT содержит параметры IPsec, которые узел хочет использовать для этого согласования IPSec. В официальном документе
    Параметры IPsec/IKE по умолчанию перечислены параметры IPsec, поддерживаемые шлюзом Azure, со значениями по умолчанию.

P2SDiagnosticLog

Последняя доступная таблица для диагностики VPN — P2SDiagnosticLog. В этой таблице отслеживаются действия "Точка — сеть" (только протоколы IKEv2 и OpenVPN).

Вот пример запроса:

AzureDiagnostics  
| where Category == "P2SDiagnosticLog"  
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup

Этот запрос к P2SDiagnosticLog возвращает несколько столбцов.

Имя Description
TimeGenerated Метка времени каждого события в часовом поясе UTC.
OperationName Произошедшее событие. В данном случае — это P2SLogEvent.
Сообщение Сведения о выполняемой операции.

В выходных данных будут показаны все параметры для подключения "точка — сеть", примененные шлюзом, а также действующие политики IPsec.

Example of Point to Site connection seen in P2SDiagnosticLog.

Кроме того, всякий раз, когда клиент будет использовать подключение "точка — сеть" по протоколу IKE версии 2 или через OpenVPN, в таблицу будут записываться активность пакетов, взаимодействия EAP/RADIUS, а также успешные и неудачные результаты по пользователям.

Example of EAP authentication seen in P2SDiagnosticLog.

Next Steps

Сведения о настройке оповещений для журналов ресурсов туннеля см. в разделе Настройка оповещений для журналов ресурсов VPN-шлюза.