एकाच वेळी दोन 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।
मग जे लोक सोडून देतात ते पाऊल उचला: बोगदा जाणूनबुजून थांबवा आणि ज्या रहदारीचे अपयश अपेक्षित आहे ते खरोखर अपयशी होते याची खात्री करा। जोडलेले चिन्ह ही इंटरफेसची स्थिती आहे, अंमलबजावणी नाही।
कधी दोन क्लायंट चुकीची रचना आहेत
जर दुसऱ्या ॲपमागील एकमेव मागणी जास्त संरक्षण असेल, तर ते काढून टाका। दोन परस्पर क्रिया करणाऱ्या अडवण्याच्या धोरणांचा अंदाज एकापेक्षा कमी लागतो, आणि प्रत्येक पुनर्जोडणी ही कोणत्याही विक्रेत्याने तपासली न जाणारी स्थिती गाठण्याची संधी आहे।
जर खरोखर साखळी जोडणी हवी असेल, उदाहरणार्थ व्यापारी उडीने गाठलेला कॉर्पोरेट गेटवे, तर एकच अंमलबजावणी बिंदू असलेली रचना निवडा। याचा अर्थ सहसा एक राउटर किंवा एकच क्लायंट जो साखळीला आधार देतो, असे नव्हे की एकाच डीफॉल्ट मार्गासाठी स्पर्धा करणारी दोन डेस्कटॉप ॲप्स। व्यवस्थापित उपकरणावर मंजूर क्लायंट ठेवा आणि बाकी सर्व व्याप्तीबाहेर माना, ट्रेमध्ये काहीही दाखवले तरी।
दोन्ही ठेवण्यापूर्वी तपासणी यादी
यादी क्रमाने पूर्ण करा; पहिला अपयशी ठरणारा मुद्दा हाच दुरुस्त करायचा आहे।
- नेमक्या एका क्लायंटकडे डीफॉल्ट मार्ग आणि रिझॉल्व्हर आहे याची खात्री करा।
- जर दुसरा क्लायंट वर ठेवायचा असेल, तर त्याच्या सर्व्हरच्या टोकबिंदूला स्पष्ट परवानगी द्या आणि प्रत्येक क्लायंट अद्ययावतानंतर पुन्हा तपासा।
- कोणताही बोगदा कोसळल्यावर अपेक्षित निकाल लिहा आणि नेमकी तीच स्थिती तपासा।
- रीबूटनंतर अपयशाचा मार्ग तपासा, जेव्हा सुरुवातीचा क्रम वेगळा असतो।
- व्यवस्थापित प्रोफाइलवर थांबा आणि काहीही जोडण्यापूर्वी मालकाला विचारा।
जर तिसरे पाऊल अपयशी झाले, तर खरे उत्तर हे आहे की फक्त एकच क्लायंट तुम्हाला धोरण देत आहे। कोणावर विश्वास आहे ते ठरवा आणि दुसऱ्याला जाऊ द्या।