WireGuard dice che la lunghezza della chiave privata è sbagliata: e ora?

Il messaggio dice che la chiave privata ha una lunghezza sbagliata, e questa formulazione punta prima alla codifica e solo dopo alla crittografia. Le chiavi di WireGuard codificano 32 byte in base64, il che produce 44 caratteri incluso un riempimento finale, quindi un valore di un’altra dimensione non è una chiave per quanto sembri casuale. Riempire la stringa finché l’analizzatore non la accetta produce un valore ben formato che nessun peer riconoscerà mai.

Dietro questo errore si nascondono due compiti diversi: riparare il testo di una chiave valida e sostituire un’identità che non possiedi più. Hanno conseguenze diverse, e una delle due invalida l’altro estremo.

Che cosa si aspetta l’analizzatore

Una chiave di WireGuard sono 32 byte di materiale di chiave in base64 con riempimento standard, il che dà una stringa fissa di 44 caratteri. Gli strumenti rifiutano tutto ciò che non si decodifica esattamente in 32 byte, perché la curva sottostante prende uno scalare di 32 byte e nient’altro. I valori pubblici e privati usano la stessa codifica, quindi l’analizzatore non può capire dal solo formato quale dei due hai incollato. È questa ambiguità a causare metà della confusione attorno a questo errore.

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

Se il tuo valore si decodifica in 32 byte, la lunghezza è corretta e la lamentela arriva da un altro punto del file. Se si decodifica in qualcosa di più corto, hai materiale troncato e non un problema di formattazione.

Danno di formattazione o materiale sbagliato?

I danni di formattazione si concentrano sui bordi: virgolette aggiunte da una shell, un’etichetta come private_key copiata insieme al valore, un’interruzione di riga inserita da un client di chat o uno spazio finale sopravvissuto all’incollaggio. Ognuna di queste modifiche cambia la stringa senza cambiare i byte, quindi rimuoverla ripristina l’identità originale. Confronta il file con il registro di provisioning carattere per carattere invece di togliere la punteggiatura finché l’analizzatore non tace.

Il materiale sbagliato è un’altra situazione. Una password, una chiave di certificato o un valore pubblico possono sembrare plausibili e decodificarsi nella dimensione sbagliata. Nessuna pulizia li trasforma nello scalare che il peer si aspetta. Quel caso richiede una nuova identità, non una modifica.

Una chiave pubblica nel campo privato

La confusione più comune è un valore pubblico incollato nel campo privato, o il contrario. Entrambi sono base64 validi da 32 byte, quindi il controllo di lunghezza passa e l’handshake fallisce più tardi senza un messaggio utile. Una chiave privata è lo scalare che produce quella pubblica, quindi puoi risolverla derivando il valore pubblico e confrontandolo con ciò che il peer autorizza. Quando il valore derivato non corrisponde al registro, stai tenendo l’identità sbagliata e non un refuso.

Sostituire la chiave privata del client senza aggiornare la chiave pubblica autorizzata all’altro estremo ricrea lo stesso disallineamento, con l’ulteriore confusione che il file del client ora sembra coerente con sé stesso. Cambia entrambi gli estremi in un’unica operazione, altrimenti la persona successiva farà debug sulla metà sbagliata.

Ripara il profilo, poi dimostra l’handshake

Una volta che la chiave si decodifica nella dimensione giusta e corrisponde alla coppia autorizzata, il lavoro che resta è il profilo e il percorso. I comandi seguenti generano una coppia nuova quando serve, verificano la dimensione decodificata di una chiave esistente e leggono il valore pubblico che l’interfaccia usa realmente. Non incollare mai un valore privato in un ticket o su un sito di decodifica.

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

Il controllo di dimensione risponde alla domanda se il materiale abbia la forma di una chiave, e la query di rotta risponde se un pacchetto raggiungerebbe mai l’interfaccia. Una riga di handshake che resta vuota dopo che entrambi i controlli sono passati sposta la diagnosi verso l’endpoint del peer e gli indirizzi consentiti. Rileggi la chiave pubblica dell’interfaccia rispetto al registro di provisioning un’ultima volta, perché un profilo salvato obsoleto può sembrare corretto mentre quello attivo differisce].

Annota quale valore hai sostituito e dove si trova la copia autorizzata. Chi toccherà questo peer in seguito deve sapere quale estremo è cambiato.