Hvorfor vpnc-advarslen om ruteoprydning dukker op i en container

Friske containerlogfiler ender ofte med en Read-only file system-klage over /proc/sys/net/ipv4/route/flush, og den linje får skylden for en tunnel, der kan være helt sund. Skrivningen bag den rammer en kernel-post, der ikke længere gør noget nyttigt, nu hvor IPv4-rutecachen er væk. Inde i en container monteres /proc/sys skrivebeskyttet, så omdirigeringen afvises, før nogen værdi lander, og shellen udskriver den afvisning. En fungerende tunnel kan udskrive denne advarsel, så længe den gamle linje bliver i scriptet, og --privileged gør aldrig skrivningen meningsfuld.

Hvad scriptet prøvede at rydde

Ældre forbindelsesscripts sluttede med en cacheoprydning: skriv en værdi i en kernel-kontrolfil, og bed IPv4-stakken om at droppe sin rutecache, så en ny tunnelrute blev valgt uden at vente på, at forældede poster udløb. Filen blev adresseret under /proc/sys/net/ipv4/, hvilket gjorde handlingen til en shell-omdirigering i stedet for en rute-kommando. Kerne 3.6 fjernede den cache og dermed grunden til, at oprydningen fandtes. Intet i den nuværende datasti afhænger af den skrivning.

Posten selv overlevede som en gammel skrivebeskyttet fil, så et script, der stadig skriver til den, når en rigtig sti og en rigtig tilladelseskontrol. På en vært returnerer skrivningen succes og ændrer intet. I en container rammer den samme omdirigering en skrivebeskyttet /proc/sys og fejler med EROFS, som shellen udskriver som filsystemets skrivebeskyttede besked. På kerner, hvor stien virkelig mangler, bliver formuleringen No such file or directory, og konklusionen ændrer sig ikke.

De to fejl siger forskellige ting, og forskellen er værd at holde styr på. Read-only file system betyder, at kernen nåede en post og afviste skrivningen; No such file or directory betyder, at posten er væk. Ingen af beskederne rapporterer om tunnel-enheden, ruterne eller navneopløsningen, så ingen af dem kan retfærdiggøre flere privilegier.

Det er rækkefølgen, der får beskeden til at se kausal ud. Et forbindelsesscript installerer ruter, ændrer grænsefladetilstand og omskriver navneopløsningen, før det når oprydningen til sidst, så den sidste udskrevne linje er den, folk citerer, selv når hvert vigtigt trin returnerede succes. En tunnel, der etableres og bærer trafik, mens den udskriver denne advarsel, passer præcis på mekanismen ovenfor.

Kontroller mountet og ruten, før du tilføjer privilegier

Tre læsninger skiller en kosmetisk advarsel fra en rigtig fejl: om det installerede script stadig bærer linjen, hvordan /proc/sys er monteret, og hvor applikationens trafik faktisk går hen. Kør dem i det samme container-navnerum eller på den vært, hvor advarslen dukkede op, fordi en kontrol på en uvedkommende maskine besvarer et andet spørgsmå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 svagere, end det ser ud, fordi et hit beviser, at linjen findes, ikke at den kører ubeskyttet; et vedligeholdt script kan bære skrivningen inde i en vagt, der springer den over. findmnt -no OPTIONS /proc/sys afgør mountet direkte, og ro i det output betyder, at enhver skrivning under det punkt afvises, uanset hvad scriptet gør. Ruteopslaget viser derefter, om det mål, applikationen har brug for, løses via tunnelgrænsefladen eller via containerens standardgateway. Et opslag, der vælger standardgatewayen, betyder, at tunnelen kom op, og at intet ruter ind i den, hvilket er et ruteproblem og ikke et privilegieproblem.

Hvor rettelsen faktisk kommer fra

Den vedligeholdte rettelse ligger i scriptet og ikke i containerflagene. upstream vpnc-script har ændret, hvordan det håndterer denne handling, så sammenlign kopien inde i imaget med det aktuelle upstream og opdater via den pakke eller image-build, der leverer den. En håndredigeret fil i en kørende container kan ikke revideres og overlever ikke næste build.

--privileged er dokumenteret som at give alle capabilities plus bred enhedsadgang, en stor indrømmelse for en besked, der intet ændrer, så navngiv den manglende capability i stedet, hvis en reelt mangler. Efter opdateringen gentages ruteopslaget, og lad en applikation bruge tunnelen, fordi en stille log og en fungerende forbindelse er to forskellige resultater.