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ą.
Następujące dzienniki są dostępne* na platformie Azure:
Nazwa/nazwisko | Opis |
---|---|
GatewayDiagnosticLog | Zawiera dzienniki diagnostyczne zdarzeń konfiguracji bramy, podstawowych zmian i zdarzeń konserwacji. |
TunnelDiagnosticLog | Zawiera zdarzenia zmiany stanu tunelu. Zdarzenia połączenia/rozłączania tunelu mają podsumowaną przyczynę zmiany stanu, jeśli ma to zastosowanie. |
RouteDiagnosticLog | Rejestruje zmiany tras statycznych i zdarzeń protokołu BGP występujących w bramie. |
IKEDiagnosticLog | Rejestruje komunikaty i zdarzenia kontroli IKE w bramie. |
P2SDiagnosticLog | Rejestruje komunikaty i zdarzenia sterowania punkt-lokacja w bramie. |
*W przypadku bram opartych na zasadach dostępne są tylko bramy GatewayDiagnosticLog i RouteDiagnosticLog.
Zwróć uwagę, że w tych tabelach jest dostępnych kilka kolumn. W tym artykule przedstawimy tylko najbardziej istotne informacje na potrzeby łatwiejszego użycia dzienników.
Konfigurowanie rejestrowania
Postępuj zgodnie z tą procedurą, aby dowiedzieć się, jak skonfigurować zdarzenia dziennika diagnostycznego z usługi Azure VPN Gateway przy użyciu usługi Azure Log Analytics:
Utwórz obszar roboczy usługi Log Analytics przy użyciu tego artykułu.
Znajdź bramę sieci VPN w bloku Monitorowanie > ustawień diagnostyki.
- Wybierz bramę i kliknij pozycję "Dodaj ustawienie diagnostyczne".
- Wypełnij nazwę ustawienia diagnostycznego, wybierz wszystkie kategorie dzienników i wybierz obszar roboczy usługi Log Analytics.
Uwaga
Początkowe wyświetlenie danych może potrwać kilka godzin.
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 wyświetli 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, Set Połączenie ionConfiguration, 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 będzie rejestrowana za każdym razem, gdy konfiguracja zostanie zmodyfikowana zarówno w bramie sieci VPN, jak i w bramie sieci lokalnej. Krzyżowe odwoływanie się do wyników z tabeli GatewayDiagnosticLog z tabelą TunnelDiagnosticLog może pomóc nam określić, czy awaria łączności tunelu została uruchomiona w tym samym czasie, gdy konfiguracja została zmieniona, czy nastąpiła konserwacja. Jeśli tak, mamy świetny wskaźnik w kierunku możliwej głównej przyczyny.
TunnelDiagnosticLog
Tabela TunnelDiagnosticLog jest bardzo 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 wyświetli 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ć tunel Połączenie lubTunnelDisconnected. |
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 bardzo 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 w jednym wystąpieniu bramy zostanie wyświetlone zdarzenie rozłączenia, a następnie zdarzenie połączenia w innym wystąpieniu bramy w ciągu kilku sekund, patrzysz na tryb failover bramy. Zazwyczaj jest to oczekiwane zachowanie ze względu na konserwację 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 zostanie zaobserwowane, jeśli celowo uruchomisz 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 wyświetli 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, Bgp Połączenie edEvent, BgpDisconnectedEvent. |
Wiadomość | szczegółowe informacje o tym, jaka operacja się dzieje. |
Dane wyjściowe będą zawierać 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 bardzo przydatne 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 wyświetli 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, z których rozwiązujemy problemy. 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. KtoTo w zależności od tego, czy pierwszy pakiet jest nazywany "inicjatorem" w terminologii IPsec, a druga strona staje się "obiektem odpowiadającym". 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 bardzo wygodne w usłudze 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. |
W danych wyjściowych zostaną wyświetlone wszystkie ustawienia punkt-lokacja, które zostały zastosowane przez bramę, a także zastosowane zasady protokołu IPsec.
Ponadto za każdym razem, gdy klient połączy się za pośrednictwem protokołu IKEv2 lub openVPN point to Site, tabela będzie rejestrować aktywność pakietów, konwersacje protokołu EAP/RADIUS i wyniki powodzenia/niepowodzenia według użytkownika.
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.