WireGuard hlásí nesprávnou délku soukromého klíče: co teď?

Hlášení tvrdí, že soukromý klíč má nesprávnou délku, a tato formulace ukazuje nejprve na kódování a teprve potom na kryptografii. Klíče WireGuardu kódují 32 bajtů do base64, což dává 44 znaků včetně závěrečného zarovnání, takže hodnota jiné velikosti není klíč, ať už vypadá jakkoli náhodně. Doplnění řetězce na požadovanou délku, dokud ho parser nepřijme, vytvoří správně utvořenou hodnotu, kterou žádný protějšek nikdy nerozpozná.

Za touto chybou se skrývají dva různé úkoly: oprava textu platného klíče a nahrazení identity, kterou už nedržíte. Mají různé důsledky a jeden z nich zneplatní druhý konec.

Co parser očekává

Klíč WireGuardu je 32 bajtů klíčového materiálu v base64 se standardním zarovnáním, což dává pevný řetězec o 44 znacích. Nástroje odmítnou vše, co se nedekóduje přesně na 32 bajtů, protože podkladová křivka přijímá 32bajtový skalár a nic jiného. Veřejné i soukromé hodnoty používají stejné kódování, takže parser z formátu sám nepozná, kterou z nich jste vložili. Tato nejednoznačnost způsobuje polovinu zmatku kolem této chyby.

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

Pokud se vaše hodnota dekóduje na 32 bajtů, délka je v pořádku a stížnost přichází z jiného místa v souboru. Pokud se dekóduje na něco kratšího, máte zkrácený materiál, nikoli problém s formátováním.

Poškozené formátování, nebo špatný materiál?

Poškození formátování se hromadí na okrajích: uvozovky přidané shellem, označení jako private_key zkopírované spolu s hodnotou, zalomení řádku vložené chatovacím klientem nebo koncová mezera, která přežila vložení. Každá z těchto změn mění řetězec, aniž by měnila bajty, takže jejím odstraněním se obnoví původní identita. Porovnejte soubor s protokolem o zřízení znak po znaku, místo abyste odstraňovali interpunkci, dokud parser neztichne.

Špatný materiál je jiná situace. Heslo, klíč certifikátu nebo veřejná hodnota mohou vypadat věrohodně a dekódovat se na špatnou velikost. Žádné čištění z nich neudělá skalár, který protějšek očekává. Tento případ potřebuje novou identitu, ne úpravu.

Veřejný klíč v poli pro soukromý klíč

Nejčastější záměna je veřejná hodnota vložená do pole pro soukromý klíč, nebo naopak. Obě jsou platné base64 o 32 bajtech, takže kontrola délky projde a handshake později selže bez užitečné zprávy. Soukromý klíč je skalár, který vytváří ten veřejný, takže to můžete vyřešit odvozením veřejné hodnoty a porovnáním s tím, co protějšek autorizuje. Když odvozená hodnota neodpovídá záznamu, držíte špatnou identitu, ne překlep.

Nahradíte-li soukromý klíč klienta, aniž byste aktualizovali autorizovaný veřejný klíč na druhém konci, obnovíte stejný nesoulad, navíc se zmatkem, že soubor klienta teď vypadá vnitřně konzistentně. Změňte oba konce v jedné operaci, jinak bude příští člověk ladit špatnou polovinu.

Opravte profil a pak dokažte handshake

Jakmile se klíč dekóduje na správnou velikost a odpovídá autorizovanému páru, zbývá profil a cesta. Níže uvedené příkazy vytvoří čerstvý pár, když je potřeba, ověří dekódovanou velikost existujícího klíče a přečtou veřejnou hodnotu, kterou rozhraní skutečně používá. Nikdy nevkládejte soukromou hodnotu do tiketu ani na dekódovací web.

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 velikosti odpovídá na to, zda má materiál tvar klíče, a dotaz na trasu odpovídá na to, zda by paket vůbec dosáhl rozhraní. Řádek handshake, který zůstane prázdný i po obou kontrolách, přesouvá diagnostiku na koncový bod protějšku a povolené adresy. Přečtěte veřejný klíč rozhraní naposledy proti záznamu o zřízení, protože zastaralý uložený profil může vypadat správně, zatímco aktivní se liší].

Zaznamenejte, kterou hodnotu jste nahradili a kde leží autorizovaná kopie. Kdokoli bude tento protějšek příště upravovat, musí vědět, který konec se změnil.