Varför vpnc-varningen om ruttcache-tömning dyker upp i en container

Färska containerloggar slutar ofta på en Read-only file system-klagan över /proc/sys/net/ipv4/route/flush, och den raden får skulden för en tunnel som kan vara helt frisk. Skrivningen bakom den träffar en kärnpost som inte längre gör något nyttigt nu när IPv4-ruttcachen är borta. Inuti en container monteras /proc/sys skrivskyddat, så omdirigeringen avvisas innan något värde landar och skalet skriver ut den avvisningen. En fungerande tunnel kan skriva ut den här varningen så länge den gamla raden finns kvar i skriptet, och --privileged gör aldrig skrivningen meningsfull.

Vad skriptet försökte tömma

Äldre anslutningsskript slutade med en cachestädning: skriva ett värde till en kärnkontrollfil och be IPv4-stacken släppa sin ruttcache, så att en ny tunnelrutt valdes utan att vänta på att inaktuella poster löpte ut. Filen adresserades under /proc/sys/net/ipv4/, vilket gjorde åtgärden till en skalomdirigering i stället för ett ruttkommando. Kärna 3.6 tog bort den cachen, och med den anledningen till att tömningen fanns. Inget i den nuvarande datavägen är beroende av den skrivningen.

Själva posten överlevde som en gammal skrivskyddad fil, så ett skript som fortfarande skriver till den når en riktig sökväg och en riktig behörighetskontroll. På en värd returnerar skrivningen framgång och ändrar ingenting. I en container träffar samma omdirigering en skrivskyddad /proc/sys och misslyckas med EROFS, som skalet skriver ut som filsystemets skrivskyddade meddelande. På kärnor där sökvägen verkligen saknas blir formuleringen No such file or directory, och slutsatsen ändras inte.

De två felen säger olika saker, och skillnaden är värd att hålla klar. Read-only file system betyder att kärnan nådde en post och avvisade skrivningen; No such file or directory betyder att posten är borta. Inget av meddelandena rapporterar om tunnelenheten, rutterna eller namnmatchningen, så inget av dem kan motivera mer behörighet.

Det är ordningen som får meddelandet att se kausalt ut. Ett anslutningsskript installerar rutter, ändrar gränssnittstillstånd och skriver om namnmatchningen innan det når städningen på slutet, så den sista utskrivna raden är den som folk citerar även när varje viktigt steg returnerade framgång. En tunnel som etableras och bär trafik medan den skriver ut den här varningen passar exakt in på mekanismen ovan.

Kontrollera monteringen och rutten innan du lägger till behörighet

Tre läsningar skiljer en kosmetisk varning från ett verkligt fel: om det installerade skriptet fortfarande bär raden, hur /proc/sys är monterad och vart applikationens trafik faktiskt tar vägen. Kör dem i samma containerns namnrymd eller på värden där varningen dök upp, eftersom en kontroll på en orelaterad maskin svarar på en annan fråga.

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

grep-svaret är svagare än det ser ut, eftersom en träff bevisar att raden finns, inte att den körs oskyddat; ett underhållet skript kan bära skrivningen inuti en vakt som hoppar över den. findmnt -no OPTIONS /proc/sys avgör monteringen direkt, och ro i den utskriften betyder att varje skrivning under den punkten avvisas, vad skriptet än gör. Ruttuppslagningen visar sedan om målet som applikationen behöver löses via tunnelgränssnittet eller via containerns standardgateway. En uppslagning som väljer standardgatewayen betyder att tunneln kom upp och ingenting routas in i den, vilket är ett ruttproblem och inte ett behörighetsproblem.

Varifrån rättelsen faktiskt kommer

Den underhållna rättelsen bor i skriptet och inte i containerflaggorna. upstream vpnc-script har ändrat hur det hanterar den här åtgärden, så jämför kopian i avbilden med nuvarande upstream och uppdatera via paketet eller avbildsbygget som levererar det. En handredigerad fil i en körande container kan inte granskas och överlever inte nästa bygge.

--privileged är dokumenterat som att ge alla kapabiliteter plus bred enhetsåtkomst, en stor eftergift för ett meddelande som inte ändrar något, så namnge den saknade kapabiliteten i stället om en faktiskt saknas. Efter uppdateringen upprepar du ruttuppslagningen och låter en applikation använda tunneln, eftersom en tyst logg och en fungerande anslutning är separata resultat.