Dar CAP_NET_ADMIN a OpenVPN sin darle root

El servicio arranca, el registro se queja de que no puede abrir el dispositivo tun y las rutas nunca aparecen. Ejecute capsh --print en su shell y cap_net_admin está justo ahí, lo que hace que el fallo parezca imposible. Lo que difiere entre su shell y la unidad es la transición de privilegios, no la disposición del núcleo a conceder la capacidad. Recorra las cuatro comprobaciones siguientes en orden y deténgase en la primera que explique la diferencia.

Separe una capacidad ausente de un dispositivo oculto

Dos fallos se ven iguales desde la línea de registro. Un proceso sin CAP_NET_ADMIN no puede crear ni configurar la interfaz del túnel, y un proceso cuyo sandbox oculta /dev/net/tun no puede abrirlo de entrada. Añadir capacidades no arreglará el segundo caso.

Compruebe si el dispositivo existe dentro del espacio de nombres del servicio antes de editar nada. PrivateDevices=yes es una línea de endurecimiento habitual que elimina el nodo tun por completo, y un ProtectSystem restrictivo puede dejar la ruta de configuración solo de lectura de una forma que se lee como un error de permisos. Ambos producen líneas de registro que mencionan el túnel, y por eso se culpa a las capacidades. Confirme primero que el nodo está presente y se puede abrir, y después siga.

Sepa qué conjunto de capacidades está mirando

Linux mantiene los conjuntos permitido, efectivo, heredable, límite y ambiente, y el conjunto ambiente es el que sobrevive a un exec de un usuario que no es root. Las capacidades de archivo en el binario pueden ceder derechos permitidos y efectivos en el exec, pero solo mientras nada en la cadena bloquee esa transferencia.

Aquí es donde sudo engaña a la gente. Un comando ejecutado mediante sudo -u inicia una nueva transición de privilegios y el conjunto ambiente desaparece, así que la misma comprobación que triunfa como root falla allí. El gestor de servicios es otra transición más, y no concede nada ambiente salvo que la unidad lo diga.

Conceda la capacidad en la unidad, no en un envoltorio

Una sección de servicio mínima para un túnel que debe crear un dispositivo e instalar rutas se lee así.

[Unit]
Description=OpenVPN client, office profile
After=network-online.target

[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.conf

AmbientCapabilities pone el derecho en el conjunto ambiente antes de que arranque el proceso, y CapabilityBoundingSet impide que el proceso tenga algo fuera de esa lista. NoNewPrivileges=yes bloquea la obtención de privilegios mediante setuid o capacidades de archivo, mientras que la capacidad que la unidad concede explícitamente sigue aplicándose. Añada CAP_NET_BIND_SERVICE solo cuando el servicio deba enlazar un puerto bajo, y nunca añada CAP_SYS_ADMIN solo porque un hilo de foro lo hiciera.

Si la unidad envuelve el binario en sudo, quite el envoltorio. systemd ya aplica User=, y esa capa extra es el motivo más probable de que el conjunto ambiente esté vacío.

Verifique contra el proceso vivo, no contra el archivo de la unidad

Lea lo que el gestor aplicó realmente y luego lea el proceso que generó.

unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/status

Si la unidad enumera la capacidad y CapEff sigue sin tenerla, algún drop-in está anulando la configuración o algún paso ExecStartPre está cambiando el entorno. Busque el nombre de la unidad en los directorios drop-in antes de dar por sentado que el archivo principal es la autoridad, porque un archivo posterior gana en silencio. Si tanto la unidad como el proceso muestran la capacidad y el túnel sigue fallando, vuelva a las comprobaciones de dispositivo y de ruta en lugar de ampliar el conjunto límite. Ampliarlo oculta la causa real y deja el servicio con más privilegios de los que tenía.

Prefiera soltar privilegios después del arranque

OpenVPN puede arrancar con privilegios y luego bajar a una cuenta sin privilegios mediante sus propias opciones user y group, con persist-key y persist-tun manteniendo el túnel utilizable después. Esa disposición estrecha la ventana en la que el proceso tiene derechos, y a menudo encaja mejor que arrancar todo el demonio sin privilegios con capacidades permanentes.

Elija el modelo que elija, reinicie la unidad y repita las comprobaciones tras un reinicio del sistema, porque un servicio que funciona desde una shell root interactiva y falla al arrancar suele ser una diferencia de capacidad, dispositivo o permisos de archivo. Anote los ajustes de la unidad junto a la salida de capacidades del proceso para que el siguiente revisor vea si una actualización de paquete o un drop-in ha movido el límite.