के OpenVPN हुक स्क्रिप्टले भर्खरै बनाएको टनेल प्रयोग गर्न सक्छ?

हुक स्क्रिप्ट टनेलको अर्को छेउसम्म पुग्छ कि पुग्दैन तीन सर्तमा निर्भर छ: यो कुन घटनासँग जोडिएको छ, स्क्रिप्ट चल्दा OpenVPN अझै आफ्नो सुरुवात क्रमभित्र छ कि छैन, र काम त्यो क्रमबाट अलग गरिएको छ कि छैन। अधिकांश स्क्रिप्ट तेस्रोमा असफल हुन्छन्। निद्रा थप्नु जीवनचक्रको समस्यालाई समयको समस्या मान्छ, र यो भ्रमित गर्न पर्याप्त पटक काम गर्छ।

पहिले घटना तय गर्नुहोस्, त्यसपछि काम स्थगित गर्ने विधि, त्यसपछि स्थगित काम चल्ने स्थान। यी तीन निर्णय स्वतन्त्र छन्, र तिनलाई मिसाउनु नै दुई लाइनको हुकलाई पूरै दिउँसो बनाउने तरिका हो।

हुक आफूलाई पर्खिरहेको टनेल किन पर्खन्छ

OpenVPN आफ्ना हुकहरूलाई समकालिक रूपमा बोलाउँछ, प्याकेट सार्ने त्यही प्रक्रियाभित्र। tun वा tap यन्त्र हुँदा तर कुनै पनि मार्ग थप्नुअघि up सक्रिय हुन्छ, र मार्गपछि route-up सक्रिय हुन्छ; यी दुवै क्षणले विपक्षी उत्तर दिने वाचा गर्दैन। कुनै पनि हुकको स्क्रिप्ट चलिरहेको बेला डेमन अगाडि पठाउँदैन, त्यसैले टनेलबाट ट्राफिक जाने अपेक्षा गर्ने आदेश त्यही आदेशलाई पर्खिरहेको टनेल पर्खन्छ। यही चक्रीय प्रतीक्षा हातले चलाउँदा सफल हुने र हुकको समय सकिने कारण हो।

स्पष्ट उपाय, अर्थात् केही सेकेन्ड निदाउनु, कहिलेकाहीँ काम गर्छ किनभने टाढाको छेउ आफै माथि आयो, निद्राले केही सुधारेकोले होइन। तयारी सोध्ने सहायक फरक उत्तर हो: हुक फर्कन्छ, अगाडि पठाउने सुरु हुन्छ, र सहायकले आवश्यक कुरा त्यो साँच्चै भएपछि पाउँछ।

सुविधाअनुसार होइन, घटनाअनुसार हुक छान्नुहोस्

केवल यन्त्र चाहिने काममा up जोड्नुहोस्, मार्ग चाहिने काममा route-up, र client-connect तथा client-disconnect राख्नुहोस् सर्भर पक्षमा प्रति-क्लाइन्ट कार्यहरूका लागि। डिस्कनेक्टमा सफाइ दुई पटक चल्न सहनुपर्छ, किनभने स्थायी इन्टरफेसमार्फत पुनः जडान पूर्ण रिस्टार्टकै क्रम पछ्याउँदैन। सर्भरमा, डेमन सुरु हुँदा होइन तर क्लाइन्ट प्रमाणित हुँदा client-connect सक्रिय हुन्छ, जुन त्यहाँ तर्क सार्नुअघि पुष्टि गर्न लायक छ। काम एकल जडानको सट्टा सेवाको जीवनचक्रको भए, systemd इकाई कुनै पनि हुकभन्दा राम्रो घर हो।

हुक आदेशहरू डेमनले सिधै चलाउँछ, बीचमा कुनै शेल छैन, त्यसैले up लाइनमा ifconfig_remote शाब्दिक पाठका रूपमा आउँछ। आदेशलाई स्पष्ट शेलमा बेर्नुहोस्, वा तर्कलाई वातावरण पढ्ने स्क्रिप्टमा राख्नुहोस्। ipchange आफ्नै तर्कहरू थप्ने एक निर्देश हो: यसले आदेशलाई ठेगाना र पोर्ट दिन्छ, त्यसैले कसैका लागि नलेखिएको स्क्रिप्टले दुई अप्रत्याशित तर्क देख्छ।

काम अलग गर्ने तीन तरिका

पहिलो विकल्प हुकभित्रबाट सहायकलाई पृष्ठभूमिमा पठाउनु हो: setsid वा systemd-run --scope ले सुरु गर्नुहोस्, वंशानुगत डिस्क्रिप्टरहरू बन्द गर्नुहोस्, र तुरुन्तै शून्यसहित बाहिर निस्कनुहोस्। दोस्रो भनेको हुकले सानो अवस्था फाइल लेखोस् र systemd टाइमर वा पथ इकाईले त्यसमा काम गरोस्, जसले हुकलाई साधारण राख्छ र पुनःप्रयास नीति लग भएको ठाउँमा राख्छ। तेस्रो भनेको हुक पूरै छोडेर कामलाई VPN सेवापछि क्रमबद्ध इकाईमा सार्नु हो, जुन काम कुनै पनि हिसाबले प्रति-जडान नभए सही उत्तर हो। तीनवटै एउटै नियम साझा गर्छन्: टनेल चाहिनुअघि हुक फर्कनुपर्छ।

जे छाने पनि सहायकलाई इडेम्पोटेन्ट र अवलोकनयोग्य बनाउनुहोस्। दुई अतिव्यापी आह्वानले एउटै अपरिवर्तनीय क्रिया दुई पटक चलाउनु हुँदैन, र असफल सहायकले मानिसले पढ्न सक्ने केही छोड्नुपर्छ।

स्यान्डबक्स असफलतालाई जीवनचक्र असफलताबाट अलग गर्नुहोस्

स्क्रिप्ट root प्रम्प्टबाट चल्छ र सेवाका रूपमा असफल हुन्छ भने कारण सामान्यतया नेटवर्क होइन, स्यान्डबक्स हो। प्रतिबन्धक ProtectHome, केवल-पढ्ने ProtectSystem, वा नभएको कार्य निर्देशिका स्क्रिप्ट वा त्यसको डेटा पुग्न नसकिने बनाउन सक्छन्, र SELinux होस्टमा फाइललाई कार्यान्वयन अनुमति दिने सन्दर्भ पनि चाहिन्छ। systemctl cat openvpn-server@server ले इकाई र journalctl -u openvpn-server@server -n 80 ले जर्नल पढ्नुहोस्, त्यसपछि जडान टाइमआउटको सट्टा अनुमति वा सन्दर्भ त्रुटि खोज्नुहोस्। स्यान्डबक्स अक्षम गर्नु पहिलो होइन, अन्तिम कदम हुनुपर्छ।

जीवनचक्र असफलता फरक देखिन्छ: हुक सुरु हुन्छ, सहायक चल्छ, र सकेट अझै त्यहाँ छैन। हुकबाटै टाइमस्ट्याम्प भएको लाइन लेख्नुहोस्, डिस्कनेक्ट गरी फेरि जोड्नुहोस्, र घटनाहरू क्रममा पढ्नुहोस्। सहायकलाई साँच्चै टनेल चाहिए, निश्चित समय निदाउनुको सट्टा तयारी सोध्न दिनुहोस्।

तीन क्षेत्रले अर्को प्रतिवेदन उपयोगी बनाउँछन्: कुन हुक चल्यो, कुन खाता प्रयोग गर्यो, र कहाँ रोकियो। ती नभए प्रत्येक पछिल्लो अनुसन्धान सुरुदेखि सुरु हुन्छ।