Waarom de vpnc-waarschuwing over routecache-flush in een container verschijnt

Verse containerlogs eindigen vaak op een Read-only file system-klacht over /proc/sys/net/ipv4/route/flush, en die regel krijgt de schuld van een tunnel die volledig gezond kan zijn. De schrijfactie erachter richt zich op een kernel-item dat niets nuttigs meer doet nu de IPv4-routecache weg is. In een container wordt /proc/sys alleen-lezen gemount, dus de omleiding wordt geweigerd voordat er een waarde landt en de shell drukt die weigering af. Een werkende tunnel kan deze waarschuwing blijven afdrukken zolang de oude regel in het script staat, en --privileged maakt de schrijfactie nooit zinvol.

Wat het script probeerde te flushen

Oudere verbindingsscripts eindigden met een cache-opruiming: een waarde in een kernel-controlebestand schrijven en de IPv4-stack vragen zijn routingcache te laten vallen, zodat een nieuwe tunnelroute werd gekozen zonder te wachten tot verouderde items verlopen. Het bestand werd onder /proc/sys/net/ipv4/ geadresseerd, waardoor de handeling een shell-omleiding werd in plaats van een routingcommando. Kernel 3.6 verwijderde die cache, en daarmee de reden waarom de flush bestond. Niets in het huidige datapad is afhankelijk van die schrijfactie.

Het item zelf bleef bestaan als een verouderd alleen-schrijfbestand, dus een script dat er nog in schrijft, bereikt een echt pad en een echte rechtencontrole. Op een host geeft de schrijfactie succes terug en verandert niets. In een container stuit dezelfde omleiding op een alleen-lezen /proc/sys en faalt met EROFS, wat de shell afdrukt als het bericht van een alleen-lezen bestandssysteem. Op kernels waar het pad echt ontbreekt, wordt de formulering No such file or directory, en de conclusie verandert niet.

De twee fouten zeggen verschillende dingen, en het verschil is de moeite waard om helder te houden. Read-only file system betekent dat de kernel een item bereikte en de schrijfactie weigerde; No such file or directory betekent dat het item weg is. Geen van beide berichten rapporteert over het tunnelapparaat, de routes of naamresolutie, dus geen van beide kan meer rechten rechtvaardigen.

Het is de volgorde die het bericht causaal laat lijken. Een verbindingsscript installeert routes, wijzigt de interfacestatus en herschrijft naamresolutie voordat het de opruiming aan het einde bereikt, dus de laatst afgedrukte regel is de regel die mensen citeren, ook wanneer elke belangrijke stap succes teruggaf. Een tunnel die tot stand komt en verkeer draagt terwijl hij deze waarschuwing afdrukt, past precies bij het mechanisme hierboven.

Controleer de mount en de route voordat u rechten toevoegt

Drie uitlezingen scheiden een cosmetische waarschuwing van een echte storing: of het geïnstalleerde script de regel nog bevat, hoe /proc/sys is gemount, en waar het verkeer van de applicatie echt heen gaat. Voer ze uit in dezelfde containernaamruimte of op de host waar de waarschuwing verscheen, want een controle op een ongerelateerde machine beantwoordt een andere vraag.

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

Het grep-antwoord is zwakker dan het lijkt, want een treffer bewijst dat de regel aanwezig is, niet dat hij onbeschermd draait; een onderhouden script kan de schrijfactie binnen een guard dragen die hem overslaat. findmnt -no OPTIONS /proc/sys beslecht de mount direct, en ro in die uitvoer betekent dat elke schrijfactie onder dat punt wordt geweigerd, wat het script ook doet. De route-opzoeking laat vervolgens zien of de bestemming die de applicatie nodig heeft via de tunnelinterface of via de standaardgateway van de container wordt opgelost. Een opzoeking die de standaardgateway kiest, betekent dat de tunnel omhoog kwam en er niets naartoe wordt gerouteerd, wat een routingprobleem is en geen rechtenprobleem.

Waar de oplossing echt vandaan komt

De onderhouden oplossing zit in het script en niet in de containerflags. De upstream vpnc-script is veranderd in hoe hij deze handeling afhandelt, dus vergelijk de kopie in de image met de huidige upstream en werk bij via het pakket of de imagebuild die hem levert. Een met de hand bewerkt bestand in een draaiende container is niet te reviewen en overleeft de volgende build niet.

--privileged staat gedocumenteerd als het verlenen van alle capabilities plus brede apparaattoegang, een grote concessie voor een bericht dat niets verandert, dus noem de ontbrekende capability als er echt een ontbreekt. Herhaal na de update de route-opzoeking en laat een applicatie de tunnel gebruiken, want een stil log en een werkende verbinding zijn aparte resultaten.