WireGuard: Unable to Access Interface: Operation Not Permitted (solución)

Divulgación de afiliados: este artículo contiene enlaces de afiliación de Contabo. Si contratas un VPS a través de ellos, recibimos una comisión sin coste adicional para ti.

Ejecutas wg-quick up wg0 y se detiene en una sola línea:

Unable to access interface: Operation not permitted

La primera respuesta que vas a encontrar es añadir sudo. Muy a menudo sudo ya está ahí, y el comando sigue fallando, que es justo donde la mayoría se atasca.

Qué está informando el mensaje

Operation not permitted es EPERM, devuelto por el kernel cuando wg intenta configurar la interfaz por netlink. Se le preguntó al kernel, y el kernel dijo que no. Es una afirmación más acotada de lo que parece, y conviene separarla de dos errores con los que se confunde:

• No such device significa que la interfaz no existe. Otro problema.
• Command not found o un error de módulo significa que faltan las herramientas o el módulo del kernel. También es otro problema.

Aquí las herramientas se ejecutaron, la llamada se hizo y el permiso se denegó a nivel de kernel. Así que la pregunta no es "¿soy root?", sino "¿qué más está bloqueando esta llamada?".

Causa 1: de verdad no eres root

Merece la pena descartarla con un comando, porque no cuesta nada:

id -u

Si no devuelve 0 y no usaste sudo, ahí tienes la respuesta. Si imprime 0, sigue adelante. Ten en cuenta que sudo wg-quick up wg0 y sudo -E wg-quick up wg0 se comportan distinto respecto al entorno, pero ninguno cambia el panorama de capabilities que viene a continuación.

Causa 2: un contenedor sin CAP_NET_ADMIN

Esta es la habitual, y sudo no puede arreglarla. Dentro de un contenedor puedes ser uid 0 y aun así carecer de la capability que autoriza la administración de red. Root en un contenedor no es root en el host.

Comprueba lo que tienes realmente:

capsh --print | grep -i net_admin

Si no aparece cap_net_admin en el conjunto efectivo, el kernel lo rechazará siempre, con sudo o sin él. En Docker:

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

En un contenedor LXC sin privilegios, la capability por sí sola no suele bastar porque el dispositivo tun no está expuesto; hay que pasar el dispositivo en la configuración del contenedor. Lo mismo ocurre cuando el "servidor" que has alquilado es en sí un contenedor: en los planes VPS basados en OpenVZ o LXC es el kernel del proveedor el que decide lo que puedes hacer, y ningún sudo por tu parte añade NET_ADMIN. La solución ahí es una instancia KVM, que se trata al final de este artículo. Si tu WireGuard vive en un contenedor por diseño, la instalación en contenedores se explica aparte en WireGuard en Docker.

Si prefieres partir de una definición de contenedor que ya lleve las capabilities correctas, la plantilla docker-compose de nuestro WireGuard Self-Hosting Kit (9 USD, PDF + Markdown + archivos .conf listos) declara cap_add: NET_ADMIN, SYS_MODULE y el sysctl net.ipv4.ip_forward=1, con la interfaz web enlazada solo a la dirección del túnel. El kit incluye además una checklist de 12 causas para un túnel que se levanta pero no pasa tráfico. Todo lo que hay en esta página sigue siendo gratuito. Ver el kit en Gumroad.

Causa 3: el archivo de configuración que la herramienta no quiere leer

wg-quick lee /etc/wireguard/wg0.conf antes de tocar la interfaz. Dos problemas a nivel de archivo aparecen cerca de este paso:

ls -l /etc/wireguard/wg0.conf

El modo debe ser 600 y el propietario root. Un archivo de configuración legible por todos que contiene una clave privada es un problema real en sí mismo, y wg-quick te lo dirá. Un archivo que el usuario que lo invoca no puede leer provoca un fallo antes en la ejecución, antes de cualquier llamada netlink, así que lee la salida completa y no solo la última línea.

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

Causa 4: algo por encima del kernel está diciendo que no

Si eres root, tienes NET_ADMIN y el archivo está limpio, mira qué más puede devolver EPERM en una llamada netlink:

• Un módulo de seguridad. SELinux o AppArmor en modo enforcing pueden denegar la operación. dmesg | tail justo después del comando fallido es la forma más rápida de ver una denegación, porque estos módulos registran donde el comando no lo hace.
• Un /sys en solo lectura o restringido. Algunos entornos endurecidos o mínimos lo montan de forma que bloquea la configuración de la interfaz.
• Un filtro de syscalls. Un perfil seccomp que descarta las llamadas relevantes produce el mismo errno sin ninguna otra pista.

dmesg | tail -20

Si no aparece nada en dmesg, la causa 4 es poco probable y la respuesta es casi seguro la causa 2.

El orden para revisarlo

1. id -u, confirma que eres 0.
2. capsh --print | grep net_admin, confirma la capability.
3. ls -l /etc/wireguard/wg0.conf, confirma modo 600 y propiedad de root.
4. dmesg | tail -20 inmediatamente después del fallo, busca una denegación.

Cuatro comandos, y descartan las causas en el orden de la frecuencia con la que resultan ser la buena.

Una vez que la interfaz se levanta

Un wg-quick up con éxito no equivale a un túnel que funciona. Si la interfaz ya existe pero no pasa nada, has pasado a un problema de enrutamiento o de handshake, no de permisos: la parte del handshake se trata en solución de problemas de handshake en WireGuard, y los errores de dirección que aparecen justo después en el error bad address.

Para el VPS que aloje todo esto, root y NET_ADMIN vienen de serie con una instancia KVM, que es un motivo para preferirla a las ofertas más baratas basadas en contenedores, donde exactamente este problema viene incorporado. Un invitado KVM ejecuta su propio kernel, así que wg-quick up le pregunta a un kernel que controlas tú, no al del proveedor. La gama Cloud VPS de Contabo está virtualizada con KVM (indicado en contabo.com, comprobado el 18 de octubre de 2026) y es la que usamos para nuestras propias guías; nuestras notas sobre las alternativas están en el VPS más barato para una VPN WireGuard.