कई OpenVPN रिमोट: फेलओवर सूची, लिंक बॉन्डिंग नहीं

एक प्रोफ़ाइल में दो रिमोट पंक्तियाँ दूसरी लेन जैसी लगती हैं; वे दूसरा प्रयास हैं। जब पहला endpoint जवाब देना बंद कर देता है, क्लाइंट आगे बढ़ जाता है और सत्र चौड़ा नहीं होता। सूची को शुरू में ही फेलओवर कहें, वरना आप गलत नॉब ट्यून करेंगे।

रिमोट सूची आपको क्या देती है

प्रोफ़ाइल को प्रयासों के क्रमबद्ध समूह की तरह देखें, क्षमता के पूल की तरह नहीं। हर प्रविष्टि को सुरंग उठाने की अपनी बारी मिलती है, और सत्र उसी पर रहता है जिसने जवाब दिया। लंबी सूची जुड़ने की संभावना सुधारती है, पाइप का आकार नहीं।

असली एग्रीगेशन एक अलग मशीन है। एक प्रवाह को कई रास्तों पर बाँटने के लिए दोनों सिरों पर सॉफ़्टवेयर चाहिए, जो ट्रैफ़िक को बाँटकर क्रम में फिर जोड़े।

ज़्यादा सर्वर से तेज़ सुरंगों का वादा करने वाला विक्रेता वही दूसरा मॉडल बेचता है, लंबी सूची नहीं। अगर क्लाइंट सिर्फ़ बारी-बारी endpoint आज़माता है, तो पाँच प्रविष्टियाँ आपकी संभावना बदलती हैं और कुछ नहीं। किसी कटौती को देखें: सत्र गिरता है और कहीं और लौटता है, जिसे लॉग नया endpoint दिखाता है, कभी चौड़ा पाइप नहीं।

एक endpoint के साथ सेटिंग्स रखने वाले ब्लॉक

सामान्य remote पंक्ति एक पता ले जाती है, और कभी-कभी पोर्ट और प्रोटोकॉल भी। जब endpoint को प्रॉक्सी चाहिए, या ऐसा ट्रांसपोर्ट जो बाकी फ़ाइल इस्तेमाल नहीं करती, तो उन सेटिंग्स को एक कनेक्शन ब्लॉक में रखें जो उन्हें उसके साथ रखे। इनलाइन ब्लॉक एक .ovpn फ़ाइल में भी काम करते हैं, और ज़्यादातर प्रोफ़ाइल इसी तरह आते हैं।

ब्लॉक के बाहर की हर चीज़ उन प्रविष्टियों के लिए डिफ़ॉल्ट का काम करती है जो उसे ओवरराइड नहीं करतीं। इसीलिए एक बना हुआ ब्लॉक और चार सामान्य रिमोट ऐसे व्यवहार करते हैं जो पतों की सूची समझा नहीं सकती।

जिस ब्लॉक को आप नहीं पहचानते उसे हटाना सौंदर्य का मामला नहीं है। जिस endpoint का वह था, वह फ़ाइल के डिफ़ॉल्ट पर लौट जाता है, जो उस ट्रांसपोर्ट से अलग हो सकता है जिस पर वह सुनता है। गलत आवरण हटाइए और एक प्रविष्टि विफल हो जाती है जबकि बाकी काम करती हैं, इसलिए यह टूटी प्रोफ़ाइल नहीं, खराब सर्वर जैसा दिखता है। संपादन से पहले हर रिमोट को उसके ट्रांसपोर्ट, पोर्ट और प्रॉक्सी के साथ पढ़ें।

पुनः प्रयास का क्रम और remote-random की कीमत

क्रम मायने रखता है क्योंकि हर मृत प्रविष्टि अगले प्रयास से पहले समय लेती है। जो endpoint चाहिए उसे पहले रखें और बाकी को क्रमबद्ध विकल्प मानें।

remote-random शुरुआती क्रम बदल देता है, जो भार को समतुल्य सर्वरों में बाँटता है और तब उलटा पड़ता है जब एक endpoint स्पष्ट रूप से प्राथमिक हो। किसी भी हाल में, क्लाइंट ने जो endpoint चुना उसे लॉग करें; कनेक्शन धीमा लगने पर प्रोफ़ाइल का नाम कुछ नहीं कहता। विस्तृत लॉग से लिंक पंक्ति को grep करने पर दिखता है कि सत्र कहाँ उतरा।

ऑपरेटर मिलाना विश्वास के बयान को तोड़ता है

प्रोफ़ाइल पहचान के बारे में एक दावा भी है: ये पते वही सेवा हैं जहाँ आप पहुँचना चाहते थे, और पिन किया गया प्रमाणपत्र उसी का है। उस फ़ाइल में मुफ़्त सार्वजनिक सर्वर डालना दावा तोड़ देता है: उनके प्रमाणपत्र और आपका अलग सेवाएँ बताते हैं। सामान्य नतीजा पहचान विफलता है, या ऐसे क्रेडेंशियल जो आपके प्रदाता के नेटवर्क के बाहर के होस्ट को दिए जाते हैं। विकल्पों को उस सेट के भीतर रखें जो आपका ऑपरेटर बाँटता है, मेल खाते क्रेडेंशियल और विश्वास सामग्री के साथ।

अगर आपको दो प्रदाताओं के endpoint चाहिए, तो वह रूटिंग है, प्रोफ़ाइल संपादन नहीं। इसे सुरंग के ऊपर सुलझाएँ, जहाँ आप कह सकें कि कौन सा ट्रैफ़िक कौन सा रास्ता लेता है।

मानने के बजाय हर प्रविष्टि को जाँचें

मंज़ूर प्रोफ़ाइल अपडेट के बाद, हर ज़रूरी endpoint से जान-बूझकर जुड़ें और पुष्टि करें कि कौन सा ट्रांसपोर्ट ऊपर आया। विस्तृत रन इसे दिखाता है। openvpn --config office.ovpn --verb 4 शुरू करें और जिस पते की उम्मीद थी उसके लिए लिंक पंक्ति पढ़ें। फिर सुरंग के पीछे के संसाधन जाँचें; एक प्रविष्टि हैंडशेक पूरा कर सकती है और फिर भी आपको कहीं रूट नहीं करती।

फेलओवर को उम्मीद की जगह अपनी जाँच चाहिए। प्रयोगशाला में पहला endpoint अवरुद्ध करें, क्लाइंट शुरू करें, और मापें कि आगे बढ़ने में कितना समय लगता है। धीमी पहली प्रविष्टि के पीछे लंबी सूची अच्छी शुरुआत वाली छोटी सूची से बदतर है।

ऑपरेटर सूची बदले तो हर बार उसे फिर जाँचें। आयातित सेट तभी उपयोगी है जब उसकी प्रविष्टियाँ मौजूद हों और वह ट्रांसपोर्ट बोलें जो आपके ब्लॉक बताते हैं। OpenVPN 2.6 मैनुअल यहाँ remote, connection और random-order निर्देशों को कवर करता है, और सिंटैक्स पर संदेह होने पर यही वह संस्करण है जिसे जाँचना चाहिए।