WireGuard non riesce a creare la sua interfaccia: kernel o permessi?
La creazione dell’interfaccia fallisce prima di qualsiasi stretta di mano con un peer. Leggi l’errore per distinguere un modulo mancante da un limite di privilegi o da un proprietario già esistente dell’interfaccia.
WireGuard non riesce a creare la sua interfaccia, quindi non c’è alcun dispositivo da configurare, nessuna chiave da scambiare e nessuna stretta di mano da diagnosticare. Il guasto resta interamente sulla macchina locale, e il testo dell’errore dice quale parte dello stack locale ha rifiutato. Leggerlo correttamente è più rapido che reinstallare la configurazione del peer. I livelli sono separabili, e il messaggio nomina quello che ha rifiutato.
L’errore si verifica prima che qualsiasi peer parli
Creare un’interfaccia è una sola richiesta netlink al kernel che chiede un dispositivo di tipo wireguard. Il kernel ha o non ha un driver che comprende quel tipo, e la risposta torna subito. Nessun pacchetto lascia la macchina durante questo passaggio, perciò gli indirizzi degli endpoint e le chiavi del server non possono essere la causa.
Quest’ordine conta per la diagnosi. Se il comando non ha mai creato un dispositivo, il problema non può essere una chiave pubblica sbagliata né una porta UDP bloccata. Correggi prima il percorso di creazione locale e solo dopo guarda verso l’esterno.
Quale implementazione dovrebbe possedere il dispositivo
Due implementazioni possono rispondere a quella richiesta. Il modulo nel kernel registra il tipo di dispositivo wireguard, e un’implementazione nello spazio utente come wireguard-go fornisce la stessa interfaccia con un meccanismo diverso. Se il modulo manca, il kernel rifiuta la richiesta con un errore di dispositivo non supportato, e la soluzione è caricare il modulo oppure indirizzare gli strumenti all’implementazione nello spazio utente.
Verifica ciò che è realmente presente prima di scegliere tra le due. Il primo comando mostra se il modulo è caricato e il secondo interroga il kernel direttamente:
lsmod | grep wireguard
ip link add wgtest0 type wireguardIl secondo comando è la più piccola riproduzione possibile: chiede un dispositivo e nient’altro. Se fallisce con un messaggio di tipo non supportato, il pezzo mancante è l’implementazione e non il tuo file di configurazione.
| Error text | What refused | Next step |
|---|---|---|
| Unknown device type or operation not supported | The kernel has no wireguard driver | Load the module or use the userspace implementation |
| Operation not permitted | Missing privilege | Use the service context or grant the capability |
| File exists | The name is already in use | Inspect the owner before touching it |
| No such device in a container | No tunnel device or capability | Add the device and NET_ADMIN to the container |
Privilegi e confini del container
Creare e configurare un dispositivo di rete richiede privilegi, come root oppure con la capacità di amministrare la rete. Una normale sessione utente non può farlo, e questa restrizione è il progetto e non un ostacolo da aggirare eseguendo un programma di installazione che non hai esaminato.
Dentro un container il confine raddoppia. Il container ha bisogno dell’accesso al dispositivo tunnel e della capacità di configurarlo, e i flag che lo concedono sono gli stessi che usa un container VPN su Linux. Un ospite limitato che può navigare normalmente sul web non può comunque creare un’interfaccia, perché la navigazione non richiede quella capacità. Concedi la capacità al servizio che ne ha bisogno e non a ogni sessione dell’host.
Risolvi il conflitto di nomi, poi riprova
Un’interfaccia che esiste già non è automaticamente un residuo. Un altro gestore può possedere il nome e usarlo in questo momento, quindi ispezionala prima di cancellare qualcosa:
ip link show wg0
sudo wg show wg0Se il proprietario è un servizio attivo, configura quel servizio invece di creare un secondo dispositivo. Se è davvero obsoleta, rimuovila tramite lo strumento che l’ha creata, poi alza l’interfaccia con il client o l’unità documentati, così che la configurazione e il dispositivo restino allineati.
Una volta riuscita la creazione, il guasto successivo appartiene a una fase successiva, e un’unità che segnala un guasto dopo che il dispositivo esiste è un problema diverso da un dispositivo che non è mai stato creato. Separa i due prima di cambiare di nuovo i permessi.