NetworkManager o wg-quick: chi possiede le tue route WireGuard?

Modifichi AllowedIPs nel file WireGuard, riavvii il tunnel e la tabella di routing è esattamente come prima. La reazione abituale è eliminare la route problematica e andare avanti, cosa che funziona finché la riconnessione successiva non la rimette. Il file che hai modificato non è necessariamente l’oggetto che ha prodotto lo stato che stai osservando. Due gestori possono eseguire lo stesso protocollo su una macchina, e solo uno di loro possiede l’interfaccia alla volta.

Mito: c’è una sola configurazione WireGuard sulla macchina

wg-quick legge un file sotto /etc/wireguard/ e costruisce l’interfaccia quando la alzi. NetworkManager salva un profilo di connessione nel proprio formato keyfile e lo rende all’attivazione, e importare un file wg-quick copia i valori in quel profilo invece di collegarvisi. Modificare l’originale in seguito non cambia nulla, perché il profilo non lo legge più. Lo stesso elenco di peer e chiavi può quindi esistere due volte, con la seconda copia in vigore.

Un segnale che vale la pena ricordare: le modifiche che sopravvivono a un riavvio ma non a una reimportazione provengono da un archivio, e quelle che scompaiono al riavvio dall’altro.

Un esempio pratico rende evidente la separazione. Confronta nmcli connection show con systemctl status wg-quick@wg0, poi controlla a quale interfaccia le route sono davvero appese. Se il servizio è morto e l’interfaccia è attiva, è il profilo a fare il lavoro, qualunque cosa dica il file.

Mito: le regole di routing fanno parte di WireGuard

Il dispositivo WireGuard del kernel conosce peer e chiavi, e non sa nulla di routing per policy. Le voci ip rule e le tabelle aggiuntive che vedi sono state installate dallo strumento che ha alzato l’interfaccia. wg-quick può aggiungere un fwmark e una tabella dedicata più regole che vi puntano, mentre NetworkManager installa le route tramite le proprie impostazioni ipv4 e lascia il DNS al backend di risoluzione usato dal sistema. Stesso tunnel, effetti collaterali diversi.

Leggi ip rule e ip route show table all prima di cambiare qualcosa, e annota in quale tabella vive ogni route. Un numero di tabella che non hai configurato è un forte indizio sullo strumento che l’ha creata.

Mito: eliminare la route è una soluzione

Una route eliminata a runtime è una route che il proprietario reinstallerà alla prossima attivazione, e l’attivazione può avvenire senza di te: ripresa di un portatile, un flap del collegamento, un riavvio del servizio o una autoconnessione di NetworkManager. Ecco perché la stessa route ritorna e perché la soluzione temporanea sembra inaffidabile anziché sbagliata. Identifica prima il gestore, poi modifica l’input che quel gestore legge davvero.

Riconnettersi e riavviare il servizio interessato è il test che separa una correzione reale da una solo apparentemente ordinata.

Scegli un solo proprietario e rimuovi l’altro

Scegli il gestore supportato dal tuo deployment, poi disabilita l’attivazione concorrente tramite il suo controllo documentato invece di sperare che resti inattiva. Un servizio wg-quick mascherato o un profilo NetworkManager eliminato è esplicito; lasciare entrambi abilitati e farli gareggiare non lo è. Conserva l’accesso funzionante prima di disabilitare qualcosa, perché l’interfaccia che porta la tua sessione remota potrebbe essere quella che stai per rimuovere.

Dopo la modifica, verifica il traffico incluso ed escluso, poi il DNS, poi riavvia una volta. Se lo stato sopravvive a un riavvio con un solo gestore, hai un proprietario invece di una coincidenza.

La regola generale vale anche oltre WireGuard: quando un’impostazione continua a tornare, smetti di cancellare il risultato e trova il processo che continua a produrlo.