Chiave privata qui, chiave pubblica là: le chiavi di WireGuard
La chiave privata resta sul tuo dispositivo; la voce del peer contiene la chiave pubblica dell’altro lato. Condividi solo la metà pubblica e dai a ogni dispositivo la sua identità.
La maggior parte degli errori di WireGuard messi insieme a mano si riduce a quale chiave è finita dove. La sezione dell’interfaccia porta la chiave privata del dispositivo che stai configurando, mentre una sezione peer porta la chiave pubblica della macchina dall’altra parte. Scambiare queste metà, o incollare quella sbagliata, produce un handshake che non si completa mai e un registro che non nomina mai una chiave. Esegui i quattro controlli qui sotto in ordine prima di toccare AllowedIPs o DNS.
Due chiavi, due direzioni
Una chiave privata appartiene esattamente a un dispositivo e resta nella sezione dell’interfaccia di quel dispositivo. La sua metà pubblica è ciò che ogni altro peer deve avere per riconoscere il dispositivo, e gli strumenti la derivano invece di inventarla. Sul server, la chiave pubblica del tuo dispositivo compare come voce di peer; sul tuo dispositivo, quel ruolo spetta alla chiave pubblica del server. Leggere ad alta voce una configurazione con questi termini intercetta la maggior parte delle confusioni prima che arrivino a un handshake.
Il comando wg stampa ciò che l’interfaccia locale sta davvero usando, comprese entrambe le chiavi pubbliche. Per questo è il modo più rapido per separare un errore di configurazione da un problema di connettività:
wg show
wg show interfaces
Il primo output elenca ogni peer con la sua chiave pubblica, l’endpoint usato l’ultima volta e l’età del suo ultimo handshake. Un’età di handshake «mai» da un lato e recente dall’altro indica una chiave che solo un estremo ha accettato. Il secondo comando nomina le interfacce che puoi esaminare più a fondo.
Cosa condividere e cosa non condividere mai
Una chiave pubblica è fatta per essere consegnata, anche se continua a identificare un rapporto tra dispositivi, per questo inviarla all’amministratore che l’ha chiesta è diverso dal pubblicarla. Una chiave privata non lascia mai il dispositivo che l’ha generata. Un profilo esportato o un codice QR contiene l’intera configurazione, compresa quella chiave privata, quindi nessuno dei due è sicuro da far circolare, e nascondere il testo dentro un’immagine non cambia nulla. Le chiavi precondivise sono facoltative e altrettanto segrete, ed entrambi gli estremi devono portare lo stesso valore, altrimenti l’handshake si ferma in quella fase.
Un’altra distinzione va detta chiaramente: un endpoint è un indirizzo e una porta, mai una chiave. Incollare una chiave pubblica nel campo dell’endpoint, o un indirizzo in un campo chiave, produce un profilo che viene analizzato e poi non fa nulla. Gli strumenti non lo intercetteranno, perché entrambi i campi sono solo stringhe. L’avvio rapido di WireGuard mostra la catena di generazione e derivazione in una riga.
Un dispositivo, una voce di peer
Dove il servizio lo consente, ogni dispositivo dovrebbe portare la propria identità di peer. Incollare il profilo completo di un portatile su un telefono confonde quale dispositivo detiene quell’identità sul server e rende più difficile revocare un solo telefono perduto. Se una chiave privata trapela, rimuovi la vecchia autorizzazione del peer sul server e procurati un sostituto. Eliminare il file locale non rimuove la voce sul server, e una nuova chiave client non aiuta nessuno finché il server non ne conosce la metà pubblica.
Tieni la corrispondenza tra dispositivo e chiave pubblica accanto all’elenco degli indirizzi. È quell’elenco a trasformare una revoca in un compito di due minuti invece di un pomeriggio intero.
Cosa continua a fallire dopo l’handshake
Le coppie di chiavi identificano i peer; non decidono il comportamento della rete. AllowedIPs associa intervalli di indirizzi a un peer, e le rotte intorno le gestisce il client o lo strumento di configurazione. Il sintomo di solito dice quale livello aprire dopo:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
Il DNS può fallire dopo che entrambi i peer si sono autenticati correttamente, e un’applicazione può fallire mentre il tunnel stesso è sano, quindi un handshake funzionante non è la fine della diagnosi. Le chiavi non dicono nulla nemmeno sulla pratica di registrazione di un operatore né sul fatto che un sito riconosca il tuo account, e quelle domande appartengono altrove. Passa ai livelli di rete una volta superati i quattro controlli, perché una chiave mancante non è un problema di instradamento mascherato.