जब OpenVPN का सर्वर उसी होस्ट पर चलता है तो क्लाइंट अटक जाता है

मेरे पास एक लैब मशीन थी जो किसी दूर की साइट से टनल स्वीकार करती थी और साथ ही किसी विक्रेता के नेटवर्क पर डायल भी करती थी। आउटबाउंड प्रोफ़ाइल हफ़्तों तक काम कर रही थी। इनबाउंड सर्वर जोड़ने के बाद, आउटबाउंड वाली जुड़ी और फिर कुछ सेकंड में ट्रैफ़िक भेजना बंद कर दिया, या पता पहले से उपयोग में है वाली त्रुटि के साथ शुरू होने से इनकार कर दिया। कॉन्फ़िग फ़ाइलें नहीं बदली थीं; होस्ट को बस पोर्ट और रूट के बारे में अपनी राय रखने वाली दूसरी OpenVPN प्रक्रिया मिल गई थी।

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

लक्षण को उलटा पढ़ें

शुरुआत इससे करें कि टनल कब मरती है। शुरू में बाइंड त्रुटि सुनने वाले पक्ष की ओर इशारा करती है: कुछ पहले से उस पोर्ट का मालिक है, और OpenVPN उसे साझा करने के बजाय शुरू होने से इनकार कर देता है। जो टनल ऊपर आती है और फिर चुप हो जाती है वह रूटिंग की ओर इशारा करती है, क्योंकि दूसरे इंस्टेंस द्वारा लगाया गया रूट बाहरी कनेक्शन के पैकेट को उनके रास्ते से खींच सकता है।

दोनों स्थितियाँ वही उपयोगकर्ता शिकायत पैदा करती हैं, इसलिए पुनः प्रयास लूप और वॉचडॉग स्क्रिप्ट कुछ भी ठीक नहीं करते। वे क्लाइंट को फिर उसी टकराव में जोड़ देते हैं। पहला उपयोगी सवाल यह है कि ट्रैफ़िक रुकने पर प्रक्रिया अभी भी चल रही है या नहीं।

प्रति इंस्टेंस एक सॉकेट और एक डिवाइस

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

lport 1195
nobind
dev tun1

वे संख्याएँ उदाहरण हैं, कोई अनिवार्यता नहीं। महत्वपूर्ण यह है कि क्लाइंट सर्वर के पोर्ट के लिए प्रतिस्पर्धा करना बंद कर दे और हर इंस्टेंस को अलग टनल डिवाइस मिले। tun0 साझा करने वाले दो डेमन, पोर्ट अलग होने पर भी, एक-दूसरे की डिवाइस स्थिति पर लिख देते हैं, इसलिए प्रति टनल एक डिवाइस वैकल्पिक नहीं है।

nobind क्लाइंट पक्ष का है। सर्वर को अभी भी बाइंड करना और सुनना होता है, इसलिए लाइन को सर्वर कॉन्फ़िग में कॉपी न करें, और ऐसे क्लाइंट पर बाइंडिंग बंद न करें जिसका साथी निश्चित स्रोत पोर्ट पर फ़िल्टर करता है।

डिफ़ॉल्ट रूट के लिए एक मालिक चुनें

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

ऊपर के पते और टेबल नंबर प्लेसहोल्डर हैं। नियम जोड़ने के तुरंत बाद पुष्टि करें कि VPN सर्वर का अपना पता अभी भी सामान्य टेबल से हल होता है; जो टेबल बाहरी ट्रांसपोर्ट को पकड़ लेती है वह उस टनल को तोड़ देती है जिसे उसे बचाना था, और उसके बाद का पुनः कनेक्शन लूप अविश्वसनीय प्रदाता जैसा दिखता है।

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

स्टेटस लाइन से नहीं, टेबल से जाँचें

जुड़ा हुआ बताने वाला क्लाइंट केवल अपना नियंत्रण चैनल साबित करता है। हर कनेक्शन से पहले और बाद में रूटिंग स्थिति कैप्चर करें, फिर कर्नेल से पूछें कि वास्तविक गंतव्य कौन-सा डिवाइस इस्तेमाल करेगा:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

यदि दूसरी टनल शुरू होने पर विक्रेता के पते के लिए चुना गया डिवाइस बदल जाता है, तो आपके पास रूट टकराव है। यदि दोनों प्रक्रियाएँ एक ही स्थानीय पोर्ट पर दिखती हैं, तो आपके पास सॉकेट टकराव है। दूसरे के बिना पहले को ठीक करना केवल विफलता को अगले पुनः कनेक्शन पर ले जाता है।

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