Як зафіксувати одну спробу VPN у macOS Console

Ви шукаєте журнал VPN на Mac, знаходите вказівку на файл PPP, якого немає на цій машині, і робите висновок, що нічого не записалося. Такий висновок зазвичай хибний. Запис є в об'єднаному журналі, а відсутній файл означає, що це розгортання не з тих, що його пишуть, а не те, що спроба не реєструвалася. Плутанина між цими двома речами відправляє людей на годину доводити заперечення.

Вбудований VPN, Tunnelblick і власний клієнт постачальника можуть мати різних власників журналу. Починайте з підтримуваного клієнтом перегляду журналу, коли він є, а до Console звертайтеся, коли потрібні системні події або події постачальника навколо спроби.

Виберіть клієнт, який справді зазнав збою

Запишіть версію macOS, версію клієнта, назву з'єднання і протокол, перш ніж щось відкривати. Ці чотири факти визначають, яку назву процесу ви шукатимете, і саме їх першим запитає інженер підтримки.

Якщо з'єднання було запущене з пункту рядка меню, що належить клієнту постачальника, цікаві повідомлення можуть надходити від того клієнта, а не від системного постачальника VPN. Якщо його запущено з власної панелі VPN системи, шукати треба процес постачальника. Здогадки між ними витрачають одну спробу, тому спершу перевірте, який застосунок володіє з'єднанням.

Увімкніть перегляд у реальному часі перед спробою

Відкрийте Console і виберіть цей Mac у розділі Devices, а не під'єднаний телефон і не старий пакет звіту. Натисніть Start на панелі інструментів, щоб потік був живим, потім запишіть час із його часовим поясом. Використовуйте доступ адміністратора, якщо перегляд цього вимагає, а на керованому Mac попросіть цей доступ у власника, а не обходьте його.

Тепер зробіть одну звичайну спробу з'єднання і запишіть видиму помилку. Одна спроба важлива: повторна додає нові події в той самий потік, і змішування двох спроб в одному вікні — це те, як люди починають досліджувати не те рукостискання.

Ніщо з цього не обіцяє, що слід уже існує. Console — це процедура збору, і ви створюєте умови для чистого запису, а не витягуєте щось заздалегідь записане.

Звужуйте за процесом, а не за переказами

Почніть достатньо широко, щоб визначити власника, потім уточнюйте за властивостями процесу й повідомлення, які справді видно у вашому записі. Мітка постачальника, цитована в старому посібнику, — це підказка для однієї версії macOS і одного протоколу, а не постійний фільтр. Занадто раннє фільтрування за нею може дати порожнє вікно, яке виглядає як збій журналювання, а насправді є промахом пошуку. Додайте умову, яку можна зняти, а не ту, що прибирає докази.

Console дозволяє поєднувати критерії, і вони звужують разом. Якщо результати зникають, зніміть або послабте найсуворішу умову, а не додавайте ще одну. Показувати лише кінцеву помилку — поширена помилка, боподія, яка пояснює помилку, зазвичай з'являється на кілька рядків раніше.

Збережіть достатньо контексту, щоб відповісти на одне питання

Розгорніть потрібне повідомлення і прочитайте його подробиці, потім збережіть першу значущу помилку разом з подіями з'єднання навколо неї. Окремий рядок про те, що з'єднання зупинилося, нічого не каже читачеві про причину.

Скажіть точно, який етап доводить запис: локальний постачальник або служба, які так і не запустилися, обмін з віддаленим боком, відмова під час автентифікації або пізніша скарга на маршрутизацію чи розв'язання імен. Повідомлення про запуск процесу не доводить, що рукостискання завершилося, а попередження про маршрут після успішного з'єднання описує іншу несправність, ніж невдале з'єднання.

Якщо клієнт веде власний журнал, порівняйте ту саму спробу там, замість того щоб поєднувати поточну подію Console з іншим повтором із файлу, який лише дописується. Старі вказівки щодо файлу PPP стосуються лише розгортання, яке досі створює цей файл.

Поділіться найменшим корисним фрагментом

Виберіть потрібні повідомлення і використайте підтримувану дію Share для передбаченого одержувача. Додайте нотатки про версію й час, потім перед надсиланням перегляньте внутрішні імена хостів, ідентифікатори облікових записів, адреси та не пов'язані події. Цілий діагностичний архів легко прикріпити й важко потім обґрунтувати.

Очікуйте, що деяких подій не буде за поточних налаштувань конфіденційності або журналювання. У такому разі використайте діагностичну процедуру, приписану вашим постачальником або адміністратором, і опирайтеся бажанню вимкнути загальносистемні захисти, щоб зібрати більше історії. Передача, яку варто підготувати, невелика: який клієнт, який протокол, коли сталася спроба, її перша значуща подія і що було далі.