0x или 0s? Как читать формат PSK в ipsec.secrets

Один клиент проходит аутентификацию по общему ключу, а другой отклоняет его, хотя вставленные символы выглядят одинаково с обеих сторон. Скорее всего, это одни и те же символы; разница в том, какое правило декодирования применяет к ним файл. Строка в кавычках берётся буквально, токен, начинающийся с 0x, читается как шестнадцатеричный, а токен, начинающийся с 0s, читается как Base64. Только одно из этих трёх написаний означает то, что вы задумали, поэтому исправление обычно является преобразованием, а не более надёжным паролем.

Симптом указывает на кодирование, а не на шифры

Когда две стороны хранят разные байты, согласование всё равно проходит, а доказательство терпит неудачу после него. Тогда журнал сообщает об отказе целостности или HMAC, а не о несовпадении алгоритма, потому что предложение было выбрано, а шаг аутентификации не совпал. Эта строка никогда не упоминает форму секрета.

Этап и есть подсказка. Отказ, приходящий после выбранного предложения, означает, что стороны договорились обо всём, кроме ключевого материала, тогда как «предложение не выбрано» относится к политике или наборам шифров. Проверка целостности, которая терпит неудачу при внешне правильном пароле, — видимая сторона несовпадения кодирования.

Один секрет, три способа, которыми файл может его прочитать

Для значения из четырёх байт key1 шестнадцатеричное представление и Base64 — это два перекодирования одних и тех же байт, и только ведущие символы говорят анализатору, какое из них он держит. Учётные данные swanctl следуют тому же соглашению, поэтому значение, перенесённое между двумя интерфейсами, сохраняет смысл только тогда, когда его префикс путешествует вместе с ним.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Две детали в этом блоке отнимают больше всего времени. Шестнадцатеричные цифры принимают оба регистра, поэтому 0x6b657931 и 0x6B657931 — одно и то же значение, но нечётное число символов читается молча неправильно вместо того, чтобы быть отвергнутым, что сдвигает каждый байт после места разреза. Дополнение Base64 является частью значения, поэтому строка, вставленная без завершающих знаков =, декодируется в другие байты, а не завершается громким отказом.

Профиль, который однажды декодировал значение, уже преобразовал его, поэтому повторное декодирование даёт другие байты и отказ аутентификации, который читается как неверный пароль. Кавычки — безопасное направление для всего неоднозначного, потому что содержимое остаётся буквальным, даже когда начинается с маркера кодирования.

Откуда берётся текст Base64

Экспорт профилей и порталы поставщиков часто передают ключ уже закодированным, обычно в поле данных, которое никогда не предназначалось для ручного ввода. Либо распакуйте это значение и сохраните декодированный текст в кавычках, либо оставьте его закодированным с маркером впереди. Делать половину того и половину другого — это и ломает. Оба пути работают только тогда, когда всё значение переживает копирование.

Оба направления — по одной команде, и их стоит сохранить в заявке как точную операцию, создавшую сохранённое значение. Выполните их в таком порядке:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Вставка закодированного текста как обычного — дорогая ошибка. Файл хеширует символы точно так, как они записаны, производный ключ получается примерно на треть длиннее вычисленного партнёром, и каждая попытка терпит неудачу одинаково, без предупреждения, потому что анализатор следовал данному ему правилу.

Убедитесь, какие байты каждый партнёр действительно использует

Сначала прочитайте, как демон видит соединение, а затем результат аутентификации, вместо того чтобы угадывать причину по строке ошибки. Сравнение сохранённой длины — быстрая проверка здравого смысла, потому что закодированный текст длиннее представляемых им байт. Затем убедитесь, какая строка идентичности совпала, потому что правильный секрет, записанный под неверным партнёром, терпит неудачу точно так же, как неверный. Порядок строк решает это: первое совпадение побеждает, поэтому широкая строка %any ближе к верху тихо заменяет ту конкретную строку, которую вы только что правили.

Перезагрузите, а не перезапускайте, когда файл уже верен. ipsec rereadsecrets обновляет копию демона IKE, а конфигурация swanctl загружает учётные данные своей собственной командой. Перезапуск сбрасывает каждую установленную ассоциацию и уничтожает сравнение, которое вы пытались сделать.

Ни одна из этих проверок не требует раскрытия секрета. Длина, селектор идентичности и позиция строки объясняют большинство таких отказов, прежде чем кому-либо понадобится шестнадцатеричный дамп.

Измените файл, не скрывая результат

Ограничьте файл учётной записью демона и держите живые секреты вне заявок, чатов и скриншотов, потому что вставленный ключ — это утечка, а не диагностика. Он также переживает инцидент, который его породил.

Проверьте с клиента, конфигурацией которого вы управляете, убедитесь, что аутентификация проходит, а затем убедитесь, что туннель передаёт трафик. Перезагрузка, которая исправляет рукопожатие, пока маршрутизация остаётся сломанной, — это другая проблема, и она становится видимой, как только секрет перестаёт двигаться.