दूसरा VPN टनल पहले वाले को क्यों तोड़ देता है?

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

लक्षण: दूसरा क्लाइंट चुपचाप जीत जाता है

OpenVPN: विकल्प redirect-gateway def1 0.0.0.0/0 को अधिलेखित नहीं करता। यह 0.0.0.0/1 और 128.0.0.0/1 जोड़ता है: दोनों मिलकर हर IPv4 पते को कवर करते हैं, और हर प्रीफ़िक्स लंबाई में साधारण डिफ़ॉल्ट को हरा देता है। मूल डिफ़ॉल्ट टेबल में रहता है और सामान्य ट्रैफ़िक के लिए इस्तेमाल होना बंद हो जाता है, और VPN सर्वर तक का होस्ट रूट टनल को उसके अपने बाहरी पैकेट पकड़ने से रोकता है। दोनों क्लाइंट ऐसा करते हैं, और दूसरा बस अपनी जोड़ी बाद में इंस्टॉल करता है।

इसीलिए पहली टनल डिस्कनेक्ट नहीं बल्कि मृत दिखती है। उसका इंटरफ़ेस चालू है, उसका कंट्रोल चैनल जीवित है, और अब कोई एप्लिकेशन ट्रैफ़िक उस तक नहीं पहुँचता। उलटी शिकायत में भी वही गायब push है: ऐसा फ़ोन जो जुड़ता है पर कुछ भेजता नहीं, आम तौर पर ऐसे सर्वर से बात करता है जिसने कभी redirect-gateway की घोषणा नहीं की, इसलिए डिवाइस अपना डिफ़ॉल्ट रखता है और सिर्फ़ पूल तक पहुँचता है।

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

पढ़ें कि असल में कौन-सी टनल जीतती है

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

विंडोज़: एक प्रोफ़ाइल को डिफ़ॉल्ट का मालिक बनने से रोकें

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

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

लिनक्स: दूसरी टनल को मुख्य टेबल से बाहर रखें

एक मशीन पर दो openvpn --config इंस्टेंस चलाने से दोनों क्लाइंट एक ही टेबल में आ जाते हैं, और तीन विकल्प बढ़ते अलगाव के साथ उन्हें अलग करते हैं। सबसे हल्का है दूसरे क्लाइंट को टेबल संपादित करने से पूरी तरह रोकना: स्पष्ट रूट के साथ route-nopull, या route-up स्क्रिप्ट जो सिर्फ़ वही इंस्टॉल करे जो आप चाहते हैं। तब दूसरी टनल ठीक वही प्रीफ़िक्स ढोती है जिनके नाम आप लेते हैं और कुछ नहीं। तब आप तय करते हैं कौन-से प्रीफ़िक्स कहाँ जाएँ, बाद में पता लगाने के बजाय।

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

नेटवर्क नेमस्पेस सबसे भारी और सबसे साफ़ विकल्प हैं। दूसरे क्लाइंट को ip netns के अंदर शुरू करें, उसे veth जोड़ी दें, और इस्तेमाल के लिए उस नेमस्पेस में प्रवेश करें। हस्तक्षेप खत्म हो जाता है क्योंकि हर नेमस्पेस एक टेबल बाँटने के बजाय अपनी टेबल रखता है, जो तब अतिरिक्त सेटअप के लायक है जब दोनों टनल हफ़्तों तक चालू रहनी हों।

प्रति-एप्लिकेशन, और चेनिंग एक अलग समस्या के रूप में

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

चेनिंग दो टनल साथ-साथ चलाने से अलग क्रिया है। A को B के ऊपर से चेन करने का मतलब है कि भीतरी सर्वर का पता बाहरी टनल के अंदर से पहुँचने योग्य होना चाहिए। बाहरी क्लाइंट को भीतरी क्लाइंट के एन्क्रिप्टेड पैकेट को लीक नहीं समझना चाहिए। वर्चुअल मशीन के अंदर एक क्लाइंट मोटा पर भरोसेमंद संस्करण है; एक ही होस्ट पर दोनों हों तो ऊपर का रूटिंग काम और भीतरी सर्वर की ओर बाहरी ऐसा रास्ता चाहिए जो कभी भीतरी टनल में न जाए।

डिफ़ॉल्ट का मालिक, हर टनल के ढोए जाने वाले प्रीफ़िक्स की सूची और DNS पथ लिख लें। वे तीन तथ्य अगली घटना को जाँच के बजाय खोज में बदल देते हैं।