Fånga ett enda VPN-försök i macOS Console

Du letar efter Mac-VPN-loggen, hittar en instruktion som pekar på en PPP-fil som inte finns på den här maskinen och drar slutsatsen att ingenting registrerades. Den slutsatsen är oftast fel. Posten finns i den enhetliga loggen, och den saknade filen betyder att den här installationen inte är en som skriver den, inte att försöket gick ologgat. Att blanda ihop de två skickar folk att i en timme bevisa en negation.

En inbyggd VPN, Tunnelblick och leverantörens egen klient kan ha olika loggägare. Börja med klientens loggvy om den erbjuder en, och ta till Console när du behöver systemets eller leverantörens händelser kring försöket.

Välj den klient som faktiskt misslyckades

Skriv ned macOS-versionen, klientversionen, anslutningens namn och protokollet innan du öppnar något. De fyra fakta avgör vilket processnamn du ska söka efter, och de är det första en supporttekniker frågar efter.

Om anslutningen startades från ett menyradsobjekt som tillhör en leverantörsklient kan de intressanta meddelandena komma från den klienten i stället för från systemets VPN-leverantör. Startades den från systemets egen VPN-panel är det leverantörsprocessen du ska leta efter. Att gissa mellan dem slösar ett försök, så kontrollera först vilket program som äger anslutningen.

Starta livevyn före försöket

Öppna Console och välj den här Macen under Devices, inte en ansluten telefon och inte ett gammalt rapportpaket. Klicka på Start i verktygsfältet så att strömmen är live och anteckna sedan tiden med tidszon. Använd administratörsåtkomst om vyn kräver det, och på en hanterad Mac ber du ägaren om den åtkomsten i stället för att gå runt den.

Gör nu ett normalt anslutningsförsök och anteckna det synliga felet. Ett försök spelar roll: ett andra nytt försök lägger till nya händelser i samma ström, och att blanda två försök i ett fönster är hur folk hamnar med att undersöka fel handskakning.

Inget av detta lovar att ett spår redan finns. Console är en insamlingsprocedur, och du skapar förutsättningarna för en ren fångst i stället för att hämta något som redan spelats in.

Begränsa efter process i stället för efter folktro

Börja tillräckligt brett för att identifiera ägaren och förfina sedan med de process- och meddelandeegenskaper som faktiskt syns i din fångst. En leverantörsetikett som citeras i en äldre guide är en ledtråd för en macOS-version och ett protokoll, inte ett permanent filter. Att filtrera på den för tidigt kan ge ett tomt fönster som ser ut som ett loggningsfel och egentligen är en missad sökning. Lägg till ett villkor du kan ta bort, inte ett som tar bort bevisen.

Console låter dig kombinera kriterier, och de begränsar tillsammans. Om resultaten försvinner tar du bort eller lossar det mest restriktiva villkoret i stället för att lägga till ett till. Att bara visa det sista felet är ett vanligt misstag, eftersomhändelsen som förklarar felet oftast dyker upp flera rader tidigare.

Behåll tillräckligt med sammanhang för att svara på en fråga

Expandera det relevanta meddelandet och läs dess detaljer, behåll sedan det första meningsfulla felet tillsammans med anslutningshändelserna runt det. En isolerad rad som säger att anslutningen stoppades säger ingenting till läsaren om varför.

Säg exakt vilket steg posten bevisar: en lokal leverantör eller tjänst som aldrig startade, ett utbyte med den andra sidan, en avvisning vid autentisering eller ett senare klagomål på routing eller namnuppslagning. Ett meddelande om att en process startar är inte bevis för att en handskakning slutfördes, och en routvarning efter en lyckad anslutning beskriver ett annat fel än en misslyckad anslutning.

Om klienten har en egen logg jämför du samma försök där i stället för att kombinera en aktuell Console-händelse med ett annat nytt försök från en fil som bara läggs till i slutet. Gamla PPP-filinstruktioner hör bara till en installation som fortfarande producerar den filen.

Dela det minsta användbara utdraget

Markera de relevanta meddelandena och använd den stödda Share-åtgärden för den avsedda mottagaren. Ta med versions- och tidsanteckningarna och granska sedan interna värdnamn, kontoidentifierare, adresser och orelaterade händelser innan du skickar. Ett helt diagnostikarkiv är lätt att bifoga och svårt att motivera senare.

Räkna med att vissa händelser saknas under den aktuella sekretess- eller loggkonfigurationen. Använd i så fall den diagnostiska procedur som din leverantör eller administratör föreskriver, och stå emot lusten att stänga av systemomfattande skydd för att samla mer historik. Överlämningen som är värd att ta fram är liten: vilken klient, vilket protokoll, när försöket skedde, dess första relevanta händelse och vad som följde.