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

Проверката на размера отговаря дали материалът има форма на ключ, а заявката за маршрут отговаря дали пакет някога ще стигне до интерфейса. Ред за ръкостискане, който остава празен след двете проверки, премества диагностиката към крайната точка на партньора и разрешените адреси. Прочетете публичния ключ на интерфейса срещу записа за осигуряване още веднъж, защото остарял запазен профил може да изглежда правилен, докато активният се различава].

Запишете коя стойност сте заменили и къде е разрешеното копие. Следващият, който докосне този партньор, трябва да знае кой край се е променил.

Подобни статии