WireGuard наводи да је дужина приватног кључа погрешна: шта сада?

Порука каже да приватни кључ има погрешну дужину, а та формулација најпре упућује на кодирање, а тек потом на криптографију. 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 бајта, дужина је у реду и жалба долази са неког другог места у датотеци. Ако се декодира у нешто краће, имате скраћен материјал, а не проблем са форматирањем.

Оштећено форматирање или погрешан материјал?

Оштећења форматирања скупљају се на ивицама: наводници које је додао shell, ознака попут private_key копирана заједно са вредношћу, прелом реда који је уметнуо chat клијент или завршни размак који је преживео лепљење. Свака од тих промена мења низ без промене бајтова, па уклањање враћа изворни идентитет. Упоредите датотеку са евиденцијом о обезбеђивању знак по знак уместо да уклањате интерпункцију док парсер не утихне.

Погрешан материјал је друга ситуација. Лозинка, кључ сертификата или јавна вредност могу изгледати уверљиво и декодирати се у погрешну величину. Ниједно чишћење не претвара ниједан од њих у скалар који партнер очекује. Тај случај захтева нови идентитет, а не измену.

Јавни кључ у приватном пољу

Најчешћа забуна је јавна вредност залепљена у приватно поље, или обрнуто. Обе су важећи 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

Провера величине одговара на питање да ли материјал има облик кључа, а упит о рути на питање да ли би пакет икада стигао до интерфејса. Ред руковања који остане празан након обе провере премешта дијагнозу на крајњу тачку партнера и дозвољене адресе. Прочитајте јавни кључ интерфејса према евиденцији о обезбеђивању још једном, јер застарео сачуван профил може изгледати исправно док се активни разликује].

Запишите коју сте вредност заменили и где се налази овлашћена копија. Следећи који дотакне овог партнера мора да зна који се крај променио.