Warum die vpnc-Warnung zum Routen-Cache-Flush in einem Container erscheint

Frische Container-Logs enden oft mit einer Read-only file system-Beschwerde über /proc/sys/net/ipv4/route/flush, und diese Zeile bekommt die Schuld für einen Tunnel, der völlig gesund sein kann. Der Schreibvorgang dahinter zielt auf einen Kernel-Eintrag, der nichts Nützliches mehr tut, seit der IPv4-Routen-Cache verschwunden ist. In einem Container wird /proc/sys schreibgeschützt eingebunden, daher wird die Umleitung abgelehnt, bevor ein Wert ankommt, und die Shell gibt diese Ablehnung aus. Ein funktionierender Tunnel kann diese Warnung ausgeben, solange die alte Zeile im Skript bleibt, und --privileged macht den Schreibvorgang nie sinnvoll.

Was das Skript leeren wollte

Ältere Verbindungsskripte endeten mit einer Cache-Bereinigung: einen Wert in eine Kernel-Kontrolldatei schreiben und den IPv4-Stack bitten, seinen Routing-Cache zu verwerfen, damit eine neue Tunnelroute gewählt wird, ohne auf das Auslaufen veralteter Einträge zu warten. Die Datei wurde unter /proc/sys/net/ipv4/ adressiert, was den Vorgang zu einer Shell-Umleitung statt zu einem Routing-Befehl machte. Kernel 3.6 entfernte diesen Cache und damit den Grund für das Leeren. Nichts im aktuellen Datenpfad hängt von diesem Schreibvorgang ab.

Der Eintrag selbst überlebte als Altdatei nur zum Schreiben, sodass ein Skript, das noch hineinschreibt, einen echten Pfad und eine echte Berechtigungsprüfung erreicht. Auf einem Host liefert der Schreibvorgang Erfolg und ändert nichts. In einem Container trifft dieselbe Umleitung auf ein schreibgeschütztes /proc/sys und scheitert mit EROFS, was die Shell als Meldung des schreibgeschützten Dateisystems ausgibt. Auf Kerneln, wo der Pfad wirklich fehlt, lautet der Wortlaut No such file or directory, und die Schlussfolgerung ändert sich nicht.

Die beiden Fehler sagen Unterschiedliches, und der Unterschied sollte klar bleiben. Read-only file system bedeutet, dass der Kernel einen Eintrag erreicht und den Schreibvorgang verweigert hat; No such file or directory bedeutet, dass der Eintrag fehlt. Keine der Meldungen berichtet über das Tunnelgerät, die Routen oder die Namensauflösung, daher kann keine von ihnen mehr Rechte rechtfertigen.

Die Reihenfolge lässt die Meldung kausal wirken. Ein Verbindungsskript installiert Routen, ändert den Schnittstellenzustand und schreibt die Namensauflösung um, bevor es die Bereinigung am Ende erreicht, daher ist die zuletzt ausgegebene Zeile die, die zitiert wird, selbst wenn jeder wichtige Schritt Erfolg zurückgegeben hat. Ein Tunnel, der aufgebaut wird und Verkehr trägt, während er diese Warnung ausgibt, passt genau zu dem Mechanismus oben.

Prüfen Sie Mount und Route, bevor Sie Rechte hinzufügen

Drei Prüfungen trennen eine kosmetische Warnung von einem echten Fehler: ob das installierte Skript die Zeile noch enthält, wie /proc/sys eingebunden ist und wohin der Verkehr der Anwendung tatsächlich geht. Führen Sie sie im selben Container-Namespace oder auf dem Host aus, auf dem die Warnung erschien, denn eine Prüfung auf einem unbeteiligten Rechner beantwortet eine andere Frage.

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

Die grep-Antwort ist schwächer, als sie aussieht, denn ein Treffer beweist, dass die Zeile vorhanden ist, nicht dass sie ungeschützt läuft; ein gepflegtes Skript kann den Schreibvorgang in einer Prüfung tragen, die ihn überspringt. findmnt -no OPTIONS /proc/sys klärt den Mount direkt, und ro in dieser Ausgabe bedeutet, dass jeder Schreibvorgang unterhalb dieses Punkts verweigert wird, was das Skript auch tut. Die Routenabfrage zeigt dann, ob das Ziel, das die Anwendung braucht, über die Tunnelschnittstelle oder über das Standard-Gateway des Containers aufgelöst wird. Eine Abfrage, die das Standard-Gateway wählt, bedeutet, dass der Tunnel aufkam und nichts hineinroutet, was ein Routingproblem und kein Rechteproblem ist.

Woher die Korrektur tatsächlich kommt

Die gepflegte Korrektur lebt im Skript und nicht in den Container-Flags. Das Upstream-vpnc-script hat geändert, wie es diesen Vorgang behandelt, daher vergleichen Sie die Kopie im Image mit dem aktuellen Upstream und aktualisieren Sie über das Paket oder den Image-Build, das bzw. der sie liefert. Eine handbearbeitete Datei in einem laufenden Container ist nicht überprüfbar und überlebt den nächsten Build nicht.

--privileged ist dokumentiert als Gewährung aller Capabilities plus breitem Gerätezugriff, ein großes Zugeständnis für eine Meldung, die nichts ändert, daher benennen Sie stattdessen die fehlende Capability, wenn wirklich eine fehlt. Wiederholen Sie nach dem Update die Routenabfrage und lassen Sie eine Anwendung den Tunnel nutzen, denn ein stilles Log und eine funktionierende Verbindung sind getrennte Ergebnisse.