कन्टेनरमा 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 लाई सबै क्षमता र उपकरणमा व्यापक पहुँच दिने भनी अभिलेख गरिएको छ, जुन केही नबदल्ने सन्देशका लागि ठूलो छुट हो, त्यसैले साँच्चै कुनै क्षमता छुटेको भए त्यसको नाम भन्नुहोस्। अद्यावधिकपछि रुट खोज दोहोर्‍याउनुहोस् र एप्लिकेसनलाई टनेल प्रयोग गर्न दिनुहोस्, किनकि शान्त लग र काम गर्ने जडान भिन्न-भिन्न नतिजा हुन्।