Поделиться через

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

  • Статья

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

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

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

  • GatewayDiagnosticLog
  • TunnelDiagnosticLog
  • RouteDiagnosticLog
  • IKEDiagnosticLog
  • P2SDiagnosticLog

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

Сведения обо всех журналах VPN-шлюз см. в справочнике по данным мониторинга azure VPN-шлюз

Сведения о настройке событий журнала диагностики из Azure VPN-шлюз с помощью Azure Log Analytics см. в статье "Создание параметров диагностики" в Azure Monitor.

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.
Сообщение Подробные сведения о выполняемой операции и список успешных и неудачных результатов.

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

Пример: операция настройки шлюза, отображаемая в 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 Группа ресурсов, в которой находится шлюз.

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

Пример: событие подключения туннеля в таблице, отображаемое в TunnelDiagnosticLog.

ТуннельDiagnosticLog полезен для устранения неполадок с прошлыми событиями о непредвиденных отключениях 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, подключенных или отключенных, а также маршрутах, обменяемых данными.

Пример:

Пример: действие изменения маршрута BGP, отображаемое в 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.

Пример: подключение типа

Кроме того, когда клиент устанавливает подключение с помощью Проверки подлинности OpenVPN и Идентификатора Microsoft Entra для типа "точка — сеть", таблица записывает действие пакета следующим образом:

[MSG] [default] [OVPN_XXXXXXXXXXXXXXXXXXXXXXXXXXX] Connect request received. IP=0.X.X.X:XXX
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] AAD authentication succeeded. Username=***tosouser@contoso.com
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Connection successful. Username=***tosouser@contoso.com IP=10.0.0.1

Примечание.

В журнале "точка — сеть" имя пользователя частично скрыто. Первый октет IP-адреса пользователя клиента заменен на 0.

Next Steps

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