कंटेनरमध्ये vpnc रूट-फ्लश चेतावणी का येते

नवीन कंटेनर लॉग बहुतेकदा /proc/sys/net/ipv4/route/flush बद्दल Read-only file system तक्रारीवर संपतात, आणि त्या ओळीवर पूर्णपणे निरोगी असू शकणाऱ्या टनेलचा दोष मढवला जातो. तिच्या मागील लेखन IPv4 रूट कॅशे गेल्यानंतर काहीही उपयुक्त न करणाऱ्या कर्नेल नोंदीला लक्ष्य करते. कंटेनरच्या आत /proc/sys फक्त-वाचन म्हणून माउंट होते, त्यामुळे कोणतेही मूल्य पोहोचण्यापूर्वीच पुनर्निर्देशन नाकारले जाते आणि शेल ते नाकारणे छापते. कार्यरत टनेल जुनी ओळ स्क्रिप्टमध्ये राहिल्यास ही चेतावणी छापू शकते, आणि --privileged लेखनाला कधीही अर्थपूर्ण करत नाही.

स्क्रिप्ट काय फ्लश करू इच्छित होती

जुन्या कनेक्शन स्क्रिप्ट कॅशे साफसफाईने संपत असत: कर्नेल नियंत्रण फाइलमध्ये मूल्य लिहिणे आणि IPv4 स्टॅकला त्याचा राउटिंग कॅशे टाकून देण्यास सांगणे, जेणेकरून जुन्या नोंदी कालबाह्य होण्याची वाट न पाहता नवीन टनेल मार्ग निवडला जाईल. फाइल /proc/sys/net/ipv4/ अंतर्गत पत्ता दिला होता, ज्यामुळे क्रिया राउटिंग आदेशाऐवजी शेल पुनर्निर्देशन बनली. कर्नेल 3.6 ने तो कॅशे काढून टाकला, आणि त्यासोबत फ्लशच्या अस्तित्वाचे कारणही. सध्याच्या डेटा मार्गातील काहीही त्या लेखनावर अवलंबून नाही.

नोंद स्वतः जुन्या फक्त-लेखन फाइल म्हणून टिकून राहिली, त्यामुळे अजूनही तिच्यात लिहिणारी स्क्रिप्ट खऱ्या मार्गापर्यंत आणि खऱ्या परवानगी तपासणीपर्यंत पोहोचते. होस्टवर लेखन यश परत करते आणि काहीही बदलत नाही. कंटेनरमध्ये तेच पुनर्निर्देशन फक्त-वाचन /proc/sys ला धडकते आणि EROFS ने अयशस्वी होते, जे शेल फक्त-वाचन फाइलसिस्टम संदेश म्हणून छापते. मार्ग खरोखर नसलेल्या कर्नेलवर शब्दरचना No such file or directory होते, आणि निष्कर्ष बदलत नाही.

दोन्ही त्रुटी वेगळ्या गोष्टी सांगतात, आणि फरक स्पष्ट ठेवणे योग्य आहे. Read-only file system म्हणजे कर्नेल नोंदीपर्यंत पोहोचले आणि लेखन नाकारले; No such file or directory म्हणजे नोंद गेली. कोणताही संदेश टनेल उपकरण, मार्ग किंवा नाव-निराकरणाबद्दल अहवाल देत नाही, त्यामुळे कोणताही अधिक विशेषाधिकार न्याय्य ठरवू शकत नाही.

संदेशाला कारणासारखा दिसण्यासाठी क्रम कारणीभूत आहे. कनेक्शन स्क्रिप्ट शेवटच्या साफसफाईपर्यंत पोहोचण्यापूर्वी मार्ग स्थापित करते, इंटरफेस स्थिती बदलते आणि नाव-निराकरण पुन्हा लिहिते, त्यामुळे शेवटी छापलेली ओळच लोक उद्धृत करतात, प्रत्येक महत्त्वाची पायरी यश परत देत असली तरीही. ही चेतावणी छापत असताना स्थिरावणारे आणि रहदारी वाहणारे टनेल वरील यंत्रणेशी तंतोतंत जुळते.

विशेषाधिकार जोडण्यापूर्वी माउंट आणि मार्ग तपासा

तीन वाचन बाह्य चेतावणीला खऱ्या अपयशापासून वेगळे करतात: स्थापित स्क्रिप्ट अजूनही ओळ घेते का, /proc/sys कसे माउंट आहे, आणि अ‍ॅप्लिकेशनची रहदारी खरोखर कुठे जाते. ती त्याच कंटेनर नेमस्पेसमध्ये किंवा चेतावणी दिसलेल्या होस्टवर चालवा, कारण असंबंधित मशीनवरील तपासणी वेगळ्या प्रश्नाचे उत्तर देते.

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 चे उत्तर दिसते त्यापेक्षा कमकुवत आहे, कारण सापडणे ओळ असल्याचे सिद्ध करते, ती संरक्षणाशिवाय चालते हे नाही; देखभाल केलेली स्क्रिप्ट लेखनाला ते वगळणाऱ्या रक्षकाच्या आत ठेवू शकते. findmnt -no OPTIONS /proc/sys माउंट थेट ठरवते, आणि त्या आउटपुटमधील ro म्हणजे त्या बिंदूखालील प्रत्येक लेखन नाकारले जाते, स्क्रिप्ट काहीही करो. त्यानंतर मार्ग शोध दाखवतो की अ‍ॅप्लिकेशनला आवश्यक गंतव्य टनेल इंटरफेसद्वारे ठरते की कंटेनरच्या डीफॉल्ट गेटवेमार्फत. डीफॉल्ट गेटवे निवडणारा शोध म्हणजे टनेल वर आले आणि त्यात काहीही मार्गस्थ होत नाही, ही राउटिंग समस्या आहे, विशेषाधिकाराची नाही.

दुरुस्ती खरोखर कुठून येते

देखभाल केलेली दुरुस्ती कंटेनर फ्लॅगमध्ये नाही, स्क्रिप्टमध्ये राहते. upstream vpnc-script ने ही क्रिया कशी हाताळते ते बदलले आहे, त्यामुळे इमेजमधील प्रत सध्याच्या upstream शी तुलना करा आणि ती पुरवणाऱ्या पॅकेज किंवा इमेज बिल्डद्वारे अद्ययावत करा. चालू कंटेनरमध्ये हाताने संपादित फाइल पुनरावलोकनयोग्य नाही आणि पुढील बिल्डपर्यंत टिकणार नाही.

--privileged सर्व क्षमता आणि उपकरणांना व्यापक प्रवेश देते असे नोंदवले आहे, हे काहीही न बदलणाऱ्या संदेशासाठी मोठी सवलत आहे, त्यामुळे खरोखर क्षमता कमी असल्यास तिचे नाव घ्या. अद्ययावतानंतर मार्ग शोध पुन्हा करा आणि अ‍ॅप्लिकेशनला टनेल वापरू द्या, कारण शांत लॉग आणि कार्यरत कनेक्शन वेगवेगळे निकाल आहेत.