Por que o modo privilexiado é máis amplo do que unha VPN necesita

O contedor non abría o seu túnel, así que se engadiu a marca privilexiada e agora funciona. Esa secuencia só demostrou que faltaba polo menos un permiso, e non di nada sobre cal. O modo privilexiado concede un conxunto de capacidades e acceso a dispositivos moito máis amplo do que necesita unha interface de túnel.

Que cambia realmente a marca

Un contedor privilexiado recibe capacidades amplas e acceso aos dispositivos do anfitrión, o que é unha concesión moito maior do que require a ruta de rede. O conxunto exacto documéntao a contorna de execución e non o fixa a tradición, e a documentación de Docker sobre a execución de contedores describe as opcións de privilexio dispoñibles. Lela unha vez abonda para ver que o túnel é unha parte pequena do total.

Dous requisitos máis estreitos cobren a maioría dos contedores VPN. Configurar unha interface necesita a capacidade de administración de rede, e abrir o dispositivo de túnel necesita acceso a ese nodo de dispositivo concreto. Son concesións separadas, e fornecer ambas segue sendo máis estreito que a opción global. O resto do conxunto privilexiado non ten nada que ver co túnel. Existe para cargas de traballo que de verdade necesitan acceso a nivel de anfitrión, e un contedor VPN normalmente non é unha delas.

Emparexe cada erro cun requisito previo

A mensaxe de erro dille que requisito previo falta se a le antes de suprimirla. Unha mensaxe sobre un nodo de dispositivo nomea o dispositivo, unha mensaxe sobre unha operación non permitida nomea unha capacidade, e unha mensaxe sobre un módulo ou un sysctl nomea soporte do núcleo. Cada un deles ten unha solución distinta, e só un deles é unha capacidade.

Un ficheiro de configuración ausente segue ausente despois de conceder todas as capacidades, por iso o modo privilexiado ás veces non cambia absolutamente nada. O contedor arrinca, o túnel segue fallando, e o erro real nunca tivo que ver con permisos. O soporte do núcleo é o terceiro caso e o máis fácil de ler mal. Un módulo que non está cargado no anfitrión non se pode cargar desde dentro dun contedor sen privilexios, e conceder máis capacidades dentro do contedor non cambia o estado do anfitrión.

Comprobe o requisito, non o síntoma

Comece pola invocación mínima que documenta a imaxe, execútea e garde o texto exacto do fallo. Despois engada unha concesión á vez e anote que adición cambiou o resultado.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Un contedor que ve o dispositivo e ten a capacidade pero aínda así falla está a dicirlle que o problema está noutro sitio. Ese é un resultado útil, e o modo privilexiado ocultaríao.

Comprobe tamén os permisos do dispositivo no anfitrión, porque un nodo de dispositivo concedido correctamente coa propiedade de grupo equivocada produce o mesmo erro que unha concesión ausente.

Anote a concesión máis estreita que funcione

Anote cada dispositivo e capacidade que necesita o despregamento, xunto co erro que os xustificou. Ese rexistro é o que permite á seguinte persoa retirar algo con seguridade, e é o que pedirá un auditor cando se notifique un contedor como privilexiado.

Revise tamén a contorna que o rodea, porque a rede do anfitrión, as montaxes do anfitrión e as opcións da contorna de execución poden ampliar cada unha o impacto dunha concesión. Unha invocación illada de laboratorio que os combina todos non é unha configuración de produción, por ben que funcionase. Probe a aplicación, o seu comportamento en DNS e un fallo de túnel antes de dar o despregamento por rematado. O permiso para crear unha interface non é unha política de saída, e un contedor que pode tunelar perfectamente segue encamiñando todo o que envía a aplicación.