Porque o modo privilegiado é mais amplo do que uma VPN precisa

O contentor não abria o seu túnel, por isso foi adicionada a flag privilegiada, e agora funciona. Essa sequência apenas estabeleceu que faltava pelo menos uma permissão, e não diz nada sobre qual. O modo privilegiado concede um conjunto de capacidades e acesso a dispositivos muito mais amplo do que uma interface de túnel necessita.

O que a flag altera realmente

Um contentor privilegiado recebe capacidades amplas e acesso aos dispositivos do anfitrião, o que é uma concessão muito maior do que a exigida pelo caminho de rede. O conjunto exato é documentado pelo ambiente de execução e não fixado pela tradição, e a documentação do Docker sobre a execução de contentores descreve as opções de privilégio disponíveis. Uma leitura basta para perceber que o túnel é uma pequena parte do total.

Dois requisitos mais estreitos cobrem a maioria dos contentores VPN. Configurar uma interface exige a capacidade de administração de rede, e abrir o dispositivo de túnel exige acesso a esse nó de dispositivo específico. São concessões separadas, e mesmo ambas juntas continuam mais estreitas do que a opção global. O resto do conjunto privilegiado não tem nada a ver com o túnel. Existe para cargas de trabalho que realmente precisam de acesso ao nível do anfitrião, e um contentor VPN normalmente não é uma delas.

Associe cada erro a um pré-requisito

A mensagem de erro diz-lhe qual pré-requisito falta se a ler antes de a suprimir. Uma mensagem sobre um nó de dispositivo nomeia o dispositivo, uma mensagem sobre uma operação não permitida nomeia uma capacidade, e uma mensagem sobre um módulo ou um sysctl nomeia suporte do núcleo. Cada um deles tem uma correção diferente, e apenas um deles é uma capacidade.

Um ficheiro de configuração em falta continua em falta depois de todas as capacidades serem concedidas, e é por isso que o modo privilegiado às vezes não altera absolutamente nada. O contentor arranca, o túnel continua a falhar, e o erro real nunca foi sobre permissões. O suporte do núcleo é o terceiro caso e o mais fácil de ler mal. Um módulo que não está carregado no anfitrião não pode ser carregado de dentro de um contentor sem privilégios, e conceder mais capacidades dentro do contentor não altera o estado do anfitrião.

Verifique o requisito, não o sintoma

Comece pela invocação mínima que a imagem documenta, execute-a e guarde o texto exato da falha. Depois acrescente uma concessão de cada vez e anote qual adição alterou 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

Um contentor que vê o dispositivo e detém a capacidade mas ainda assim falha está a dizer-lhe que o problema está noutro lugar. É um resultado útil, e o modo privilegiado tê-lo-ia escondido.

Verifique também as permissões do dispositivo no anfitrião, porque um nó de dispositivo corretamente concedido com a propriedade de grupo errada produz o mesmo erro que uma concessão em falta.

Registe a concessão mais estreita que funciona

Registe cada dispositivo e capacidade de que a implementação precisa, com o erro que os justificou. É esse registo que permite à pessoa seguinte remover algo com segurança, e é o que um auditor pedirá quando um contentor for reportado como privilegiado.

Reveja também o contexto envolvente, porque a rede do anfitrião, as montagens do anfitrião e as opções do ambiente de execução podem ampliar cada uma o impacto de uma concessão. Uma invocação isolada de laboratório que as combina todas não é uma configuração de produção, por melhor que tenha funcionado. Teste a aplicação, o seu comportamento em DNS e uma falha de túnel antes de considerar a implementação concluída. A permissão para criar uma interface não é uma política de saída, e um contentor que consegue tunelar perfeitamente continua a encaminhar tudo o que a aplicação envia.