Capturer une seule tentative VPN dans la Console de macOS

Vous cherchez le journal VPN du Mac, vous trouvez une consigne pointant vers un fichier PPP qui n'existe pas sur cette machine et vous concluez que rien n'a été enregistré. Cette conclusion est généralement fausse. L'enregistrement existe dans le journal unifié, et le fichier absent signifie que ce déploiement n'est pas de ceux qui l'écrivent, non que la tentative n'a pas été journalisée. Confondre les deux envoie les gens passer une heure à prouver une négation.

Un VPN natif, Tunnelblick et le client propre d'un fournisseur peuvent tous avoir des propriétaires de journal différents. Commencez par la vue de journal prise en charge par le client lorsqu'il en propose une, et recourez à la Console lorsque vous avez besoin des événements système ou fournisseur autour de la tentative.

Choisissez le client qui a réellement échoué

Notez la version de macOS, la version du client, le nom de la connexion et le protocole avant d'ouvrir quoi que ce soit. Ces quatre faits décident quel nom de processus vous chercherez, et c'est la première chose qu'un ingénieur de support vous demandera.

Si la connexion a été lancée depuis un élément de la barre des menus appartenant à un client fournisseur, les messages intéressants peuvent venir de ce client plutôt que du fournisseur VPN du système. Si elle a été lancée depuis le panneau VPN propre au système, le processus du fournisseur est celui à chercher. Deviner entre les deux gaspille une tentative, alors vérifiez d'abord quelle application possède la connexion.

Lancez la vue en direct avant la tentative

Ouvrez la Console et sélectionnez ce Mac sous Devices, pas un téléphone connecté ni un ancien paquet de rapport. Cliquez sur Start dans la barre d'outils pour que le flux soit en direct, puis notez l'heure avec son fuseau horaire. Utilisez un accès administrateur si la vue l'exige, et sur un Mac géré demandez cet accès au propriétaire plutôt que de le contourner.

Faites maintenant une tentative de connexion normale et notez l'échec visible. Une seule tentative compte : un second essai ajoute de nouveaux événements au même flux, et mélanger deux tentatives dans une fenêtre est la façon dont on finit par enquêter sur la mauvaise poignée de main.

Rien de tout cela ne promet qu'une trace existe déjà. La Console est une procédure de collecte, et vous créez les conditions d'une capture propre plutôt que de récupérer quelque chose d'enregistré d'avance.

Affinez par processus, pas par légende

Commencez assez large pour identifier le propriétaire, puis précisez avec le processus et les propriétés de message qui apparaissent réellement dans votre capture. Une étiquette de fournisseur citée dans un guide ancien est un indice pour une version de macOS et un protocole, pas un filtre permanent. Filtrer dessus trop tôt peut produire une fenêtre vide qui ressemble à une panne de journalisation et n'est en réalité qu'une recherche ratée. Ajoutez une condition que vous pouvez retirer, pas une qui retire la preuve.

La Console vous permet de combiner des critères, et ils se resserrent ensemble. Si les résultats disparaissent, retirez ou assouplissez la condition la plus restrictive plutôt que d'en ajouter une autre. N'afficher que l'erreur finale est une erreur courante, car l'événement qui explique l'erreur apparaît généralement plusieurs lignes plus haut.

Gardez assez de contexte pour répondre à une question

Dépliez le message pertinent et lisez ses détails, puis gardez le premier échec significatif avec les événements de connexion qui l'entourent. Une ligne isolée disant que la connexion s'est arrêtée n'apprend rien au lecteur sur la raison.

Dites précisément quelle étape l'enregistrement prouve : un fournisseur ou service local qui n'a jamais démarré, un échange avec l'extrémité distante, un rejet à l'authentification ou une plainte ultérieure de routage ou de résolution. Un message sur un processus qui démarre ne prouve pas qu'une poignée de main s'est achevée, et un avertissement de route après une connexion réussie décrit une autre panne qu'une connexion échouée.

Si le client tient son propre journal, comparez-y la même tentative au lieu de combiner un événement Console actuel avec un autre essai provenant d'un fichier en ajout seul. Les consignes sur l'ancien fichier PPP ne concernent qu'un déploiement qui produit encore ce fichier.

Partagez le plus petit extrait utile

Sélectionnez les messages pertinents et utilisez l'action Share prise en charge pour le destinataire prévu. Incluez les notes de version et de temps, puis vérifiez les noms d'hôtes internes, les identifiants de compte, les adresses et les événements sans rapport avant l'envoi. Une archive de diagnostic entière est facile à joindre et difficile à justifier ensuite.

Attendez-vous à ce que certains événements manquent avec la configuration actuelle de confidentialité ou de journalisation. Dans ce cas, utilisez la procédure de diagnostic prescrite par votre fournisseur ou administrateur, et résistez à l'envie de désactiver des protections à l'échelle du système pour collecter plus d'historique. La remise qui vaut la peine d'être préparée est petite : quel client, quel protocole, quand la tentative a eu lieu, son premier événement pertinent et ce qui a suivi.