Устранение неполадок #REF! с помощью журналов диагностики

Сводка

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

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

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

• Журнал диагностики шлюза
• Журнал диагностики туннеля
• Журнал диагностики маршрута
• IKEDiagnosticLog
• P2SDiagnosticLog

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

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

Сведения о настройке событий журнала диагностики из #REF! с помощью #REF! см. в разделе Создание параметров диагностики в Azure Monitor.

GatewayDiagnosticLog

Изменения конфигурации проверяются в таблице GatewayDiagnosticLog . Это может занять несколько минут, прежде чем изменения будут отражены в журналах.

Ниже приведен пример запроса в качестве ссылки.

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

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

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

Пример операции set Gateway, показанной в GatewayDiagnosticLog.

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

Сравнение результатов из таблицы GatewayDiagnosticLog с результатами таблицы 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 показывает несколько столбцов.

Пример выходных данных:

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

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

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

• Если вы наблюдаете событие отключения на одном экземпляре шлюза, за которым в течение нескольких секунд следует событие подключения на другом экземпляре шлюза, это указывает на отказоустойчивость шлюза. Такое событие обычно возникает из-за обслуживания экземпляра шлюза. Дополнительные сведения об этом поведении см. в разделе О повышении надежности VPN-шлюза #REF!.
• Такое же поведение наблюдается при намеренном запуске Gateway Reset на стороне #REF!, что приводит к перезагрузке активного экземпляра шлюза. Дополнительные сведения об этом поведении см. в статье Reset a VPN-шлюз.
• Если вы видите событие отключения на одном экземпляре шлюза, за которым через несколько секунд следует событие подключения на том же шлюзе, это может быть сбоем в сети, вызывающим истечение времени ожидания DPD, или ошибочно отправленным отключением от внутреннего устройства.

Журнал диагностики маршрута

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

Ниже приведен пример запроса в качестве ссылки.

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

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

В выходных данных показаны полезные сведения о одноранговых узлах 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 показывает несколько столбцов.

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

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

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

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

• SA_INIT содержит параметры IPsec, которые одноранговый узел хочет использовать для этого согласования IPsec. Официальный документ
  Параметры по умолчанию для IPsec/IKE содержат параметры IPsec, поддерживаемые шлюзом #REF! с настройками по умолчанию.

P2SDiagnosticLog

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

Ниже приведен пример запроса в качестве ссылки.

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

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

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

Пример подключения "Точка — сеть", показанный в P2SDiagnosticLog.

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

[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

Дальнейшие шаги

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