Profilo WireGuard copiato: perché falliscono entrambi i dispositivi

Il tunnel funzionava sul portatile, quindi il file di configurazione è finito sul telefono e sul tablet, e ora gli handshake vanno e vengono su tutti e tre. Nulla è stato digitato male e la configurazione del server non è stata modificata. Un profilo WireGuard non è un account con password che più dispositivi possono usare; è una coppia di chiavi, e solo la metà pubblica identifica un peer. Copiare il file copia l’identità, quindi il server ora cerca di mantenere un’unica relazione di endpoint per più dispositivi che dichiarano tutti di essere lo stesso. Dal lato del server non c’è un secondo dispositivo da notare, solo un peer il cui indirizzo continua a spostarsi.

Inizia dal log degli handshake su ogni dispositivo

Apri il client su ogni dispositivo e annota l’ora dell’ultimo handshake e l’endpoint attuale prima di cambiare qualsiasi cosa. In un’installazione sana quei valori restano stabili finché un dispositivo è in uso; con un’identità duplicata i timestamp si alternano, e l’endpoint registrato sul server può descrivere un dispositivo diverso da quello che possiede il profilo. Quell’alternanza è la firma, e spiega perché il sintomo somiglia a una connettività instabile e non a un errore di configurazione. I dispositivi non sono rotti; si interrompono a vicenda.

Fai la lettura sui dispositivi stessi, così ogni osservazione resta legata a una macchina precisa. Un timestamp copiato da una chat di assistenza perde quel legame e dopo vale molto poco.

Conferma se due dispositivi condividono una sola identità

Confronta le chiavi pubbliche, mai quelle private. La chiave pubblica deriva da quella privata, quindi due profili con la stessa chiave privata producono la stessa chiave pubblica e sono indistinguibili per il server. Se due dispositivi riportano la stessa chiave pubblica, la questione è risolta e nessuna regolazione di keepalive aiuterà. Due chiavi diverse con handshake instabili indicano tutt’altro, ed è per questo che il confronto deve venire prima di qualsiasi modifica.

wg show wg0 public-key
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Questi comandi stampano solo materiale pubblico e contatori, ed è tutto ciò che serve a una conversazione di assistenza. Una voce di peer sul server con una sola chiave pubblica e un endpoint che continua a spostarsi tra due reti è il risultato atteso della duplicazione, perché un pacchetto autenticato da una nuova sorgente aggiorna dove viene inviato il traffico. Questo comportamento è il protocollo che funziona come progettato, ed è per questo che viene così facilmente scambiato per un guasto di rete.

Predisponi correttamente una seconda identità

Genera una nuova coppia di chiavi sul dispositivo che ne ha bisogno, poi aggiungi la chiave pubblica risultante al server come peer separato con i propri indirizzi consentiti. La chiave privata dovrebbe essere creata sul dispositivo e restare lì; una chiave generata altrove e incollata ha attraversato almeno un posto in più, e quel viaggio ora fa parte della storia di fiducia.

umask 077
wg genkey > newdevice.key
wg pubkey < newdevice.key

Il lato server richiede la chiave pubblica più un’assegnazione di indirizzo consentito che non entri in conflitto con il dispositivo originale. Un profilo che conserva il vecchio indirizzo del tunnel presentando una chiave nuova produce un peer che il server può accettare e poi instradare male, il che è un guasto più sottile di un handshake rifiutato. Controlla l’assegnazione dell’indirizzo prima di connetterti, non dopo la prima confusa perdita di pacchetti.

Ritira il duplicato senza rompere l’originale

Una volta che la nuova identità funziona, rimuovi il profilo copiato dalla cerchia del dispositivo originale invece di cancellare la voce sul server che l’originale usa ancora. Se la copia può essere stata esposta, revocala subito e poi riemetti; la comodità non è una ragione per lasciare in circolazione un segreto condiviso.

Un servizio gestito che supporta davvero più dispositivi per abbonamento te lo dirà e rilascerà credenziali separate dalla propria interfaccia. La duplicazione manuale di un profilo non è mai quel modello, anche quando il marchio del servizio suggerisce dispositivi illimitati.

Prova entrambi i dispositivi separatamente e insieme

Verifica prima ogni dispositivo da solo: handshake, contatori di trasferimento che si muovono e una destinazione raggiungibile solo dal tunnel. Poi esegui entrambi contemporaneamente e osserva come il server vede gli endpoint; due chiavi distinte dovrebbero produrre due voci di peer stabili invece di una che salta.

Conserva le nuove chiavi pubbliche con le note di distribuzione e annota quale dispositivo possiede quale. Senza quell’elenco, la prossima persona che copia un profilo ripeterà lo stesso guasto, e gli handshake alternati verranno di nuovo attribuiti alla rete.