एक ही होस्ट पर OpenVPN सर्वर और क्लाइंट: क्लाइंट क्यों गिर जाते हैं

जिस मशीन पर पहले से VPN सर्वर चल रहा है, उस पर क्लाइंट प्रोफ़ाइल जोड़िए और पहला नुकसान मूल सेवा का होगा। नया टनल कभी बन ही न सके, या बन जाए और सर्वर के मौजूदा क्लाइंट चुपचाप जवाब पाना बंद कर दें। दो टकराव ये दोनों नतीजे देते हैं: एक टनल पूल जो पहले से इस्तेमाल में है, और नए क्लाइंट-आधे द्वारा लगाया गया डिफ़ॉल्ट रूट जो पूरी तालिका को ढक लेता है। इनमें से कोई भी OpenVPN त्रुटि संदेश नहीं देता, इसलिए विफलता को सर्वर की समस्या पढ़ा जाता है।

एक मशीन, दो भूमिकाएँ, और जवाब कहाँ जाने चाहिए इस पर दो असंगत जवाब।

एक ही पूल, दो सर्वर: कौन जीतता है

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

संपादन से पहले सूची बनाइए कि क्या सक्रिय है: ip -4 addr show टनल डिवाइस की सूची देता है, ss -lunp श्रोताओं की सूची देता है, और systemctl list-units यूनिटों के नाम बताता है। टनल पतों पर एक नज़र तय कर देती है कि पूल टकराते हैं या नहीं।

क्लाइंट प्रोफ़ाइल तालिका में क्या जोड़ता है

क्लाइंट-आधा जुड़ते ही रूट लिखता है। redirect-gateway def1 डिफ़ॉल्ट रूट को 0.0.0.0/1 और 128.0.0.0/1 में बाँटता है, दोनों नए डिवाइस से रूट होते हैं, साथ में दूर के सर्वर तक एक होस्ट रूट जो जानबूझकर भौतिक इंटरफ़ेस पर पिन किया गया है। यह पिन इसलिए है कि टनल अपने परिवहन के लिए रास्ता बनाए रखे। बाकी सब कुछ, जिन जवाबों का स्थानीय सर्वर अपने क्लाइंटों को देनदार है वे भी, अब नए डिफ़ॉल्ट का पालन करता है और दूर के लिंक से बाहर जाता है।

तो दूसरा टकराव टूटा हुआ टनल नहीं है। यह तालिका में गलत जगह पर बैठा एक काम करता टनल है।

भूमिकाओं को अलग रखने के तीन तरीके

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

चाहे कोई भी रास्ता लें, अपवाद में LAN नहीं, स्थानीय टनल सबनेट का नाम होना चाहिए। स्थानीय सर्वर जो जवाब भेजता है उसका गंतव्य टनल पता होता है, इसलिए LAN जैसा अपवाद उससे कभी मेल नहीं खाता।

दोनों में से कौन सा इंस्टेंस दोषी है

क्लाइंट इंस्टेंस रोकिए और मूल क्लाइंटों को फिर से जाँचिए। तुरंत सुधार का अर्थ रूटिंग है, सर्वर नहीं। क्लाइंट वापस लाइए और ip route get से एक ही जवाब का पीछा कीजिए, जिसे स्रोत और गंतव्य दोनों पते दिए गए हैं, जो वह रास्ता दिखाता है जो कर्नेल चुनेगा, फिर tcpdump -ni any port 1194 से देखिए कि पैकेट वास्तव में कौन सा इंटरफ़ेस इस्तेमाल करते हैं। सर्वर की स्टेटस फ़ाइल, जो हर कुछ सेकंड में status निर्देश से लिखी जाती है, जुड़े क्लाइंटों की सूची और दोनों दिशाओं के बाइट काउंटर रखती है।

इन काउंटरों को एक-दूसरे के सामने पढ़िए। जो ट्रैफ़िक निकलकर कभी वापस नहीं आता, वह हैंडशेक की समस्या नहीं, रूटिंग का जवाब है।