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 स्क्रिप्टमध्ये ती चल उपलब्ध असतात; cron कामातून किंवा हाताने चालवलेल्या शेलमधून नसतात। तुमची आवृत्ती कोणता जीवनचक्र हुक वापरते आणि हुक इंटरफेस बदलण्यापुरते विशेषाधिकार घेऊन चालतो याची खात्री करा, कारण क्लायंट आधीच अनधिकृत वापरकर्त्याकडे उतरलेला असू शकतो।
एक सत्र नाही, संपूर्ण जीवनचक्र तपासा
टनेल वर आणा, उपकरणावरील पत्ता तपासा, मग पुन्हा कनेक्ट करा आणि पुन्हा तपासा। एकदा चालून दुसऱ्या प्रयत्नात अयशस्वी होणाऱ्या संरचनेचा अर्थ सहसा असा असतो की सोपवलेली पायरी फक्त पहिल्या कनेक्शनवर चालते।
मग दोन्ही स्वीकृती निकष एकत्र तपासा: इच्छित व्यवस्थापन मार्गाने नवीन SSH कनेक्शन चालते, आणि परवानगी दिलेले अनुप्रयोग टनेल योग्यरीत्या वापरते।
टनेलला पत्ता नसताना जुने SSH सत्र योगायोगाने टिकून राहणे हे यश नाही, आणि कोणीही काम स्वीकारत नाही तेव्हा हा पर्याय नेमकी तीच अवस्था निर्माण करतो। आधी इंटरफेसचा पत्ता, नंतर व्यवस्थापन उत्तर मार्ग, नंतर अनुप्रयोग तपासा। तीनपैकी दोन चुकीचे असतील, तर पर्यायाने काम हलवले पण त्याला मालक दिला नाही।