Jurnalele proaspete de container se termină adesea cu o plângere Read-only file system despre /proc/sys/net/ipv4/route/flush, iar acea linie primește vina pentru un tunel care poate fi perfect sănătos. Scrierea din spatele ei vizează o intrare de nucleu care nu mai face nimic util de când cache-ul de rute IPv4 a dispărut. În interiorul unui container, /proc/sys este montat doar-citire, așa că redirecționarea este refuzată înainte să ajungă vreo valoare, iar shell-ul tipărește acel refuz. Un tunel funcțional poate tipări acest avertisment atâta timp cât linia veche rămâne în script, iar --privileged nu face niciodată scrierea semnificativă.

Ce încerca scriptul să golească

Scripturile de conectare mai vechi se terminau cu o curățare a cache-ului: scriau o valoare într-un fișier de control al nucleului și cereau stivei IPv4 să-și arunce cache-ul de rutare, astfel încât o rută nouă de tunel să fie aleasă fără a aștepta expirarea intrărilor învechite. Fișierul era adresat sub /proc/sys/net/ipv4/, ceea ce făcea operația o redirecționare de shell, nu o comandă de rutare. Nucleul 3.6 a eliminat acel cache, și odată cu el motivul existenței golirii. Nimic din calea actuală de date nu depinde de acea scriere.

Intrarea în sine a supraviețuit ca fișier vechi doar-scriere, așa că un script care încă scrie în el ajunge la o cale reală și la o verificare reală a permisiunilor. Pe un host scrierea returnează succes și nu schimbă nimic. Într-un container aceeași redirecționare lovește un /proc/sys doar-citire și eșuează cu EROFS, pe care shell-ul îl tipărește ca mesaj de sistem de fișiere doar-citire. Pe nuclee unde calea chiar lipsește, formularea devine No such file or directory, iar concluzia nu se schimbă.

Cele două erori spun lucruri diferite, iar diferența merită păstrată clar. Read-only file system înseamnă că nucleul a ajuns la o intrare și a refuzat scrierea; No such file or directory înseamnă că intrarea a dispărut. Niciun mesaj nu raportează despre dispozitivul tunelului, rute sau rezolvarea numelor, așa că niciunul nu poate justifica mai multe privilegii.

Ordinea este cea care face mesajul să pară cauzal. Un script de conectare instalează rute, schimbă starea interfeței și rescrie rezolvarea numelor înainte de a ajunge la curățarea de la final, așa că ultima linie tipărită este cea pe care oamenii o citează chiar și când fiecare pas important a returnat succes. Un tunel care se stabilește și transportă trafic în timp ce tipărește acest avertisment corespunde exact mecanismului de mai sus.

Verificați montarea și ruta înainte de a adăuga privilegii

Trei citiri separă un avertisment cosmetic de o defecțiune reală: dacă scriptul instalat mai poartă linia, cum este montat /proc/sys și unde merge de fapt traficul aplicației. Rulați-le în același namespace al containerului sau pe hostul unde a apărut avertismentul, pentru că o verificare pe o mașină nelegată răspunde la altă întrebare.

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

Răspunsul grep este mai slab decât pare, pentru că o potrivire dovedește că linia există, nu că rulează fără protecție; un script întreținut poate purta scrierea într-o gardă care o sare. findmnt -no OPTIONS /proc/sys rezolvă montarea direct, iar ro în acea ieșire înseamnă că orice scriere sub acel punct este refuzată, orice ar face scriptul. Apoi căutarea rutei arată dacă destinația de care are nevoie aplicația este rezolvată prin interfața tunelului sau prin gateway-ul implicit al containerului. O căutare care alege gateway-ul implicit înseamnă că tunelul a urcat și nimic nu este rutat în el, ceea ce este o problemă de rutare, nu de privilegii.

De unde vine de fapt corectura

Corectura întreținută trăiește în script, nu în steagurile containerului. vpnc-script upstream a schimbat modul în care tratează această operație, așa că comparați copia din imagine cu upstream-ul actual și actualizați prin pachetul sau construcția de imagine care o furnizează. Un fișier editat manual într-un container care rulează nu poate fi revizuit și nu va supraviețui următoarei construcții.

--privileged este documentat ca acordând toate capabilitățile plus acces larg la dispozitive, o concesie mare pentru un mesaj care nu schimbă nimic, așa că numiți capabilitatea lipsă dacă una chiar lipsește. După actualizare, repetați căutarea rutei și lăsați o aplicație să folosească tunelul, pentru că un jurnal liniștit și o conexiune funcțională sunt rezultate separate.

Articole similare