Rozwiązywanie problemów z usługą Azure VPN Gateway przy użyciu dzienników diagnostycznych

Ten artykuł pomaga zrozumieć różne dzienniki dostępne do diagnostyki usługi VPN Gateway i jak ich używać do efektywnego rozwiązywania problemów z bramą sieci VPN.

Jeśli problem z platformą Azure nie został rozwiązany w tym artykule, odwiedź fora platformy Azure w witrynach Microsoft Q & A i Stack Overflow. Możesz opublikować swój problem na tych forach lub opublikować go na @AzureSupport na Twitterze. Możesz również przesłać żądanie pomoc techniczna platformy Azure. Aby przesłać wniosek o pomoc techniczną, na stronie pomoc techniczna platformy Azure wybierz pozycję Uzyskaj pomoc techniczną.

Na platformie Azure są dostępne następujące dzienniki:

• GatewayDiagnosticLog
• TunnelDiagnosticLog
• RouteDiagnosticLog
• IKEDiagnosticLog
• P2SDiagnosticLog

W przypadku bram opartych na zasadach dostępne są tylko bramy GatewayDiagnosticLog i RouteDiagnosticLog .

Wszystkie dzienniki usługi VPN Gateway można znaleźć w temacie Dokumentacja danych monitorowania usługi Azure VPN Gateway

Aby skonfigurować zdarzenia dziennika diagnostycznego z usługi Azure VPN Gateway przy użyciu usługi Azure Log Analytics, zobacz Tworzenie ustawień diagnostycznych w usłudze Azure Monitor.

GatewayDiagnosticLog

Zmiany konfiguracji są poddawane inspekcji w tabeli GatewayDiagnosticLog . Może upłynąć kilka minut, zanim zmiany zostaną odzwierciedlone w dziennikach.

W tym miejscu masz przykładowe zapytanie jako odwołanie.

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

To zapytanie w usłudze GatewayDiagnosticLog pokazuje wiele kolumn.

Nazwa/nazwisko	Opis
TimeGenerated	sygnatura czasowa każdego zdarzenia w strefie czasowej UTC.
OperationName	zdarzenie, które się stało. Może to być dowolny element SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration.
Wiadomość	szczegółowe informacje o tym, co się dzieje, oraz wyświetla listę wyników zakończonych powodzeniem/niepowodzeniem.

W poniższym przykładzie pokazano działanie zarejestrowane po zastosowaniu nowej konfiguracji:

Zwróć uwagę, że konfiguracja SetGatewayConfiguration jest rejestrowana za każdym razem, gdy konfiguracja jest modyfikowana zarówno w bramie sieci VPN, jak i w bramie sieci lokalnej.

Porównanie wyników z tabeli GatewayDiagnosticLog z wynikami tabeli TunnelDiagnosticLog może pomóc w ustaleniu, czy podczas zmiany konfiguracji lub działania konserwacji wystąpił błąd łączności tunelu. Jeśli tak, stanowi ona znaczące wskazanie na potencjalną główną przyczynę.

TunnelDiagnosticLog

Tabela TunnelDiagnosticLog jest przydatna do sprawdzania historycznych stanów łączności tunelu.

W tym miejscu masz przykładowe zapytanie jako odwołanie.

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

To zapytanie w pliku TunnelDiagnosticLog pokazuje wiele kolumn.

Nazwa/nazwisko	Opis
TimeGenerated	sygnatura czasowa każdego zdarzenia w strefie czasowej UTC.
OperationName	zdarzenie, które się stało. Może to być tunnelConnected lub TunnelDisconnected.
remoteIP_s	adres IP lokalnego urządzenia sieci VPN. W rzeczywistych scenariuszach warto filtrować według adresu IP odpowiedniego urządzenia lokalnego, jeśli istnieje więcej niż jeden.
Instance_s	wystąpienie roli bramy, które wyzwoliło zdarzenie. Może to być GatewayTenantWorker_IN_0 lub GatewayTenantWorker_IN_1, które są nazwami dwóch wystąpień bramy.
Zasób	wskazuje nazwę bramy sieci VPN.
ResourceGroup	wskazuje grupę zasobów, w której znajduje się brama.

Przykładowe wyjście:

Narzędzie TunnelDiagnosticLog jest przydatne do rozwiązywania problemów z przeszłymi zdarzeniami dotyczącymi nieoczekiwanych rozłączeń sieci VPN. Jego lekki charakter oferuje możliwość analizowania dużych zakresów czasu w ciągu kilku dni z niewielkim nakładem pracy. Dopiero po zidentyfikowaniu sygnatury czasowej rozłączenia można przełączyć się na bardziej szczegółową analizę tabeli IKEdiagnosticLog , aby dokładniej zapoznać się z przyczynami rozłączeń, są powiązane z protokołem IPsec.

Niektóre porady dotyczące rozwiązywania problemów:

• Jeśli zauważysz zdarzenie rozłączenia w jednym wystąpieniu bramy, a następnie zdarzenie połączenia w innym wystąpieniu bramy w ciągu kilku sekund, wskazuje tryb failover bramy. Takie zdarzenie zwykle występuje z powodu konserwacji wystąpienia bramy. Aby dowiedzieć się więcej na temat tego zachowania, zobacz About Azure VPN Gateway redundancy (Informacje o nadmiarowości bramy sieci VPN platformy Azure).
• To samo zachowanie jest obserwowane, jeśli celowo uruchamiasz resetowanie bramy po stronie platformy Azure — co powoduje ponowne uruchomienie aktywnego wystąpienia bramy. Aby dowiedzieć się więcej o tym zachowaniu, zobacz Resetowanie bramy sieci VPN.
• Jeśli w jednym wystąpieniu bramy zostanie wyświetlone zdarzenie rozłączenia, a następnie zdarzenie połączenia w tym samym wystąpieniu bramy w ciągu kilku sekund, może być widoczne usterki sieci powodujące przekroczenie limitu czasu usługi DPD lub błędne rozłączenie wysyłane przez urządzenie lokalne.

RouteDiagnosticLog

Tabela RouteDiagnosticLog śledzi działanie statycznie zmodyfikowanych tras lub tras odebranych za pośrednictwem protokołu BGP.

W tym miejscu masz przykładowe zapytanie jako odwołanie.

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

To zapytanie w usłudze RouteDiagnosticLog pokazuje wiele kolumn.

Nazwa/nazwisko	Opis
TimeGenerated	sygnatura czasowa każdego zdarzenia w strefie czasowej UTC.
OperationName	zdarzenie, które się stało. Może to być jeden z elementów StaticRouteUpdate, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent.
Wiadomość	szczegółowe informacje o tym, jaka operacja się dzieje.

Dane wyjściowe zawierają przydatne informacje o połączonych/rozłączonych elementach równorzędnych BGP i wymienianych trasach.

Przykład:

IKEDiagnosticLog

Tabela IKEDiagnosticLog oferuje pełne rejestrowanie debugowania dla protokołu IKE/IPsec. Jest to przydatne do przejrzenia podczas rozwiązywania problemów z rozłączeniami lub niepowodzenia nawiązywania połączenia ze scenariuszami sieci VPN.

W tym miejscu masz przykładowe zapytanie jako odwołanie.

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

To zapytanie w dzienniku IKEDiagnosticLog pokazuje wiele kolumn.

Nazwa/nazwisko	Opis
TimeGenerated	sygnatura czasowa każdego zdarzenia w strefie czasowej UTC.
RemoteIP	adres IP lokalnego urządzenia sieci VPN. W rzeczywistych scenariuszach warto filtrować według adresu IP odpowiedniego urządzenia lokalnego, jeśli istnieje więcej niż jeden.
LocalIP	adres IP bramy sieci VPN, która jest rozwiązywana. W rzeczywistych scenariuszach warto filtrować według adresu IP odpowiedniej bramy sieci VPN, jeśli w twojej subskrypcji znajduje się więcej niż jeden.
Zdarzenie	zawiera komunikat diagnostyczny przydatny do rozwiązywania problemów. Zazwyczaj zaczynają się od słowa kluczowego i odwołują się do akcji wykonywanych przez usługę Azure Gateway: [SEND] wskazuje zdarzenie spowodowane przez pakiet IPSec wysyłany przez usługę Azure Gateway. [ODEBRANO] wskazuje zdarzenie w wyniku pakietu odebranego z urządzenia lokalnego. [LOCAL] wskazuje akcję podjętą lokalnie przez usługę Azure Gateway.

Zwróć uwagę, że kolumny RemoteIP, LocalIP i Event nie znajdują się na oryginalnej liście kolumn w bazie danych AzureDiagnostics, ale są dodawane do zapytania, analizując dane wyjściowe kolumny "Message", aby uprościć analizę.

Porady dotyczące rozwiązywania problemów:

• Aby zidentyfikować początek negocjacji protokołu IPSec, należy znaleźć początkowy komunikat SA_INIT. Taki komunikat można wysłać po obu stronach tunelu. Każdy, kto wysyła pierwszy pakiet, jest nazywany "inicjatorem" w terminologii IPsec, podczas gdy druga strona staje się "osoba odpowiadająca". Pierwszy komunikat SA_INIT jest zawsze taki, w którym rCookie = 0.

• Jeśli nie można ustanowić tunelu IPsec, platforma Azure będzie ponawiać próby co kilka sekund. Z tego powodu rozwiązywanie problemów z "wyłączoną siecią VPN" jest wygodne w dzienniku IKEdiagnosticLog, ponieważ nie trzeba czekać na określony czas, aby odtworzyć problem. Ponadto awaria będzie zawsze taka sama za każdym razem, gdy spróbujemy, aby po prostu powiększyć jedną "próbkę" negocjacji zakończonych niepowodzeniem w dowolnym momencie.

• SA_INIT zawiera parametry protokołu IPSec, których element równorzędny chce użyć do negocjacji protokołu IPsec. Oficjalny dokument
  Domyślne parametry protokołu IPsec/IKE wyświetla listę parametrów protokołu IPsec obsługiwanych przez usługę Azure Gateway z ustawieniami domyślnymi.

P2SDiagnosticLog

Ostatnia dostępna tabela diagnostyki sieci VPN to P2SDiagnosticLog. Ta tabela śledzi działanie dla połączeń punkt-lokacja (tylko protokoły IKEv2 i OpenVPN).

W tym miejscu masz przykładowe zapytanie jako odwołanie.

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

To zapytanie w dzienniku P2SDiagnosticLog wyświetli wiele kolumn.

Nazwa/nazwisko	Opis
TimeGenerated	sygnatura czasowa każdego zdarzenia w strefie czasowej UTC.
OperationName	zdarzenie, które się stało. Będzie to P2SLogEvent.
Wiadomość	szczegółowe informacje o tym, jaka operacja się dzieje.

Dane wyjściowe zawierają wszystkie ustawienia punkt-lokacja, które zostały zastosowane przez bramę, oraz zasady protokołu IPsec.

Ponadto, gdy klient nawiązuje połączenie przy użyciu uwierzytelniania OpenVPN i Microsoft Entra ID dla punkt-lokacja, tabela rejestruje aktywność pakietów w następujący sposób:

[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

Uwaga

W dzienniku punkt-lokacja nazwa użytkownika jest częściowo zasłonięta. Pierwszy oktet adresu IP użytkownika klienta jest zastępowany wartością 0.

Następne kroki

Aby skonfigurować alerty dotyczące dzienników zasobów tunelu, zobacz Konfigurowanie alertów w dziennikach zasobów usługi VPN Gateway.