धेरै 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 निर्देशनहरू समेट्छ, र वाक्यरचना शंकास्पद हुँदा जाँच्नुपर्ने संस्करण त्यही हो।