अनेक 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 निर्देशांचा समावेश करते आणि सिंटॅक्सबद्दल शंका असताना तपासायची आवृत्ती तीच आहे।