Gdzie są dzienniki Azure Point-to-Site VPN? Spójrz w Monitor

Użytkownik nie może połączyć się z bramą Point-to-Site, otwierasz blok bramy i nigdzie na stronie nie ma historii połączeń. Konfiguracja, certyfikaty, stan: wszystko jest, brak rekordów. Dzienniki istnieją, ale strony sieciowe wcale ich nie tworzą. Pochodzą z ustawienia diagnostycznego dołączonego do zasobu bramy, a to ustawienie mieszka w Monitor; dlatego pierwsze wyszukiwanie w oczywistym miejscu nic nie zwraca, a ludzie dochodzą do wniosku, że usługa nie prowadzi żadnego śladu audytu.

Dlaczego oczywiste wyszukiwanie zawodzi

Starsze poradniki twierdzą, że Azure Point-to-Site VPN nie ma audytu, i było to prawdą, gdy usługa nie udostępniała żadnego rekordu na połączenie. Obecne bramy publikują diagnostyczne rekordy tunelu, więc przydatne pytanie się zmieniło: nie czy dzienniki istnieją, ale który zasób je emituje i którą kategorię włączyłeś. Blok bramy to powierzchnia konfiguracji, a powierzchnie konfiguracji rzadko służą jednocześnie jako przeglądarki dzienników. Ustawienie diagnostyczne to obiekt na zasób, więc wybrany zasób decyduje o wszystkim, co następuje.

Drugą połową zamieszania jest uwierzytelnianie. Połączenia Point-to-Site oparte na certyfikatach nie generują zdarzenia logowania na użytkownika tak jak dostawca tożsamości, więc nie ma rekordu nazwanej osoby wpisującej hasło.

Dołącz ustawienie diagnostyczne do zasobu bramy

Otwórz Monitor, następnie Diagnostic settings, i dodaj nowe ustawienie, którego celem jest sama brama sieci wirtualnej, a nie sieć wirtualna, która ją zawiera. Wybierz kategorię diagnostyczną Point-to-Site, tę o nazwie P2SDiagnosticLog, bo to ona przenosi rekordy połączeń na klienta; kategorie tunelu, trasy lub IKE dodawaj tylko dla błędów site-to-site, które obejmują. Następnie wyślij dane do obszaru roboczego Log Analytics, który kontrolujesz, z okresem przechowywania wybranym świadomie. Większość nieudanych wyszukiwań to ustawienie dołączone do niewłaściwego zasobu, a nie brakująca funkcja.

Listy kategorii różnią się w zależności od typu i generacji bramy. Jeśli brakuje kategorii Point-to-Site, brama może być starsza niż funkcja lub działać na SKU, które nigdy jej nie emituje, więc sprawdź obsługiwane kategorie, zanim zaczniesz szukać problemu z uprawnieniami. Brama bez kategorii Point-to-Site nie jest zepsuta; po prostu nie może być źródłem tego rekordu, a najbliższym zamiennikiem jest kategoria tunelu lub IKE, która rejestruje adres klienta, choć nie opisuje sesji Point-to-Site. Potwierdź listę kategorii, zanim otworzysz zgłoszenie do pomocy technicznej o brakujących dziennikach.

Czytaj rekordy w tabeli, której używa twój tryb

W starszym trybie zbierania wpisy trafiają do tabeli AzureDiagnostics, a kategoria pojawia się jako wartość kolumny; w tabelach specyficznych dla zasobu brama ma własną tabelę. W obu przypadkach odpytuj według zasobu bramy i okna wokół nieudanej próby, a następnie czytaj korelację, a nie pojedyncze wiersze:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

Zestaw kolumn zależy od trybu zbierania, więc traktuj zapytanie jako kształt, a nie skrypt. Szukasz adresu klienta, który pojawia się i następnie znika, z typem wyniku, który nie jest sukcesem.

Połącz rekord bramy z widokiem samego klienta

Dzienniki bramy opisują tunel, a nie to, dlaczego laptopowi nie udało się go zbudować. Zbierz stronę klienta w tym samym znaczniku czasu: dziennik zdarzeń Windows dla klienta RAS, dziennik połączeń macOS lub tekst błędu wyświetlony przez aplikację klienta. Rekord bramy bez odpowiadającej próby klienta wskazuje klienta; klient zgłaszający sukces, podczas gdy brama nic nie rejestruje, zwykle oznacza, że profil jest skierowany do innej bramy.

Trzymaj obie połowy w jednym zgłoszeniu. Sam dziennik bramy zachęca do błędnego wniosku, a sam dziennik klienta nie pokaże, czy pakiet kiedykolwiek dotarł.

Jeśli nigdzie nic się nie pojawia, sprawdź zegar na kliencie, zanim zwątpisz w platformę. Przekrzywione znaczniki czasu sprawiają, że korelacja zawodzi w sposób wyglądający dokładnie jak brakujące dane.

Przechowywanie, zakres i wpis w runbooku

Rekordy tunelu zawierają adresy klientów i znaczniki czasu połączeń, więc traktuj je jako dane osobowe z harmonogramem usuwania, zamiast zostawiać domyślne ustawienie platformy. Sprawdź też, czy obszar roboczy nie przyjmuje każdej kategorii z każdego zasobu w subskrypcji, ponieważ hałaśliwy obszar roboczy spowalnia korelację bardziej niż bezpośrednie czytanie dziennika klienta.

Na koniec zapisz nazwę ustawienia, obszar roboczy i wybrane kategorie w runbooku bramy. Następna osoba debugująca klienta najpierw zajrzy do bloku bramy, nic nie znajdzie i dojdzie do wniosku, że dzienniki nie istnieją.