एक साथ दो VPN ऐप्स: कौन सा kill switch वास्तव में लागू होता है?
दूसरा VPN क्लाइंट पहले वाले का kill switch कभी नहीं पाता। कौन सी नीति लागू होती है, यह तीन शर्तें तय करती हैं, और अपनी नीति को कैसे सत्यापित करें।
दो VPN क्लाइंट साथ-साथ चल सकते हैं, लेकिन उनके kill switch एक नीति में नहीं मिलते। हर क्लाइंट अपनी सुरंग के लिए नियम स्थापित करता है, और किसी को भी दूसरे के होने का पता नहीं होता। मुझे यह पहले जुड़े काम के क्लाइंट के साथ हुआ: दूसरा ऐप अपना हैंडशेक पूरा नहीं कर पाया, दस मिनट „Connecting“ पर अटका रहा, और पहली सुरंग ने सब कुछ चुपचाप ले लिया। दूसरा ऐप सुरक्षित रहेगा या नहीं, यह तीन शर्तों पर निर्भर है, इस पर नहीं कि दोनों आइकन जुड़ा हुआ दिखाते हैं या नहीं।
kill switch असल में किस तक सीमित होता है
ऑपरेटिंग सिस्टम में कोई एक kill switch झंडा नहीं होता। ऐसा झंडा बताने वाला क्लाइंट नियमों का एक सेट स्थापित करता है: जो मेरी सुरंग से बाहर नहीं जाता उसे गिरा दो, और सुरंग गायब होने पर अक्सर fail closed व्यवहार करो। लिनक्स पर यह आमतौर पर nftables या iptables श्रृंखला होती है, Windows पर Windows Filtering Platform फ़िल्टर का सेट, Android और iOS पर सुरंग सेवा का अपना रूटिंग और वह सिस्टम सेटिंग जो VPN के बिना कनेक्शन रोकती है। Android VPN गाइड इस सेवा मॉडल का वर्णन करता है अगर आपको प्लेटफ़ॉर्म का दृष्टिकोण चाहिए।
दायरा ही अहम हिस्सा है। „केवल wg0 आउटपुट इंटरफ़ेस पर पैकेट की अनुमति दो“ जैसा नियम इस बात की परवाह नहीं करता कि दूसरी सुरंग मौजूद है या नहीं। अगर कोई दूसरा क्लाइंट wg1 उठाता है, तो पहले क्लाइंट के नियम उन पैकेटों को सामान्य ट्रैफ़िक मानते हैं: आमतौर पर गिरा दिए जाते हैं, कभी-कभी अनुमति मिल जाती है। हर हाल में फैसला पहला क्लाइंट करता है, और उसे पता भी नहीं कि दूसरा ऐप इंतज़ार कर रहा है।
तीन शर्तें जो तय करती हैं कि कौन ढका जाएगा
हर संयोजन गिनने की ज़रूरत नहीं। तीन सवाल कुछ मिनटों में यह तय कर देते हैं।
- क्या प्लेटफ़ॉर्म दूसरी सुरंग की अनुमति ही देता है? ज़्यादातर Android फ़ोन और iPhone प्रति उपयोगकर्ता प्रोफ़ाइल केवल एक सक्रिय VPN सेवा स्वीकार करते हैं, इसलिए दूसरे ऐप के पास कभी सुरंग नहीं होती और वह कुछ भी लागू नहीं करता। आपको एक ही नीति मिलती है, उस ऐप से जिसने जगह जीती।
- डिफ़ॉल्ट रूट किस प्रक्रिया के पास है? Windows, macOS और Linux दो सुरंगें आसानी से उठा लेते हैं। डिफ़ॉल्ट रूट उस क्लाइंट का होता है जिसने उसे आख़िरी बार या बेहतर मीट्रिक के साथ सेट किया, और दूसरा क्लाइंट जुड़ा होता है पर निष्क्रिय। Linux पर wg-quick का डिफ़ॉल्ट रूट मोड निजी तालिका और fwmark नियम के साथ नीति-आधारित रूटिंग इस्तेमाल करता है, इसलिए दूसरी wg-quick सुरंग पहली को बदलने के बजाय एक प्रतिस्पर्धी नियम जोड़ती है।
- क्या दूसरा क्लाइंट अपने ही सर्वर तक पहुँच पाता है? अगर पहला kill switch डिफ़ॉल्ट इनकार है, तो दूसरे ऐप का बाहरी एंडपॉइंट बस एक और गिराया गया गंतव्य है। वह चुपचाप फिर कोशिश करता है और कभी त्रुटि नहीं बताता।
छोटा संस्करण, सहायता थ्रेड के लिए:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
उनमें से दो पंक्तियाँ सिस्टम ट्रे के आइकन से एक जैसी दिखती हैं, इसलिए आइकन यहाँ उपलब्ध सबसे खराब सबूत है।
पहले क्या विफल होता है, और वह कैसा दिखता है
दूसरा स्वस्थ हो और एक क्लाइंट „Connecting“ पर अटका हो, तो लगभग हमेशा एंडपॉइंट की भूख होती है: चल रहा kill switch दूसरे क्लाइंट का उसके खुद के सर्वर की ओर हैंडशेक गिरा देता है। इसे सस्ते में इस तरह पुष्ट करें कि पहले क्लाइंट के ब्लॉक नियम एक प्रयास के लिए रोक दें। अगर दूसरा तुरंत जुड़ जाए, तो सवाल का जवाब मिल गया।
DNS दूसरी विफलता है। क्लाइंट अपने इंटरफ़ेस के लिए रिज़ॉल्वर कॉन्फ़िगरेशन सेट करते हैं, और कुछ सीधे वैश्विक सूची को ही ओवरराइट कर देते हैं। दोनों सुरंगें ऊपर हों तो क्वेरी एक तरफ़ से निकल सकती हैं जबकि रिज़ॉल्वर दूसरी तरफ़ का हो। कोई भी ऐप डिस्कनेक्ट करें और बचा हुआ ऐप अनुपलब्ध नेमसर्वर रखता है: पेज एक मिनट के लिए अटकते हैं और फिर दोबारा हल होते हैं, जबकि VPN अब भी जुड़ा दिखाता है।
तीसरी रूटों की लहर है। दोबारा कनेक्शन डिफ़ॉल्ट रूट को फिर से क्रम में लगाते हैं, और इंटरफ़ेस से बँधा kill switch उसका पीछा नहीं करता। जो ट्रैफ़िक अभी-अभी सुरंग में था, वह अब किसी गिराने वाले नियम से मेल खाता है, जिसे उपयोगकर्ता की ओर से ऐसा VPN पढ़ा जाता है जो अचानक काम करना बंद कर देता है।
जाँचें कि वास्तव में कौन सी नीति लागू है
यह हानिरहित ट्रैफ़िक से करें, ऐसी चीज़ से नहीं जिसकी आपको कमी खलेगी।
Linux पर कर्नेल से पूछें कि कौन जीतता है और फ़ायरवॉल किससे बँधता है। ip -4 route show default उस सुरंग का नाम बताता है जिसके पास बाहर जाने का रास्ता है। ip rule show दिखाता है कि नीति-आधारित रूटिंग खेल में है या नहीं। sudo nft list ruleset | grep -n oifname दिखाता है कि गिराने की क्रियाएँ इंटरफ़ेस नाम, मार्क या पूरी आउटपुट श्रृंखला से बँधी हैं।
Windows पर वही कहानी रूट मीट्रिक और फ़िल्टर सूची में रहती है: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric और Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN"। macOS पर, netstat -rn -f inet | head -5 और scutil --dns | head -20।
फिर वह कदम उठाएँ जो लोग छोड़ देते हैं: सुरंग को जानबूझकर रोकें और पुष्ट करें कि जिस ट्रैफ़िक के विफल होने की उम्मीद है वह सचमुच विफल होता है। जुड़ा हुआ आइकन इंटरफ़ेस की स्थिति है, लागू करना नहीं।
कब दो क्लाइंट गलत डिज़ाइन हैं
अगर दूसरे ऐप के पीछे एकमात्र माँग ज़्यादा सुरक्षा है, तो उसे हटा दें। दो परस्पर क्रिया करने वाली ब्लॉक नीतियाँ एक से कम पूर्वानुमेय होती हैं, और हर दोबारा कनेक्शन ऐसी स्थिति में पहुँचने का मौका है जिसे कोई विक्रेता परखता नहीं।
अगर सचमुच शृंखलाबद्ध करना चाहिए, जैसे किसी वाणिज्यिक हॉप से पहुँचने वाला कॉर्पोरेट गेटवे, तो एक ही प्रवर्तन बिंदु वाला डिज़ाइन चुनें। इसका मतलब आमतौर पर एक राउटर या एक ऐसा क्लाइंट है जो शृंखला को सँभाले, न कि दो डेस्कटॉप ऐप जो एक ही डिफ़ॉल्ट रूट के लिए होड़ करें। प्रबंधित डिवाइस पर स्वीकृत क्लाइंट रखें और बाकी सब को दायरे से बाहर मानें, ट्रे में जो भी दिखाए।
दोनों रखने से पहले चेकलिस्ट
सूची क्रम से पूरी करें; पहला असफल मद ही वह है जिसे ठीक करना है।
- पुष्ट करें कि ठीक एक क्लाइंट के पास डिफ़ॉल्ट रूट और रिज़ॉल्वर है।
- अगर दूसरा क्लाइंट ऊपर रखना है, तो उसके सर्वर एंडपॉइंट को स्पष्ट रूप से अनुमति दें और हर क्लाइंट अपडेट के बाद फिर जाँचें।
- जब कोई सुरंग गिरे तो अपेक्षित नतीजा लिखें और ठीक उसी स्थिति को परखें।
- रीबूट के बाद विफलता का रास्ता जाँचें, जब शुरुआत का क्रम अलग हो।
- प्रबंधित प्रोफ़ाइल पर रुकें और कुछ भी जोड़ने से पहले मालिक से पूछें।
अगर तीसरा कदम विफल हो, तो सच्चा जवाब यह है कि सिर्फ़ एक क्लाइंट आपको नीति दे रहा है। तय करें कि किस पर भरोसा है और दूसरे को जाने दें।