Que capacidades de Linux necesita o teu proceso VPN?
A configuración da interface, as rutas, o acceso aos dispositivos e os sockets ordinarios son privilexios separados. Nomea a operación que fallou antes de conceder CAP_NET_ADMIN.
Un daemon VPN necesita operacións de rede privilexiadas aínda que as aplicacións ordinarias abren sockets de saída sen ningún privilexio. Nesa fenda comezan a maioría dos erros de capacidades: alguén ve un erro de permisos, concede todo o conxunto e o servizo funciona por motivos que despois ninguén sabe explicar. O percorrido seguinte parte da operación que fallou, asígnaa a unha autoridade e logo comproba o contexto no que o proceso se executa realmente. Executarse como root sen restricións é unha resposta válida para algúns despregamentos, pero debería ser unha decisión e non un valor por defecto.
Comeza pola operación que fallou
Le o erro antes de ler un titorial. «Operación non permitida» ao cambiar unha interface, a negativa a abrir un nodo de dispositivo e un fallo de bind nun porto baixo son tres problemas distintos con tres concesións distintas. Se o proceso arrinca e só falla no primeiro cambio de ruta, iso tamén indica que a creación da interface xa tivo éxito, o que estreita moito a resposta.
Reproduce o fallo co servizo detido e logo iníciao en primeiro plano co mesmo usuario se a implementación o permite. Un erro que podes ver é mellor ca unha liña de rexistro que tes que adiviñar, e deixa evidente a diferenza entre un problema de capacidades e unha denegación de SELinux ou AppArmor.
Asigna cada operación a unha autoridade
A táboa é un mapa inicial, non un substituto da documentación da implementación:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
As dúas filas desa táboa son as que a xente confunde. Abrir /dev/net/tun é unha cuestión de permisos de ficheiro; pedirlle ao núcleo que configure o que abriches é unha cuestión de capacidades. Conceder CAP_NET_ADMIN non arranxa un nodo de dispositivo que o teu usuario de servizo non pode ler, e arranxar o nodo non che dá autoridade sobre as rutas. Comproba ambas as cousas antes de cambiar calquera das dúas.
WireGuard no núcleo e os programas de túnel en espazo de usuario tampouco teñen os mesmos requisitos. A vía do módulo do núcleo configura unha interface existente mediante netlink, mentres que unha implementación en espazo de usuario tamén pode necesitar o dispositivo e, para algúns transportes, sockets crus.
Le o contexto: servizo, contedor ou shell
Unha capacidade no espazo de nomes de rede do anfitrión pode afectar moito máis ca a mesma operación dentro dunha pila deliberadamente illada. Un contorno de execución de contedores adoita comezar cun conxunto de límites reducido; engadir NET_ADMIN a un contedor que comparte a rede do anfitrión é unha concesión moito maior ca engadilo a un co seu propio espazo de nomes de rede e sen montaxes do anfitrión.
Para as unidades de systemd, le o que se aplica realmente e non o que parece dicir o ficheiro de unidade: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities informa os valores efectivos, que poden estar fixados por un drop-in que esqueciches. Pide o valor efectivo, nunca o previsto. As capacidades ambient importan porque un servizo que non é root perde capacidades a través de exec sen elas.
Toma como base a configuración admitida do paquete ou da imaxe. Non engadas permisos de sockets crus nin modo privilexiado porque outro titorial os enumerou para outra ferramenta; ese razoamento non transfire nada e cústache o illamento que pagaches. En caso de dúbida, non concedas nada e le as notas da implementación para a operación exacta que necesitas.
Observa que ocorre cando caen os privilexios
Moitos daemons arrincan con privilexios, configuran a interface e despois pasan a un usuario sen privilexios e manteñen o túnel. Desde ese punto o proceso xa non pode engadir unha ruta, reescribir unha regra de firewall nin abrir un dispositivo privilexiado novo, o que está ben ata que unha reconexión necesita exactamente iso. As lecturas de ficheiros e a execución de hooks posteriores poden fallar polo mesmo motivo.
Proba todo o ciclo de vida en lugar do primeiro segundo: o arrinque, unha renovación ou reconexión e a limpeza ao deterse. Un primeiro éxito ao crear a interface non demostra que toda operación privilexiada posterior siga funcionando, e o fallo adoita aparecer horas despois en produción.
As implementacións que manteñen o túnel aberto durante un cambio de usuario adoitan combinalo con opcións para persistir o túnel e as claves. No lado de systemd, a pregunta equivalente é se o conxunto de capacidades da unidade sobrevive ao cambio de usuario que configuraches.
Rexistra a concesión e o seu motivo
Anota a concesión exacta, a operación que habilita e o erro que corrixiu. Unha liña nas notas de despregamento — «CAP_NET_ADMIN no espazo de nomes de rede da unidade, necesario para cambios de ruta tras unha reconexión» — abonda para impedir que a seguinte persoa volva ampliar a concesión.
Despois rele o conxunto efectivo tras cada actualización. Os provedores engaden funcións, as imaxes cambian os valores por defecto e unha capacidade que o ano pasado era innecesaria pode volverse portante sen que ninguén se decate.