Hvorfor vpnc-rutevarselen om cachetømming dukker opp i en container

Ferske containerlogger ender ofte på en Read-only file system-klage over /proc/sys/net/ipv4/route/flush, og den linjen får skylden for en tunnel som kan være helt sunn. Skrivingen bak den treffer en kjerneoppføring som ikke lenger gjør noe nyttig nå som IPv4-rutecachen er borte. Inne i en container monteres /proc/sys skrivebeskyttet, så omdirigeringen avvises før noen verdi lander, og skallet skriver ut den avvisningen. En fungerende tunnel kan skrive ut denne advarselen så lenge den gamle linjen blir værende i skriptet, og --privileged gjør aldri skrivingen meningsfull.

Hva skriptet prøvde å tømme

Eldre tilkoblingsskript sluttet med en cacheopprydding: skrive en verdi til en kjernekontrollfil og be IPv4-stakken om å forkaste rutecachen sin, slik at en ny tunnelrute ble valgt uten å vente på at utdaterte oppføringer utløp. Filen ble adressert under /proc/sys/net/ipv4/, noe som gjorde operasjonen til en skallomdirigering i stedet for en rutekommando. Kjerne 3.6 fjernet den cachen, og med den grunnen til at tømmingen fantes. Ingenting i den nåværende databanen er avhengig av den skrivingen.

Oppføringen selv overlevde som en gammel skrivebeskyttet fil, så et skript som fortsatt skriver til den, når en ekte sti og en ekte tillatelseskontroll. På en vert returnerer skrivingen suksess og endrer ingenting. I en container treffer samme omdirigering en skrivebeskyttet /proc/sys og feiler med EROFS, som skallet skriver ut som filsystemets skrivebeskyttede melding. På kjerner der stien virkelig mangler, blir ordlyden No such file or directory, og konklusjonen endres ikke.

De to feilene sier forskjellige ting, og forskjellen er verdt å holde klar. Read-only file system betyr at kjernen nådde en oppføring og avviste skrivingen; No such file or directory betyr at oppføringen er borte. Ingen av meldingene rapporterer om tunnelenheten, rutene eller navneoppslaget, så ingen av dem kan rettferdiggjøre mer privilegium.

Det er rekkefølgen som får meldingen til å se kausal ut. Et tilkoblingsskript installerer ruter, endrer grensesnitttilstand og skriver navneoppslaget på nytt før det når oppryddingen til slutt, så den siste linjen som skrives ut, er den folk siterer selv når hvert viktig trinn returnerte suksess. En tunnel som etableres og bærer trafikk mens den skriver ut denne advarselen, passer nøyaktig til mekanismen ovenfor.

Kontroller monteringen og ruten før du legger til privilegium

Tre lesinger skiller en kosmetisk advarsel fra en ekte feil: om det installerte skriptet fortsatt bærer linjen, hvordan /proc/sys er montert, og hvor applikasjonens trafikk faktisk går. Kjør dem i samme containernavnerom eller på verten der advarselen dukket opp, fordi en kontroll på en urelatert maskin svarer på et annet spørsmål.

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 er svakere enn det ser ut, fordi et treff beviser at linjen finnes, ikke at den kjører ubeskyttet; et vedlikeholdt skript kan bære skrivingen inne i en vakt som hopper over den. findmnt -no OPTIONS /proc/sys avgjør monteringen direkte, og ro i den utskriften betyr at hver skriving under det punktet avvises, uansett hva skriptet gjør. Ruteoppslaget viser deretter om målet applikasjonen trenger, løses gjennom tunellgrensesnittet eller gjennom containerens standard gateway. Et oppslag som velger standard gateway, betyr at tunnelen kom opp og ingenting rutes inn i den, noe som er et ruteproblem og ikke et privilegieproblem.

Hvor rettelsen faktisk kommer fra

Den vedlikeholdte rettelsen ligger i skriptet og ikke i containerflaggene. upstream vpnc-script har endret hvordan det håndterer denne operasjonen, så sammenlign kopien i imaget med gjeldende upstream og oppdater via pakken eller imagebyggingen som leverer den. En håndredigert fil i en kjørende container kan ikke gjennomgås og overlever ikke neste bygg.

--privileged er dokumentert som å gi alle capabilities pluss bred enhetstilgang, en stor innrømmelse for en melding som ikke endrer noe, så navngi den manglende capabilityen i stedet hvis en faktisk mangler. Etter oppdateringen gjentar du ruteoppslaget og lar en applikasjon bruke tunnelen, fordi en stille logg og en fungerende tilkobling er separate resultater.