Pourquoi l'avertissement de purge de route de vpnc apparaît dans un conteneur

Les journaux récents de conteneur se terminent souvent par une plainte Read-only file system au sujet de /proc/sys/net/ipv4/route/flush, et cette ligne se voit reprocher un tunnel qui peut être parfaitement sain. L'écriture derrière elle vise une entrée du noyau qui ne fait plus rien d'utile maintenant que le cache de routes IPv4 a disparu. Dans un conteneur, /proc/sys est monté en lecture seule, donc la redirection est refusée avant qu'une valeur n'arrive et le shell imprime ce refus. Un tunnel qui fonctionne peut imprimer cet avertissement tant que l'ancienne ligne reste dans le script, et --privileged ne rend jamais l'écriture utile.

Ce que le script essayait de purger

Les anciens scripts de connexion se terminaient par un nettoyage du cache : écrire une valeur dans un fichier de contrôle du noyau et demander à la pile IPv4 d'abandonner son cache de routage, afin qu'une nouvelle route de tunnel soit choisie sans attendre l'expiration des entrées obsolètes. Le fichier était adressé sous /proc/sys/net/ipv4/, ce qui faisait de l'opération une redirection du shell plutôt qu'une commande de routage. Le noyau 3.6 a supprimé ce cache, et avec lui la raison d'être de la purge. Rien dans le chemin de données actuel ne dépend de cette écriture.

L'entrée elle-même a survécu comme fichier hérité en écriture seule, donc un script qui y écrit encore atteint un chemin réel et un contrôle de permissions réel. Sur un hôte, l'écriture renvoie un succès et ne change rien. Dans un conteneur, la même redirection heurte un /proc/sys en lecture seule et échoue avec EROFS, que le shell imprime comme le message de système de fichiers en lecture seule. Sur les noyaux où le chemin est réellement absent, la formulation devient No such file or directory, et la conclusion ne change pas.

Les deux erreurs disent des choses différentes, et la différence mérite d'être gardée claire. Read-only file system signifie que le noyau a atteint une entrée et refusé l'écriture ; No such file or directory signifie que l'entrée a disparu. Aucun des deux messages ne renseigne sur le périphérique du tunnel, les routes ou la résolution de noms, donc aucun ne peut justifier plus de privilèges.

C'est l'ordre qui fait paraître le message causal. Un script de connexion installe des routes, change l'état de l'interface et réécrit la résolution de noms avant d'atteindre le nettoyage final, donc la dernière ligne imprimée est celle que l'on cite même lorsque chaque étape importante a renvoyé un succès. Un tunnel qui s'établit et transporte du trafic tout en imprimant cet avertissement correspond exactement au mécanisme ci-dessus.

Vérifiez le montage et la route avant d'ajouter des privilèges

Trois lectures séparent un avertissement cosmétique d'une vraie panne : si le script installé porte encore la ligne, comment /proc/sys est monté, et où va réellement le trafic de l'application. Exécutez-les dans le même espace de noms du conteneur ou sur l'hôte où l'avertissement est apparu, car un contrôle sur une machine sans rapport répond à une autre question.

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

La réponse de grep est plus faible qu'elle n'en a l'air, car une correspondance prouve que la ligne est présente, pas qu'elle s'exécute sans garde ; un script maintenu peut porter l'écriture dans une garde qui la saute. findmnt -no OPTIONS /proc/sys règle le montage directement, et ro dans cette sortie signifie que toute écriture sous ce point est refusée quoi que fasse le script. La recherche de route montre ensuite si la destination dont l'application a besoin se résout par l'interface du tunnel ou par la passerelle par défaut du conteneur. Une recherche qui choisit la passerelle par défaut signifie que le tunnel est monté et que rien n'y est routé, ce qui est un problème de routage et non de privilèges.

D'où vient réellement le correctif

Le correctif maintenu vit dans le script et non dans les indicateurs du conteneur. L'vpnc-script amont a changé sa façon de gérer cette opération, donc comparez la copie dans l'image avec l'amont actuel et mettez à jour via le paquet ou la construction d'image qui la fournit. Un fichier modifié à la main dans un conteneur en marche n'est pas vérifiable et ne survivra pas à la prochaine construction.

--privileged est documenté comme accordant toutes les capacités plus un large accès aux périphériques, une grosse concession pour un message qui ne change rien, donc nommez la capacité manquante si l'une manque réellement. Après la mise à jour, répétez la recherche de route et laissez une application utiliser le tunnel, car un journal silencieux et une connexion qui fonctionne sont deux résultats distincts.