ifconfig-noexec आपका SSH सत्र नहीं बचाता: यह वास्तव में क्या करता है
यह OpenVPN की अपनी इंटरफ़ेस पता सेटिंग को दबा देता है। यह SSH के लिए उत्तर मार्ग आरक्षित नहीं करता, हर मार्ग परिवर्तन बंद नहीं करता और गायब पता नहीं देता।
किसी फ़ोरम थ्रेड में, ifconfig-noexec को ऐसा उपाय बताया जाता है जो सुरंग उठने पर SSH सत्र को जीवित रखता है। यह तर्क तब तक उचित लगता है जब तक आप यह न देखें कि यह विकल्प किस चीज़ को छूता है। यह OpenVPN को सुरंग इंटरफ़ेस का पता सेट करने से रोकता है और वे मान स्क्रिप्ट को सौंप देता है; आपके प्रबंधन कनेक्शन के उत्तर कहाँ जाते हैं, इस पर यह कुछ नहीं कहता। उल्टा मानने पर ऐसी सुरंग बनती है जिसका कोई उपयोगी पता नहीं होता और SSH सत्र फिर भी मर जाता है।
यह विकल्प वास्तव में क्या सौंपता है
डिफ़ॉल्ट रूप से क्लाइंट सुरंग उपकरण को उठाता है और सर्वर द्वारा दिए गए स्थानीय तथा दूरस्थ पते निर्दिष्ट करता है। ifconfig-noexec सेट होने पर वह चरण छोड़ दिया जाता है और तय किए गए मान स्क्रिप्ट परिवेश में निर्यात कर दिए जाते हैं ताकि कोई और उन्हें लागू कर सके।
स्वामित्व बदल जाता है। उसकी जगह कुछ भी नया नहीं गढ़ा जाता।
तो यह विकल्प जिस सवाल का जवाब देता है वह है कि इंटरफ़ेस कौन सेट करता है, और जिस सवाल का जवाब यह नहीं देता वह है कि पैकेट आप तक वापस कैसे पहुँचते हैं। इन दोनों को अलग रखें, वरना बिना पते वाले इंटरफ़ेस की भरपाई के लिए आप पूरी शाम मार्ग संपादित करते रहेंगे।
अलग-अलग कामों वाले तीन मिलते-जुलते विकल्प
इस परिवार में उलझना आसान है क्योंकि नाम एक शब्द से अलग हैं और लक्षण एक-दूसरे पर चढ़ते हैं। कोई भी चुनने से पहले पढ़ें कि हर एक क्या दबाता है।
| Option | What stops happening |
|---|---|
ifconfig-noexec | OpenVPN's own tunnel-address configuration; values go to scripts instead |
route-noexec | Automatic route addition and removal; route details go to a script |
route-nopull | Server-pushed routes and related options such as DNS are rejected |
ये अलग-अलग समझने के विकल्प हैं, एक साथ चिपकाने का समूह नहीं। पता सेटिंग दबाने से मार्ग परिवर्तन, फ़ायरवॉल नियम या DNS ले जाने वाले धकेले गए विकल्प नहीं दबते। सौंपी गई स्क्रिप्ट भी मार्ग बदलने को स्वतंत्र है, जो टालने के बजाय आप सौंप रहे हैं।
अगर कोई विक्रेता क्लाइंट इंजन को लपेटता है, तो प्रोफ़ाइल में निचले स्तर का निर्देश डालकर यह आशा करने के बजाय कि रैपर उसका सम्मान करेगा, उसका समर्थित एकीकरण इस्तेमाल करें। रैपर अक्सर कनेक्ट पर प्रोफ़ाइल फिर से बनाते हैं, इसलिए हाथ से किया बदलाव बिना त्रुटि के गायब हो जाता है। फ़ाइल पर पूरी शाम लगाने से पहले जाँचें कि क्लाइंट अपनी सेटिंग कहाँ रखता है। यह तालिका की हर पंक्ति पर लागू होता है, सिर्फ़ उस पर नहीं जिसके लिए आप आए थे।
वह SSH सत्र जिसे आप बचाना चाहते थे
SSH कनेक्शन में स्रोत पता, गंतव्य पता और उत्तर मार्ग होता है। ऐसे सर्वर पर जिसने अभी पूर्ण-सुरंग डिफ़ॉल्ट लगाया है, आपके सार्वजनिक पते का उत्तर सुरंग से मेल खाता है और VPN गेटवे उसे गिरा देता है।
सुरंग इंटरफ़ेस की पता सेटिंग में कुछ भी यह नहीं बदलता।
इसे ठीक वह करता है: सुरंग से पहले के गेटवे से होकर आपके प्रबंधन पते के लिए अधिक विशिष्ट मार्ग, या ऐसा नीति नियम जो उस ट्रैफ़िक को मोड़े, साथ में वे फ़िल्टर सेटिंग जो आपका होस्ट लागू करता है। दोनों समस्याएँ कभी-कभी साथ दिखती हैं, और इसी तरह एक को दूसरे का इलाज समझ लिया जाता है। इन्हें अलग-अलग जाँचें: विकल्प के बिना सुरंग उठाएँ, इंटरफ़ेस का पता और उत्तर मार्ग देखें, फिर तय करें कि दोनों में से कौन वास्तव में टूटा है।
सौंपी गई स्क्रिप्ट को क्या संभालना होता है
अगर आप सचमुच चाहते हैं कि कोई और मालिक इंटरफ़ेस सेट करे, तो काम की सूची बनाएँ: स्थानीय और दूरस्थ पता लागू करें, उपकरण उठाएँ, टियरडाउन पर पता बहाल करें या हटाएँ, और फिर से कनेक्ट होने के बाद वही दोबारा करें। एक सफल सत्र के मान हार्डकोड न करें, क्योंकि सर्वर अगली बार दूसरी जोड़ी दे सकता है।
क्लाइंट जो परिवेश चर निर्यात करता है, वही उस काम के लिए समर्थित इनपुट है।
env | grep -E '^ifconfig_|^route_'किसी route-up स्क्रिप्ट के अंदर वे चर उपलब्ध होते हैं; क्रॉन जॉब या हाथ से चलाए गए शेल से नहीं। पुष्टि करें कि आपका संस्करण कौन-सा जीवनचक्र हुक इस्तेमाल करता है और यह भी कि हुक इंटरफ़ेस बदलने के लिए पर्याप्त विशेषाधिकार के साथ चलता है, क्योंकि क्लाइंट पहले ही गैर-विशेषाधिकार प्राप्त उपयोगकर्ता पर उतर चुका हो सकता है।
पूरा जीवनचक्र जाँचें, एक सत्र नहीं
सुरंग उठाएँ, उपकरण पर पता जाँचें, फिर से कनेक्ट करें और दोबारा जाँचें। जो कॉन्फ़िगरेशन एक बार चलकर दूसरी कोशिश में विफल हो जाता है, उसका अर्थ आमतौर पर यह होता है कि सौंपा गया चरण केवल पहले कनेक्शन पर चलता है।
फिर दोनों स्वीकृति मानदंड साथ जाँचें: इच्छित प्रबंधन मार्ग से नया SSH कनेक्शन चलता है, और अनुमत एप्लिकेशन सुरंग का सही उपयोग करता है।
पुराना SSH सत्र जो सुरंग के बिना पते के बावजूद संयोग से बचा रहता है, सफलता नहीं है, और जब कोई काम नहीं संभालता तो यह विकल्प ठीक यही स्थिति पैदा करता है। पहले इंटरफ़ेस का पता जाँचें, फिर प्रबंधन उत्तर मार्ग, फिर एप्लिकेशन। अगर तीन में से दो गलत हों, तो विकल्प ने काम को स्थानांतरित किया है पर उसे कोई मालिक नहीं दिया।