Dar CAP_NET_ADMIN a OpenVPN sen lle dar root

O servizo arrinca, o rexistro quéixase de que non pode abrir o dispositivo tun e as rutas nunca aparecen. Execute capsh --print na súa shell e cap_net_admin está xusto alí, o que fai que o fallo pareza imposible. O que difire entre a súa shell e a unidade é a transición de privilexios, non a disposición do núcleo a conceder a capacidade. Percorra as catro comprobacións seguintes en orde e detéñase na primeira que explique a diferenza.

Separe unha capacidade ausente dun dispositivo oculto

Dous fallos vense iguais desde a liña de rexistro. Un proceso sen CAP_NET_ADMIN non pode crear nin configurar a interface do túnel, e un proceso cuxo sandbox oculta /dev/net/tun non pode abrila de entrada. Engadir capacidades non arranxará o segundo caso.

Comprobe se o dispositivo existe dentro do espazo de nomes do servizo antes de editar nada. PrivateDevices=yes é unha liña de endurecemento habitual que elimina o nodo tun por completo, e un ProtectSystem restritivo pode deixar a ruta de configuración só de lectura dun xeito que se le como un erro de permisos. Ambos producen liñas de rexistro que mencionan o túnel, e por iso se culpa as capacidades. Confirme primeiro que o nodo está presente e se pode abrir, e despois siga.

Saiba que conxunto de capacidades está mirando

Linux mantén os conxuntos permitido, efectivo, heredable, límite e ambiente, e o conxunto ambiente é o que sobrevive a un exec dun usuario que non é root. As capacidades de ficheiro no binario poden ceder dereitos permitidos e efectivos no exec, pero só mentres nada na cadea bloquee esa transferencia.

Aquí é onde sudo engana a xente. Un comando executado mediante sudo -u inicia unha nova transición de privilexios e o conxunto ambiente desaparece, así que a mesma comprobación que triunfa como root falla alí. O xestor de servizos é outra transición máis, e non concede nada ambiente salvo que a unidade o diga.

Conceda a capacidade na unidade, non nun envoltorio

Unha sección de servizo mínima para un túnel que debe crear un dispositivo e instalar rutas lese 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 pon o dereito no conxunto ambiente antes de que arrinque o proceso, e CapabilityBoundingSet impide que o proceso teña algo fóra desa lista. NoNewPrivileges=yes bloquea a obtención de privilexios mediante setuid ou capacidades de ficheiro, mentres que a capacidade que a unidade concede explicitamente segue aplicándose. Engada CAP_NET_BIND_SERVICE só cando o servizo deba ligar un porto baixo, e nunca engada CAP_SYS_ADMIN só porque un fío de foro o fixera.

Se a unidade envolve o binario en sudo, quite o envoltorio. systemd xa aplica User=, e esa capa extra é o motivo máis probable de que o conxunto ambiente estea baleiro.

Verifique contra o proceso vivo, non contra o ficheiro da unidade

Lea o que o xestor aplicou realmente e despois lea o proceso que xerou.

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

Se a unidade enumera a capacidade e CapEff segue sen tela, algún drop-in está anulando a configuración ou algún paso ExecStartPre está cambiando a contorna. Busque o nome da unidade nos directorios drop-in antes de dar por sentado que o ficheiro principal é a autoridade, porque un ficheiro posterior gaña en silencio. Se tanto a unidade como o proceso mostran a capacidade e o túnel segue fallando, volva ás comprobacións de dispositivo e de ruta en lugar de ampliar o conxunto límite. Amplialo oculta a causa real e deixa o servizo con máis privilexios dos que tiña.

Prefira soltar privilexios despois do arranque

OpenVPN pode arrincar con privilexios e despois baixar a unha conta sen privilexios mediante as súas propias opcións user e group, con persist-key e persist-tun mantendo o túnel utilizábel despois. Esa disposición estreita a xanela na que o proceso ten dereitos, e a miúdo encaixa mellor que arrincar todo o daemon sen privilexios con capacidades permanentes.

Escolla o modelo que escolla, reinicie a unidade e repita as comprobacións tras un reinicio do sistema, porque un servizo que funciona desde unha shell root interactiva e falla ao arrincar adoita ser unha diferenza de capacidade, dispositivo ou permisos de ficheiro. Anote os axustes da unidade xunto á saída de capacidades do proceso para que o seguinte revisor vexa se unha actualización de paquete ou un drop-in moveu o límite.