WireGuard zgłasza nieprawidłową długość klucza prywatnego: co teraz?

Komunikat mówi, że klucz prywatny ma nieprawidłową długość, a to sformułowanie wskazuje najpierw na kodowanie, a dopiero potem na kryptografię. Klucze WireGuard kodują 32 bajty jako base64, co daje 44 znaki wraz z końcowym dopełnieniem, więc wartość innego rozmiaru nie jest kluczem, choćby wyglądała najbardziej losowo. Dopełnianie ciągu, aż parser go zaakceptuje, tworzy poprawnie zbudowaną wartość, której żaden peer nigdy nie rozpozna.

Za tym błędem kryją się dwa różne zadania: naprawa tekstu prawidłowego klucza i zastąpienie tożsamości, której już nie posiadasz. Mają różne skutki, a jedno z nich unieważnia drugi koniec.

Czego oczekuje parser

Klucz WireGuard to 32 bajty materiału klucza w base64 ze standardowym dopełnieniem, co daje stały ciąg 44 znaków. Narzędzia odrzucają wszystko, co nie dekoduje się dokładnie do 32 bajtów, ponieważ leżąca u podstaw krzywa przyjmuje 32-bajtowy skalar i nic więcej. Wartości publiczne i prywatne używają tego samego kodowania, więc parser nie potrafi rozpoznać po samym formacie, którą z nich wkleiłeś. Ta niejednoznaczność odpowiada za połowę zamieszania wokół tego błędu.

wg genkey | tee private.key | wg pubkey > public.key
base64 -d private.key | wc -c
wc -c private.key
wg show wg0 public-key

Jeśli twoja wartość dekoduje się do 32 bajtów, długość jest prawidłowa, a skarga pochodzi z innego miejsca w pliku. Jeśli dekoduje się do czegoś krótszego, masz obcięty materiał, a nie problem z formatowaniem.

Uszkodzenie formatowania czy zły materiał?

Uszkodzenia formatowania gromadzą się na krawędziach: cudzysłowy dodane przez powłokę, etykieta taka jak private_key skopiowana razem z wartością, znak nowej linii wstawiony przez klienta czatu albo końcowa spacja, która przetrwała wklejenie. Każda z tych zmian zmienia ciąg bez zmiany bajtów, więc usunięcie jej przywraca pierwotną tożsamość. Porównaj plik z rejestrem zaopatrzenia znak po znaku, zamiast usuwać interpunkcję, dopóki parser nie ucichnie.

Zły materiał to inna sytuacja. Hasło, klucz certyfikatu lub wartość publiczna mogą wyglądać wiarygodnie i dekodować się do niewłaściwego rozmiaru. Żadne czyszczenie nie zamieni któregokolwiek z nich w skalar, którego oczekuje peer. Ten przypadek wymaga nowej tożsamości, a nie edycji.

Klucz publiczny w polu prywatnym

Najczęstsze nieporozumienie to wartość publiczna wklejona w pole prywatne albo odwrotnie. Obie są prawidłowym base64 o długości 32 bajtów, więc kontrola długości przechodzi, a uzgadnianie później zawodzi bez użytecznego komunikatu. Klucz prywatny to skalar, który tworzy publiczny, więc można to rozstrzygnąć, wyprowadzając wartość publiczną i porównując ją z tym, co autoryzuje peer. Gdy wyprowadzona wartość nie zgadza się z rejestrem, trzymasz niewłaściwą tożsamość, a nie literówkę.

Zastąpienie klucza prywatnego klienta bez aktualizacji autoryzowanego klucza publicznego na drugim końcu odtwarza tę samą niezgodność, z dodatkowym zamieszaniem, że plik klienta wygląda teraz spójnie. Zmień oba końce w jednej operacji, inaczej następna osoba będzie debugować niewłaściwą połowę.

Napraw profil, a potem udowodnij uzgadnianie

Gdy klucz dekoduje się do właściwego rozmiaru i pasuje do autoryzowanej pary, pozostaje profil i trasa. Poniższe polecenia generują świeżą parę, gdy jest potrzebna, weryfikują zdekodowany rozmiar istniejącego klucza i odczytują wartość publiczną, której interfejs faktycznie używa. Nigdy nie wklejaj wartości prywatnej do zgłoszenia ani na stronę dekodującą.

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

Kontrola rozmiaru odpowiada na pytanie, czy materiał ma kształt klucza, a zapytanie o trasę odpowiada, czy pakiet kiedykolwiek dotrze do interfejsu. Wiersz uzgadniania, który pozostaje pusty po przejściu obu kontroli, przenosi diagnozę do punktu końcowego peera i dozwolonych adresów. Odczytaj klucz publiczny interfejsu względem rejestru zaopatrzenia jeszcze raz, ponieważ nieaktualny zapisany profil może wyglądać poprawnie, podczas gdy aktywny się różni].

Zapisz, którą wartość zastąpiłeś i gdzie znajduje się autoryzowana kopia. Kto następny dotknie tego peera, musi wiedzieć, który koniec się zmienił.