Przechwytywanie jednej próby VPN w macOS Console

Szukasz dziennika VPN na Macu, znajdujesz instrukcję wskazującą plik PPP, którego nie ma na tej maszynie, i dochodzisz do wniosku, że nic nie zostało zapisane. Ten wniosek jest zwykle błędny. Zapis istnieje w dzienniku zunifikowanym, a brakujący plik oznacza, że to wdrożenie nie jest tym, które go tworzy, a nie że próba nie została zarejestrowana. Mylenie tych dwóch rzeczy wysyła ludzi na godzinę udowadniania twierdzenia negatywnego.

Wbudowany VPN, Tunnelblick i własny klient dostawcy mogą mieć różnych właścicieli dziennika. Zacznij od obsługiwanego widoku dziennika klienta, jeśli jest dostępny, a po Console sięgnij wtedy, gdy potrzebujesz zdarzeń systemowych lub zdarzeń dostawcy wokół próby.

Wybierz klienta, który naprawdę zawiódł

Zapisz wersję macOS, wersję klienta, nazwę połączenia i protokół, zanim cokolwiek otworzysz. Te cztery fakty decydują, jakiej nazwy procesu będziesz szukać, i o nie inżynier wsparcia zapyta cię w pierwszej kolejności.

Jeśli połączenie zostało uruchomione z elementu paska menu należącego do klienta dostawcy, ciekawe komunikaty mogą pochodzić z tego klienta, a nie od systemowego dostawcy VPN. Jeśli uruchomiono je z własnego panelu VPN systemu, szukać trzeba procesu dostawcy. Zgadywanie między nimi marnuje jedną próbę, więc najpierw sprawdź, która aplikacja jest właścicielem połączenia.

Uruchom widok na żywo przed próbą

Otwórz Console i wybierz tego Maca w sekcji Devices, a nie podłączony telefon i nie stary pakiet raportu. Kliknij Start na pasku narzędzi, aby strumień był na żywo, a następnie zanotuj czas wraz ze strefą czasową. Jeśli widok tego wymaga, użyj dostępu administratora, a na zarządzanym Macu poproś właściciela o ten dostęp, zamiast go obchodzić.

Teraz wykonaj jedną normalną próbę połączenia i zanotuj widoczny błąd. Jedna próba ma znaczenie: druga ponowna próba dopisuje nowe zdarzenia do tego samego strumienia, a mieszanie dwóch prób w jednym oknie to właśnie sposób, w jaki ludzie zaczynają badać niewłaściwy uścisk dłoni.

Nic z tego nie obiecuje, że ślad już istnieje. Console to procedura zbierania, a ty tworzysz warunki do czystego zapisu, zamiast odzyskiwać coś, co zostało nagrane wcześniej.

Zawęź według procesu, a nie według podań

Zacznij wystarczająco szeroko, aby zidentyfikować właściciela, a potem doprecyzuj właściwościami procesu i komunikatu, które naprawdę pojawiają się w twoim zapisie. Etykieta dostawcy cytowana w starszym poradniku jest wskazówką dla jednej wersji macOS i jednego protokołu, a nie stałym filtrem. Zbyt wczesne filtrowanie według niej może dać puste okno, które wygląda jak awaria rejestrowania, a w rzeczywistości jest chybionym wyszukiwaniem. Dodaj warunek, który możesz usunąć, a nie taki, który usuwa dowody.

Console pozwala łączyć kryteria i zawężają się one razem. Jeśli wyniki znikną, usuń albo poluzuj najbardziej restrykcyjny warunek, zamiast dodawać kolejny. Pokazywanie tylko końcowego błędu to częsty błąd, ponieważzdarzenie wyjaśniające błąd zwykle pojawia się kilka wierszy wcześniej.

Zachowaj dość kontekstu, aby odpowiedzieć na jedno pytanie

Rozwiń odpowiedni komunikat i przeczytaj jego szczegóły, a następnie zachowaj pierwszy znaczący błąd razem z otaczającymi go zdarzeniami połączenia. Pojedynczy wiersz mówiący, że połączenie się zatrzymało, nie mówi czytelnikowi nic o przyczynie.

Powiedz dokładnie, który etap potwierdza zapis: lokalny dostawca lub usługa, która nigdy nie wystartowała, wymiana z drugą stroną, odrzucenie przy uwierzytelnianiu albo późniejsza skarga na routing lub resolver. Komunikat o uruchomieniu procesu nie jest dowodem ukończenia uścisku dłoni, a ostrzeżenie o trasie po udanym połączeniu opisuje inną usterkę niż połączenie nieudane.

Jeśli klient prowadzi własny dziennik, porównaj tę samą próbę tam, zamiast łączyć bieżące zdarzenie Console z inną ponowną próbą z pliku tylko dopisywanego. Stare instrukcje dotyczące pliku PPP odnoszą się wyłącznie do wdrożenia, które nadal ten plik tworzy.

Udostępnij najmniejszy użyteczny fragment

Zaznacz odpowiednie komunikaty i użyj obsługiwanej akcji Share wobec zamierzonego odbiorcy. Dołącz notatki o wersji i czasie, a następnie przed wysłaniem przejrzyj wewnętrzne nazwy hostów, identyfikatory kont, adresy i niepowiązane zdarzenia. Całe archiwum diagnostyczne łatwo załączyć i trudno później uzasadnić.

Spodziewaj się, że część zdarzeń będzie nieobecna przy bieżącej konfiguracji prywatności lub rejestrowania. W takim przypadku użyj procedury diagnostycznej zalecanej przez dostawcę lub administratora i oprzyj się pokusie wyłączenia ogólnosystemowych zabezpieczeń, aby zebrać więcej historii. Przekazanie, które warto przygotować, jest małe: który klient, który protokół, kiedy doszło do próby, pierwsze istotne zdarzenie i co nastąpiło potem.