OpenVPN client-connect असफलता: disconnect मा सफाइ ग्यारेन्टी छ?
अस्वीकृत क्लाइन्टले फायरवाल नियम वा लेखिएको रेकर्ड फिर्ता गर्दैन। कलब्याक करारलाई तपाईंको hook ले आफैं गर्नुपर्ने रोलब्याकसँग तुलना गर्नुहोस्।
जब client-connect स्क्रिप्ट शून्य नभएको कोडसँग बाहिर निस्कन्छ, OpenVPN ले क्लाइन्ट अस्वीकार गर्छ, र अपरेटरहरूले सामान्यतया सम्बन्धित client-disconnect स्क्रिप्टले सबै मिलाउने ठान्छन्। प्रायः त्यो कहिल्यै चल्दैन, किनकि disconnect प्रशोधन connect चरणले के पूरा गर्न सक्यो भन्नेमा निर्भर हुन्छ। अस्वीकृति र रोलब्याकलाई एउटै कार्यविधि मान्नु नै असफल लगइनलाई चुहिएको फायरवाल नियम वा अनाथ रेकर्डमा बदल्छ। यी दुई अलग जिम्मेवारी हुन्, र तीमध्ये एउटा मात्र स्वचालित छ। सर्भरले अवस्था छोड्यो भनी दोष दिनुअघि hook को आफ्नै निकास मार्ग पढ्नुहोस्।
शून्य नभएको निकासले क्लाइन्ट अस्वीकार गर्छ; यसले तपाईंको काम फिर्ता गर्दैन
client-connect को निकास स्थिति प्रवेश निर्णय हो। शून्य भन्नाले स्वीकार, अरू जुनसुकै मान भन्नाले इन्स्टन्स पूर्ण रूपमा स्थापित हुनुअघि भत्काउनु। त्यो करारमा स्क्रिप्टले बाहिरी संसारमा पहिले नै के गर्यो भनी जाँच्ने केही छैन। यदि स्क्रिप्टले iptables नियम थप्यो, लाइन लेख्यो वा काउन्टर बढायो भने ती परिवर्तन अस्वीकृतिपछि पनि रहन्छन्।
त्यही असमानता प्लगइनहरूमा पनि लागू हुन्छ, जहाँ एउटै इन्स्टन्सका लागि धेरै connect फंक्शन चल्न सक्छन्। पछिको असफलताले अघिल्लो सफलतालाई पछाडि फर्काएर रद्द गर्दैन, र अघिल्लो फंक्शनलाई सहोदर फंक्शन असफल भयो भनी जान्ने कुनै उपाय छैन।
अस्वीकृति स्वचालित छ, सफाइ होइन
OpenVPN 2.6 पुस्तिका ले client-disconnect प्रशोधनलाई अघिल्लो connect प्रशोधन सफल भएकोसँग जोड्छ। अभिलेखित अपवादले क्यास्केड शृंखलाहरू समेट्छ: यदि एउटा connect चरणले पहिले नै सफलता फर्काइसकेको छ भने, पछिको connect चरण असफल भए पनि इन्स्टन्स भत्काउँदा सम्बन्धित disconnect चरणहरू तैपनि चल्छन्। त्यो अपवाद साँघुरो छ र कति कलब्याक कन्फिगर छन् भन्नेमा निर्भर छ, त्यसैले एउटा shell स्क्रिप्ट परीक्षण गर्दा शृंखलाबारे तपाईंलाई केही पनि थाहा हुँदैन।
डिजाइन गर्नुअघि वास्तविक कन्फिगरेसनको नक्सा बनाउनुहोस्: कुन स्क्रिप्ट, कुन प्लगइन र कुन क्रममा चल्छन्। तलको तालिकाले अधुरो सेटअपले पछाडि के छोड्छ भनी सूचीबद्ध गर्छ।
| What the hook did before failing | What the client sees | What stays behind |
|---|---|---|
| Created a firewall entry | A rejection, with no tunnel | A rule matching an address nobody owns |
| Wrote a state row | A rejection, with no tunnel | A record of a session that never started |
| Allocated a tunnel address | A rejection, with no tunnel | An address marked busy until something releases it |
हरेक पंक्ति क्लाइन्टका लागि एउटै तरिकाले र होस्टका लागि फरक तरिकाले अन्त्य हुन्छ। तीमध्ये कुन भयो भनी क्लाइन्टले भन्न सक्दैन, त्यसैले hook ले असफलता स्थिति फर्काउनुअघि आफूले गरेको फिर्ता लिनुपर्छ।
असफल भएको स्क्रिप्टभित्रै क्षतिपूर्ति गर्नुहोस्
साझा अवस्था छुनुअघि सम्भव भएसम्म सबै प्रमाणित गर्नुहोस्: प्रमाणपत्रका फिल्ड, ठेगानाको उपलब्धता, क्लाइन्ट रहेको समूह। सबैभन्दा सस्तो अस्वीकृति त्यो हो जो कुनै पनि बाँडफाँटअघि हुन्छ। सेटअपले धेरै बाह्य कार्यहरू समेट्न थालेपछि कुन पूरा भए भन्ने रेकर्ड राख्नुहोस् र असफलता स्थिति फर्काउनुअघि तिनलाई उल्टो क्रममा फिर्ता लिनुहोस्।
एउटा ठोस उदाहरण: स्क्रिप्टले हरेक क्लाइन्टका लागि फायरवाल प्रविष्टि बनाउँछ, त्यसपछि त्यसलाई वर्णन गर्ने स्थिति-पंक्ति लेख्न असफल हुन्छ। असफल शाखाले भर्खरै बनाएको प्रविष्टि हटाउनुपर्छ र त्यसपछि शून्य नभएको कोडसँग बाहिर निस्कनुपर्छ। कहिल्यै तालिकाबद्ध नहुन सक्ने disconnect घटनाको प्रतीक्षा गर्नु नै नियम आफ्नो उद्देश्यको सत्रभन्दा लामो बाँच्ने तरिका हो।
क्षतिपूर्तिलाई इडेम्पोटेन्ट र मालिकत्वयुक्त बनाउनुहोस्
सफाइ दुई पटक चलाउन सुरक्षित र के मेट्न सकिन्छ भन्नेमा सटीक हुनुपर्छ। अघिल्लो प्रयासको ढिलो घटनाले नयाँ सत्रको बाँडफाँट हटाउनु हुँदैन, केवल दुवैले साझा नाम वा पुनःप्रयोग गरिएको टनेल ठेगाना भएको आधारमा। विशेष ह्यान्डल वा अपरेसन आईडी स्रोतसँगै रेकर्ड गर्नुहोस्, र नामले होइन, त्यही कुञ्जीले मेट्नुहोस्। डाटाबेस कारोबारले डाटाबेसकै परिवर्तनमा मात्र मद्दत गर्छ; त्यो सीमाबाहिरको फायरवाल नियमलाई स्पष्ट क्षतिपूर्ति चरण चाहिन्छ।
प्रक्रिया परिवर्तन र सफाइबीच मर्न सक्छ भनी मान्नुहोस्, र तालिकाअनुसार बाह्य अवस्थालाई स्वीकृत क्लाइन्ट सूचीसँग तुलना गर्ने मेलमिलापकर्ता थप्नुहोस्।
साँच्चै फरक पर्ने तीन मार्ग परीक्षण गर्नुहोस्
तीन अवस्थाको अभ्यास गर्नुहोस्: केही पनि बाँडफाँट हुनुअघिको अस्वीकृति, आंशिक बाँडफाँटपछिको अस्वीकृति, र पछि अन्त्य हुने सामान्य स्वीकृत सत्र। ती तीनले फरक लग लाइन र फरक अवशेष उत्पादन गर्छन्। हरेकपछि बाह्य अवस्था जाँच्नुहोस्, क्लाइन्टको असफलता सन्देश मात्र होइन, किनकि तीनमध्ये दुईमा क्लाइन्टको असफलता नै अपेक्षित परिणाम हो।
hook को चरण, निकास स्थिति र के बाँडियो वा छोडियो भन्ने क्रेडेन्सियल बाहेक लग गर्नुहोस्। आफूले बनाएको स्रोतको नाम लिने hook लगले नै चुहिएको नियमलाई छ महिनापछि भेट्टाउन सकिने बनाउँछ।