एकै पटक दुई VPN एपहरू: कुन kill switch साँच्चै लागू हुन्छ?
दोस्रो VPN क्लाइन्टले पहिलोको kill switch कहिल्यै उत्तराधिकारमा पाउँदैन। कुन नीति लागू हुन्छ तीन सर्तले तय गर्छन्, र आफ्नो नीति कसरी जाँच्ने।
दुई VPN क्लाइन्ट सँगसँगै चल्न सक्छन्, तर तिनका kill switch एउटै नीतिमा मिसिँदैनन्। प्रत्येक क्लाइन्ट आफ्नै सुरुङका लागि नियम राख्छ, र कसैलाई पनि अर्को छ भन्ने थाहा हुँदैन। मैले यो पहिले जोडिएको कामको क्लाइन्टसँग भोगें: दोस्रो एपले आफ्नो ह्यान्डसेक पूरा गर्न सकेन, दस मिनेट „Connecting“ मा बस्यो, र पहिलो सुरुङले सबैथोक चुपचाप बोक्यो। दोस्रो एप सुरक्षित हुन्छ कि हुँदैन भन्ने तीन सर्तमा निर्भर छ, दुवै आइकन जोडिएको देखाउँछन् कि भन्नेमा होइन।
kill switch वास्तवमा केसम्म सीमित हुन्छ
अपरेटिङ सिस्टममा एउटै kill switch झन्डा हुँदैन। यस्तो झन्डा घोषणा गर्ने क्लाइन्ट नियमहरूको सेट राख्छ: मेरो सुरुङबाट बाहिर नजाने सबै फालिदेऊ, र सुरुङ हराउँदा प्रायः fail closed व्यवहार गर। Linux मा यो सामान्यतया 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।
त्यसपछि मानिसहरूले छोड्ने कदम चाल्नुहोस्: सुरुङ जानाजान रोक्नुहोस् र जुन ट्राफिक असफल हुने अपेक्षा छ त्यो साँच्चै असफल हुन्छ भनी पुष्टि गर्नुहोस्। जोडिएको आइकन इन्टरफेसको अवस्था हो, लागू गर्नु होइन।
कहिले दुई क्लाइन्ट गलत डिजाइन हुन्
यदि दोस्रो एपपछाडिको एउटै माग बढी सुरक्षा हो भने, त्यसलाई हटाउनुहोस्। दुई परस्पर क्रिया गर्ने ब्लक नीति एउटाभन्दा कम पूर्वानुमानयोग्य हुन्छन्, र हरेक पुनःजडान कुनै पनि विक्रेताले नपरीक्षण गर्ने अवस्थामा पर्ने मौका हो।
यदि साँच्चै शृंखलाबद्ध गर्नु आवश्यक छ, जस्तै कुनै वाणिज्यिक हपबाट पुगिने कर्पोरेट गेटवे, त एउटै लागू हुने बिन्दु भएको डिजाइन रोज्नुहोस्। यसको अर्थ सामान्यतया एउटा राउटर वा एउटै क्लाइन्ट जसले शृंखलालाई सघाउँछ, दुई डेस्कटप एप जो एउटै डिफल्ट रुटका लागि प्रतिस्पर्धा गर्छन् भन्ने होइन। व्यवस्थापित यन्त्रमा स्वीकृत क्लाइन्ट राख्नुहोस् र बाँकी सबैलाई व्याप्तिबाहिर मान्नुहोस्, ट्रेमा जे देखाए पनि।
दुवै राख्नुअघि चेकलिस्ट
सूची क्रममा पूरा गर्नुहोस्; पहिलो असफल हुने बुँदा नै सुधार्नुपर्ने बुँदा हो।
- ठ्याक्कै एउटा क्लाइन्टसँग डिफल्ट रुट र रिजोल्भर छ भनी पुष्टि गर्नुहोस्।
- यदि दोस्रो क्लाइन्ट माथि राख्न चाहनुहुन्छ भने त्यसको सर्भरको अन्त्यबिन्दुलाई स्पष्ट अनुमति दिनुहोस् र हरेक क्लाइन्ट अद्यावधिकपछि फेरि जाँच्नुहोस्।
- कुनै सुरुङ खस्दा अपेक्षित नतिजा लेख्नुहोस् र ठ्याक्कै त्यही अवस्था परीक्षण गर्नुहोस्।
- रिबुटपछि असफलताको बाटो जाँच्नुहोस्, जब सुरुको क्रम फरक हुन्छ।
- व्यवस्थापित प्रोफाइलमा रोक्नुहोस् र केही थप्नुअघि मालिकलाई सोध्नुहोस्।
यदि तेस्रो कदम असफल भयो भने, साँचो उत्तर यो हो कि एउटा मात्र क्लाइन्टले तपाईंलाई नीति दिइरहेको छ। कसमाथि भरोसा छ तय गर्नुहोस् र अर्कोलाई जान दिनुहोस्।