Відредагувати журнал VPN, не втративши важливі підказки

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

Редагування — це перетворення, а не видалення

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

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

Спершу фрагмент, потім чищення

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

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

Що має піти і в якому порядку

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

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

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

Не руйнуйте зв'язки

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

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

Порти, протокол і напрямок залишаються як є. Заповнювач на адресі не потребує заповнювача на порту.

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

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

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

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