Miért jelenik meg a vpnc útvonal-törlési figyelmeztetése egy kontánerben

A friss konténer-naplók gyakran egy Read-only file system panasszal végződnek a /proc/sys/net/ipv4/route/flush miatt, és ezt a sort okolják egy olyan alagútért, amely teljesen egészséges lehet. A mögötte lévő írás egy olyan kernelbejegyzést céloz, amely már semmi hasznosat nem tesz, mióta az IPv4 útvonal-gyorsítótár eltűnt. Egy konténeren belül a /proc/sys csak olvashatóként van csatolva, ezért az átirányítás elutasításra kerül, mielőtt bármilyen érték megérkezne, és a shell kiírja ezt az elutasítást. Egy működő alagút addig nyomtathatja ezt a figyelmeztetést, amíg a régi sor a szkriptben marad, és a --privileged soha nem teszi értelmessé az írást.

Mit próbált törölni a szkript

A régebbi kapcsolat-szkriptek gyorsítótár-tisztítással végződtek: értéket írtak egy kernel-vezérlőfájlba, és megkérték az IPv4 vermet, hogy dobja el az útválasztási gyorsítótárát, így az új alagút-útvonal kiválasztása nem várt az elavult bejegyzések lejártára. A fájlt a /proc/sys/net/ipv4/ alatt címezték, ami a műveletet shell-átirányítássá tette útválasztási parancs helyett. A 3.6-os kernel eltávolította ezt a gyorsítótárat, és vele a törlés létezésének okát. A jelenlegi adatútban semmi sem függ ettől az írástól.

Maga a bejegyzés örökölt, csak írható fájlként maradt fenn, ezért az a szkript, amely még mindig beleír, valódi útvonalat és valódi jogosultság-ellenőrzést ér el. Egy hoszton az írás sikert ad vissza, és semmit nem változtat. Egy konténerben ugyanez az átirányítás egy csak olvasható /proc/sys-be ütközik, és EROFS hibával meghiúsul, amelyet a shell a csak olvasható fájlrendszer üzeneteként ír ki. Azokon a kerneleken, ahol az útvonal valóban hiányzik, a megfogalmazás No such file or directory lesz, és a következtetés nem változik.

A két hiba különböző dolgokat mond, és érdemes tisztán tartani a különbséget. A Read-only file system azt jelenti, hogy a kernel elért egy bejegyzést, és megtagadta az írást; a No such file or directory azt jelenti, hogy a bejegyzés eltűnt. Egyik üzenet sem jelent az alagút-eszközről, az útvonalakról vagy a névfeloldásról, ezért egyik sem igazolhat több jogosultságot.

A sorrend az, amitől az üzenet okozatinak látszik. Egy kapcsolat-szkript útvonalakat telepít, megváltoztatja az interfész állapotát és átírja a névfeloldást, mielőtt eléri a végi tisztítást, ezért az utoljára kiírt sor az, amelyet az emberek idéznek, akkor is, ha minden fontos lépés sikert adott vissza. Az az alagút, amely felépül és forgalmat visz, miközben ezt a figyelmeztetést nyomtatja, pontosan megfelel a fenti mechanizmusnak.

Ellenőrizze a csatolást és az útvonalat, mielőtt jogosultságot ad hozzá

Három olvasás választja el a kozmetikai figyelmeztetést a valódi hibától: hogy a telepített szkript még tartalmazza-e a sort, hogyan van csatolva a /proc/sys, és hová megy valójában az alkalmazás forgalma. Ugyanabban a konténer-névtérben vagy azon a hoszton futtassa őket, ahol a figyelmeztetés megjelent, mert egy nem kapcsolódó gépen végzett ellenőrzés más kérdésre válaszol.

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

A grep válasza gyengébb, mint amilyennek látszik, mert egy találat azt bizonyítja, hogy a sor jelen van, nem azt, hogy védelem nélkül fut; egy karbantartott szkript a védelem belsejében hordozhatja az írást, amely kihagyja azt. A findmnt -no OPTIONS /proc/sys közvetlenül eldönti a csatolást, és az abban a kimenetben szereplő ro azt jelenti, hogy az adott pont alatti minden írás elutasításra kerül, bármit is tesz a szkript. Ezután az útvonal-keresés megmutatja, hogy az alkalmazás által igényelt cél az alagút-interfészen vagy a konténer alapértelmezett átjáróján keresztül oldódik-e fel. Az alapértelmezett átjárót választó keresés azt jelenti, hogy az alagút feljött, és semmi nem irányít bele, ami útválasztási probléma, nem jogosultsági.

Honnan származik valójában a javítás

A karbantartott javítás a szkriptben él, nem a konténer kapcsolóiban. Az upstream vpnc-script megváltoztatta, hogyan kezeli ezt a műveletet, ezért hasonlítsa össze a képen belüli példányt a jelenlegi upstreammel, és frissítsen azon a csomagon vagy képpépítésen keresztül, amely biztosítja. Egy futó konténeren belül kézzel szerkesztett fájl nem ellenőrizhető, és nem éli túl a következő buildet.

A --privileged dokumentáltan minden képességet és széles eszközhozzáférést biztosít, ami nagy engedmény egy semmit nem változtató üzenetért, ezért nevezze meg a hiányzó képességet, ha valóban hiányzik egy. A frissítés után ismételje meg az útvonal-keresést, és hagyja, hogy egy alkalmazás használja az alagutat, mert a csendes napló és a működő kapcsolat külön eredmények.