WireGuard сообщает, что длина закрытого ключа неверна: что делать?
Ключ из 32 байт в base64 занимает 44 символа. Решите, повреждён ли текст или неверна личность, прежде чем что-то создавать заново.
Сообщение говорит, что у закрытого ключа неверная длина, и эта формулировка указывает сначала на кодировку и лишь затем на криптографию. Ключи WireGuard кодируют 32 байта в base64, что даёт 44 символа вместе с завершающим заполнением, поэтому значение другого размера не является ключом, как бы случайно оно ни выглядело. Дополнение строки до тех пор, пока анализатор её не примет, создаёт правильно оформленное значение, которое ни один партнёр никогда не узнает.
За этой ошибкой скрываются две разные задачи: починить текст действительного ключа и заменить личность, которой у вас больше нет. У них разные последствия, и одна из них делает недействительным другой конец.
Чего ожидает анализатор
Ключ WireGuard — это 32 байта ключевого материала в base64 со стандартным заполнением, что даёт фиксированную строку из 44 символов. Инструменты отклоняют всё, что не декодируется ровно в 32 байта, потому что лежащая в основе кривая принимает 32-байтовый скаляр и ничего больше. Открытые и закрытые значения используют одну и ту же кодировку, поэтому анализатор не может по одному формату понять, какое из них вы вставили. Именно эта неоднозначность создаёт половину путаницы вокруг этой ошибки.
wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key
Если ваше значение декодируется в 32 байта, длина верна, и жалоба приходит из другого места файла. Если оно декодируется во что-то более короткое, у вас обрезанный материал, а не проблема форматирования.
Повреждение форматирования или неверный материал?
Повреждения форматирования скапливаются по краям: кавычки, добавленные оболочкой, метка вроде private_key, скопированная вместе со значением, перенос строки, вставленный клиентом чата, или завершающий пробел, переживший вставку. Каждое из этих изменений меняет строку, не меняя байты, поэтому их удаление восстанавливает исходную личность. Сравнивайте файл с записью о провижининге символ за символом, а не удаляйте пунктуацию, пока анализатор не замолчит.
Неверный материал — другая ситуация. Пароль, ключ сертификата или открытое значение могут выглядеть правдоподобно и декодироваться в неверный размер. Никакая очистка не превращает любой из них в скаляр, которого ждёт партнёр. Этот случай требует новой личности, а не правки.
Открытый ключ в закрытом поле
Самая частая путаница — открытое значение, вставленное в закрытое поле, или наоборот. Оба являются допустимым base64 из 32 байт, поэтому проверка длины проходит, а рукопожатие позже терпит неудачу без полезного сообщения. Закрытый ключ — это скаляр, порождающий открытый, поэтому вопрос можно решить, выведя открытое значение и сравнив его с тем, что авторизует партнёр. Когда выведенное значение не совпадает с записью, у вас неверная личность, а не опечатка.
Замена закрытого ключа клиента без обновления авторизованного открытого ключа на другом конце снова создаёт то же несоответствие, с дополнительной путаницей: файл самого клиента теперь выглядит самосогласованным. Меняйте оба конца одной операцией, иначе следующий человек будет отлаживать не ту половину.
Почините профиль, затем докажите рукопожатие
Когда ключ декодируется в правильный размер и совпадает с авторизованной парой, остаются профиль и маршрут. Приведённые ниже команды создают свежую пару при необходимости, проверяют декодированный размер существующего ключа и читают открытое значение, которое интерфейс действительно использует. Никогда не вставляйте закрытое значение в тикет или на сайт декодирования.
wg genkey | tee new.key | wg pubkey > new.pub
base64 -d private.key | wc -c
ip route get 10.60.9.5
wg show wg0 latest-handshakes
Проверка размера отвечает, имеет ли материал форму ключа, а запрос маршрута отвечает, дойдёт ли пакет до интерфейса. Строка рукопожатия, которая остаётся пустой после обеих проверок, переносит диагностику на конечную точку партнёра и разрешённые адреса. Прочитайте открытый ключ интерфейса против записи о провижининге ещё раз, потому что устаревший сохранённый профиль может выглядеть правильным, тогда как активный отличается].
Запишите, какое значение вы заменили и где находится авторизованная копия. Следующий, кто тронет этого партнёра, должен знать, какой конец изменился.