Предварительно общий ключ IPsec: байты за введённой строкой

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

Что шлюз делает со строкой

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

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

Откуда берутся лишние байты

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

Сравнивайте инструментом, который показывает байты, а не глифы. printf '%s' "$PSK" | xxd | tail -2 печатает конец значения в шестнадцатеричном виде, где случайный 0a или 20 очевиден. Сделайте это на обоих концах и сравните два дампа рядом. Делайте это на сгенерированном тестовом материале, а не на производственном секрете, который потом останется в истории оболочки.

Кодирование — не шифрование

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

Словарь IPSec от Apple — полезный пример того, что тип имеет значение: он документирует SharedSecret как данные для метода аутентификации общим секретом в полезных нагрузках L2TP и Cisco IPsec. Это конкретное свойство в конкретной полезной нагрузке, а не общее текстовое поле, которое можно повторно использовать для другого протокола, случайно запрашивающего секрет.

Заявленный предел относится к одной комбинации

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

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

Исправляйте представление, а не стойкость

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

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