WireGuard: Unable to Access Interface: Operation Not Permitted, cause e soluzioni

Divulgazione affiliata - Questo articolo contiene link affiliati a Contabo. Se prendi un VPS tramite questi link, riceviamo una commissione senza costi aggiuntivi per te.

Lanci wg-quick up wg0 e si ferma su una riga:

Unable to access interface: Operation not permitted

La prima risposta che troverai è aggiungere sudo. Molto spesso sudo c'è già, e il comando fallisce lo stesso: è qui che la maggior parte delle persone si blocca.

Cosa riporta il messaggio

Operation not permitted è EPERM, restituito dal kernel quando wg prova a configurare l'interfaccia via netlink. Al kernel è stato chiesto, e il kernel ha detto no. È un'affermazione più ristretta di quanto sembri, e conviene distinguerla da due errori con cui viene confusa:

• No such device significa che l'interfaccia non c'è. Problema diverso.
• Command not found o un errore di modulo significa che mancano gli strumenti o il modulo del kernel. Anche questo è diverso.

Qui gli strumenti sono partiti, la chiamata è stata fatta e il permesso è stato negato a livello kernel. Quindi la domanda non è "sono root?", ma "cos'altro sta filtrando questa chiamata?".

Causa 1: non sei davvero root

Vale la pena escluderla con un comando, perché non costa nulla:

id -u

Se non stampa 0 e non hai usato sudo, la risposta è quella. Se stampa 0, vai avanti. Nota che sudo wg-quick up wg0 e sudo -E wg-quick up wg0 si comportano diversamente rispetto all'ambiente, ma nessuno dei due cambia il quadro delle capability descritto sotto.

Causa 2: un container senza CAP_NET_ADMIN

Questa è la più comune, e sudo non può risolverla. Dentro un container puoi essere uid 0 e non avere comunque la capability che autorizza l'amministrazione della rete. Root in un container non è root sull'host.

Controlla cosa possiedi davvero:

capsh --print | grep -i net_admin

Se cap_net_admin non compare nell'insieme effettivo, il kernel rifiuterà, ogni volta, sudo o non sudo. Per Docker:

docker run --cap-add NET_ADMIN --device /dev/net/tun ...

Per un container LXC non privilegiato, la sola capability di solito non basta perché il device tun non è esposto: il device va passato nella configurazione del container. Lo stesso vale quando il "server" che hai noleggiato è esso stesso un container: sui piani VPS basati su OpenVZ o LXC è il kernel del provider a decidere cosa puoi fare, e nessuna quantità di sudo dal tuo lato aggiunge NET_ADMIN. La soluzione in quel caso è un'istanza KVM, trattata alla fine di questo articolo. Se il tuo WireGuard vive in un container per scelta, la configurazione containerizzata è trattata a parte in WireGuard in Docker.

Se preferisci partire da una definizione di container che ha già le capability giuste, il template docker-compose del nostro WireGuard Self-Hosting Kit (9 USD, PDF + Markdown + file .conf pronti) dichiara cap_add: NET_ADMIN, SYS_MODULE e il sysctl net.ipv4.ip_forward=1, con l'interfaccia web legata solo all'indirizzo del tunnel. Il kit contiene anche una checklist di 12 cause per un tunnel che si alza ma non fa passare traffico. Tutto quello che c'è in questa pagina resta gratuito. Vedi il kit su Gumroad.

Causa 3: il file di configurazione che lo strumento non vuole leggere

wg-quick legge /etc/wireguard/wg0.conf prima di toccare l'interfaccia. Due problemi a livello di file emergono vicino a questo passaggio:

ls -l /etc/wireguard/wg0.conf

I permessi devono essere 600 e il proprietario root. Una configurazione leggibile da tutti che contiene una chiave privata è un problema reale di per sé, e wg-quick te lo segnalerà. Un file che l'utente chiamante non può leggere produce un errore prima nell'esecuzione, prima di qualsiasi chiamata netlink, quindi leggi tutto l'output e non solo l'ultima riga.

chmod 600 /etc/wireguard/wg0.conf
chown root:root /etc/wireguard/wg0.conf

Causa 4: qualcosa sopra il kernel sta dicendo no

Se sei root, hai NET_ADMIN e il file è a posto, guarda cos'altro può restituire EPERM su una chiamata netlink:

• Un modulo di sicurezza. SELinux o AppArmor in modalità enforcing possono negare l'operazione. dmesg | tail subito dopo il comando fallito è il modo più rapido per vedere un diniego, perché questi moduli lo registrano lì dove il comando non lo fa.
• Un /sys in sola lettura o limitato. Alcuni ambienti hardened o minimali lo montano in un modo che blocca la configurazione dell'interfaccia.
• Un filtro di syscall. Un profilo seccomp che scarta le chiamate interessate produce lo stesso errno senza nessun altro indizio.

dmesg | tail -20

Se in dmesg non compare nulla, la causa 4 è improbabile e la risposta è quasi certamente la causa 2.

L'ordine da seguire

1. id -u, conferma di essere 0.
2. capsh --print | grep net_admin, conferma la capability.
3. ls -l /etc/wireguard/wg0.conf, conferma permessi 600 e proprietà root.
4. dmesg | tail -20 subito dopo l'errore, cerca un diniego.

Quattro comandi, che escludono le cause nell'ordine di quanto spesso si rivelano quella giusta.

Quando l'interfaccia si alza

Un wg-quick up riuscito non equivale a un tunnel funzionante. Se ora l'interfaccia esiste ma non passa nulla, sei passato a una questione di routing o di handshake, non di permessi: il lato handshake è trattato in risoluzione dei problemi di handshake WireGuard, e gli errori a livello di indirizzo che compaiono subito dopo in l'errore bad address.

Per un VPS su cui ospitare tutto questo, root e NET_ADMIN sono di serie con un'istanza KVM, ed è un motivo per preferirla alle offerte più economiche basate su container, dove proprio questo problema è incorporato. Un guest KVM gira con il proprio kernel, quindi wg-quick up interroga un kernel che controlli tu, non quello del provider. La gamma Cloud VPS di Contabo è virtualizzata KVM (indicato su contabo.com, verificato il 18 ottobre 2026) ed è quella che usiamo per le nostre guide; le nostre note sulle alternative sono in i VPS più economici per una VPN WireGuard.