Por que o aviso de flush de rotas do vpnc aparece num contêiner

Logs novos de contêiner costumam terminar numa queixa Read-only file system sobre /proc/sys/net/ipv4/route/flush, e essa linha leva a culpa por um túnel que pode estar perfeitamente saudável. A escrita por trás dela visa uma entrada do kernel que já não faz nada útil agora que o cache de rotas IPv4 desapareceu. Dentro de um contêiner, /proc/sys é montado somente leitura, então o redirecionamento é recusado antes de qualquer valor chegar e o shell imprime essa recusa. Um túnel funcional pode imprimir este aviso enquanto a linha antiga permanecer no script, e --privileged nunca torna a escrita significativa.

O que o script tentava limpar

Scripts de conexão mais antigos terminavam com uma limpeza de cache: escrever um valor num arquivo de controle do kernel e pedir à pilha IPv4 que descartasse seu cache de roteamento, para que uma nova rota de túnel fosse escolhida sem esperar as entradas obsoletas expirarem. O arquivo era endereçado sob /proc/sys/net/ipv4/, o que tornava a operação um redirecionamento do shell e não um comando de roteamento. O kernel 3.6 removeu esse cache, e com ele a razão de existir do flush. Nada no caminho de dados atual depende dessa escrita.

A própria entrada sobreviveu como arquivo legado somente de escrita, então um script que ainda escreve nela chega a um caminho real e a uma verificação de permissões real. Num host, a escrita retorna sucesso e não muda nada. Num contêiner, o mesmo redirecionamento encontra um /proc/sys somente leitura e falha com EROFS, que o shell imprime como a mensagem de sistema de arquivos somente leitura. Em kernels onde o caminho realmente falta, o texto passa a No such file or directory, e a conclusão não muda.

Os dois erros dizem coisas diferentes, e a diferença merece ficar clara. Read-only file system significa que o kernel chegou a uma entrada e recusou a escrita; No such file or directory significa que a entrada sumiu. Nenhuma das mensagens informa sobre o dispositivo do túnel, as rotas ou a resolução de nomes, então nenhuma pode justificar mais privilégios.

É a ordem que faz a mensagem parecer causal. Um script de conexão instala rotas, muda o estado da interface e reescreve a resolução de nomes antes de chegar à limpeza no final, então a última linha impressa é a que as pessoas citam mesmo quando cada passo importante retornou sucesso. Um túnel que se estabelece e transporta tráfego enquanto imprime este aviso encaixa exatamente no mecanismo acima.

Verifique a montagem e a rota antes de acrescentar privilégios

Três leituras separam um aviso cosmético de uma falha real: se o script instalado ainda traz a linha, como /proc/sys está montado e para onde o tráfego da aplicação realmente vai. Execute-as no mesmo namespace do contêiner ou no host onde o aviso apareceu, porque uma verificação numa máquina não relacionada responde a outra pergunta.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

A resposta do grep é mais fraca do que parece, porque um acerto prova que a linha existe, não que ela roda sem proteção; um script mantido pode trazer a escrita dentro de uma guarda que a pula. findmnt -no OPTIONS /proc/sys resolve a montagem diretamente, e ro nessa saída significa que toda escrita abaixo desse ponto é recusada, faça o script o que fizer. Depois, a consulta de rota mostra se o destino de que a aplicação precisa é resolvido pela interface do túnel ou pelo gateway padrão do contêiner. Uma consulta que escolhe o gateway padrão significa que o túnel subiu e nada é roteado para ele, o que é um problema de roteamento e não de privilégios.

De onde vem realmente a correção

A correção mantida vive no script e não nas flags do contêiner. O vpnc-script upstream mudou a forma como trata esta operação, então compare a cópia dentro da imagem com o upstream atual e atualize pelo pacote ou pela construção de imagem que a fornece. Um arquivo editado à mão dentro de um contêiner em execução não é revisável e não sobrevive à próxima construção.

--privileged está documentado como concessão de todas as capacidades mais acesso amplo a dispositivos, uma concessão grande para uma mensagem que não muda nada, então nomeie a capacidade em falta se realmente faltar alguma. Depois da atualização, repita a consulta de rota e deixe uma aplicação usar o túnel, porque um log silencioso e uma conexão funcional são resultados separados.