Catturare un singolo tentativo VPN nella Console di macOS

Cercate il log VPN del Mac, trovate un'istruzione che punta a un file PPP che non esiste su questa macchina e concludete che non è stato registrato nulla. Questa conclusione di solito è sbagliata. Il record esiste nel log unificato, e il file mancante significa che questo deployment non è tra quelli che lo scrivono, non che il tentativo non sia stato registrato. Confondere le due cose manda le persone a passare un'ora a dimostrare un fatto negativo.

Un VPN nativo, Tunnelblick e il client di un fornitore possono avere proprietari del log diversi. Iniziate dalla vista del log supportata dal client quando ne offre una, e ricorrete alla Console quando vi servono gli eventi di sistema o del fornitore attorno al tentativo.

Scegliete il client che ha davvero fallito

Annotate la versione di macOS, la versione del client, il nome della connessione e il protocollo prima di aprire qualsiasi cosa. Questi quattro fatti decidono quale nome di processo cercherete, e sono la prima cosa che un ingegnere di supporto vi chiederà.

Se la connessione è stata avviata da una voce della barra dei menu di un client del fornitore, i messaggi interessanti possono venire da quel client e non dal provider VPN di sistema. Se è stata avviata dal pannello VPN del sistema, è il processo del provider quello da cercare. Indovinare tra i due spreca un tentativo, quindi verificate prima quale applicazione possiede la connessione.

Avviate la vista in tempo reale prima del tentativo

Aprite la Console e selezionate questo Mac in Devices, non un telefono collegato e non un vecchio pacchetto di report. Fate clic su Start nella barra degli strumenti perché il flusso sia in tempo reale, poi annotate l'ora con il suo fuso orario. Usate l'accesso amministratore se la vista lo richiede, e su un Mac gestito chiedete quell'accesso al proprietario invece di aggirarlo.

Ora fate un tentativo di connessione normale e annotate il fallimento visibile. Un solo tentativo conta: un secondo tentativo aggiunge nuovi eventi allo stesso flusso, e mescolare due tentativi in una finestra è il modo in cui si finisce per indagare sulla stretta di mano sbagliata.

Niente di tutto questo promette che una traccia esista già. La Console è una procedura di raccolta, e voi state creando le condizioni per una cattura pulita invece di recuperare qualcosa registrato in anticipo.

Restringete per processo, non per leggenda

Iniziate abbastanza ampio da identificare il proprietario, poi affinate con il processo e le proprietà dei messaggi che compaiono davvero nella vostra cattura. Un'etichetta del fornitore citata in una guida più vecchia è un indizio per una versione di macOS e un protocollo, non un filtro permanente. Filtrare su di essa troppo presto può produrre una finestra vuota che sembra un guasto della registrazione ed è in realtà una ricerca mancata. Aggiungete una condizione che potete togliere, non una che toglie la prova.

La Console vi permette di combinare criteri, e questi si restringono insieme. Se i risultati spariscono, rimuovete o allentate la condizione più restrittiva invece di aggiungerne un'altra. Mostrare solo l'errore finale è un errore comune, perché l'evento che spiega l'errore compare di solito diverse righe prima.

Conservate abbastanza contesto per rispondere a una domanda

Espandete il messaggio pertinente e leggetene i dettagli, poi conservate il primo fallimento significativo insieme agli eventi di connessione che lo circondano. Una riga isolata che dice che la connessione si è fermata non dice nulla al lettore sul perché.

Dite con precisione quale fase il record dimostra: un provider o servizio locale che non è mai partito, uno scambio con l'estremità remota, un rifiuto all'autenticazione o una successiva lamentela di routing o di risoluzione. Un messaggio su un processo che parte non è prova che una stretta di mano sia stata completata, e un avviso di rotta dopo una connessione riuscita descrive un guasto diverso da una connessione fallita.

Se il client tiene un proprio log, confrontate lì lo stesso tentativo invece di combinare un evento Console attuale con un altro tentativo da un file in sola aggiunta. Le istruzioni sul vecchio file PPP appartengono solo a un deployment che produce ancora quel file.

Condividete l'estratto utile più piccolo

Selezionate i messaggi pertinenti e usate l'azione Share supportata per il destinatario previsto. Includete le note su versione e orario, poi rivedete nomi host interni, identificatori di account, indirizzi ed eventi non correlati prima di inviare. Un intero archivio diagnostico è facile da allegare e difficile da giustificare dopo.

Aspettatevi che alcuni eventi manchino con l'attuale configurazione di privacy o di registrazione. In quel caso usate la procedura diagnostica prescritta dal fornitore o dall'amministratore, e resistete alla tentazione di disattivare protezioni a livello di sistema per raccogliere più cronologia. La consegna che vale la pena preparare è piccola: quale client, quale protocollo, quando è avvenuto il tentativo, il suo primo evento pertinente e cosa è seguito.