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