Отредактировать журнал VPN, не потеряв важные улики
Уберите всё, что можно использовать, сохраните одну метку на каждое реальное значение и сохраните порядок и версии. Отредактированный журнал должен по-прежнему позволять постороннему проследить сбой.
Вы вставляете журнал в ветку поддержки, ответ указывает, что в нём есть ваш закрытый ключ, а вставка остаётся навсегда. Более тихий сбой проявляется позже, когда каждый адрес стал X, и файл больше не доказывает, что клиент и сервер были разными хостами. Проход редактирования убирает то, что даёт доступ или называет человека, и сохраняет то, что объясняет сбой. Это преобразование по правилам, а не удаление с помощью поля поиска.
Редактирование — это преобразование, а не удаление
Журнал несёт не только значения, но и структуру: этот адрес говорил с тем, в это время, и рукопожатие остановилось на этом шаге. Именно значения делают файл опасным для публикации. Именно структура делает его вообще достойным публикации.
Удаление целых строк убирает и то и другое сразу, поэтому урезанный журнал часто ничего не отвечает. Сведение каждого значения в один токен отказывает иначе, потому что два разных узла становятся одним действующим лицом. Оба прохода могут выглядеть аккуратно и при этом уничтожить доказательство. Проверка в том, может ли читатель, никогда не видевший вашу сеть, проследить последовательность и прийти к тому же выводу, что и вы.
Сначала фрагмент, потом вычищение
Вырежьте участок вокруг сбоя, прежде чем что-либо править. Меньший фрагмент проще проверить, и он реже несёт то, о чём вы забыли, что это было в файле. Храните нетронутый оригинал в защищённом месте, пока вопрос не закрыт. Редактирование необратимо, и только исходный файл позволяет ответить на последующий вопрос.
Прочитайте фрагмент как обычный текст, прежде чем доверять команде экспорта в том, что она убрала приватные части: экспортёры сводят и ротируют поля, а не очищают их. Режимы debug и verbose — самое вероятное место для блока ключа или встроенных учётных данных. Откройте файл в редакторе, который показывает полные строки, а не в просмотрщике, который переносит и скрывает хвост.
Что должно уйти и в каком порядке
Начните с материала, дающего доступ, потому что пропуск здесь заканчивает упражнение: блоки закрытых ключей, пароли, предварительно общие ключи, токены API, коды восстановления. Они не просто идентифицируют; их может использовать любой, кто читает ветку. Проход, который убирает всё остальное и оставляет один из них, провален.
Затем слой личности: имена пользователей, субъекты и серийные номера сертификатов, идентификаторы учётных записей и любой путь, содержащий имя человека. Ничего из этого не годится само по себе, но вместе это называет человека, а публичной ветке это не нужно.
Затем слой топологии, и здесь вступает суждение. Публичные адреса, внутренние диапазоны и имена хостов можно заменять, когда их раскрытие не служит никакой диагностической цели, а стабильные метки лучше пустых мест. Порядок важен, потому что ранние слои абсолютны, а последний — решение. Работа в этом порядке ещё и не даст вам потратить час на имена хостов, пока блок ключа стоит в сороковой строке.
| Original kind | Replace with | Keep |
|---|---|---|
| Client address | CLIENT_A | Which side initiated |
| Server address | SERVER_B | Port and protocol |
| Username | USER_1 | The failure that mentions it |
| Hostname | HOST_1 | Resolution order |
Не разрушайте связи
Дайте каждому реальному значению один заполнитель и используйте его заново каждый раз, когда это значение появляется. Если два адреса были разными, они должны остаться разными после прохода, иначе читатель решит, что клиент подключился сам к себе. Согласованность — это весь механизм: читатель узнаёт соответствие, видя, как метка повторяется. Один повторно использованный токен для двух действующих лиц — самый быстрый способ сделать журнал нечитаемым.
Порядок и время — часть той же структуры. Сохраняйте последовательность нетронутой, и если вы сдвигаете отметки времени, сдвигайте все на одну и ту же величину и скажите это одной строкой. Смешивать изменённое и настоящее время хуже, чем удалить его: тогда пробелы выглядят доказательством того, чего не было.
Порты, протокол и направление остаются как есть. Заполнитель на адресе не требует заполнителя на порте.
Сохраните вопрос, на который должен ответить журнал
Запишите поля, которые нужны помощнику, прежде чем начать редактирование: точный, несекретный текст ошибки, версии клиента и сервера, транспорт и то, какая сторона начала попытку. Именно они позволяют постороннему узнать сбой. Список рядом превращает проход в проверку, а не в надежду.
Когда отправляете файл, добавьте строку о том, что было заменено, чтобы никто не потратил час на диагностику хоста-заполнителя. Документация OpenVPN о журналах диагностики перечисляет поля, которые несут её журналы, и это тот список, который вы собираетесь изменить. Спросите перед отправкой дампа памяти или перехвата пакетов и используйте канал поддержки, который можете проверить. Эти артефакты содержат гораздо больше, чем текстовый журнал, и часть этого не вам публиковать.
Прочитайте готовый фрагмент один раз от первой до последней строки, включая начало и конец. Скриншоты заслуживают большего недоверия, чем текст, потому что несут другие окна, имена учётных записей и пункты меню.