किल स्विच किसी भी ट्रैफ़िक के बहने से पहले VPN सर्वर को रोक देता है
किल स्विच किस चरण को रोकता है: एंडपॉइंट खोज, बाहरी रूट, वापसी का रास्ता और पुराने पीयर अपवाद — अनुमान के बजाय काउंटरों के साथ।
किल स्विच उस दिशा में विफल होते हैं जिसकी लोग अपेक्षा नहीं करते: वे टनल बंद होने पर ट्रैफ़िक रोकने के लिए बने हैं, और टनल बनाने वाले पैकेट स्वयं ट्रैफ़िक हैं। पूरी गड़बड़ी यही है। जो नियम-समूह टनल से बाहर न जाने वाली हर चीज़ को गिरा देता है, वह उस हैंडशेक को भी गिरा देता है जो उसे ऊपर उठाता, इसलिए क्लाइंट लूप में फिर कोशिश करता है और त्रुटि उसी चरण को दी जाती है जो पहले जाँचा जाता है। फ़ायरवॉल चौड़ा करने से पहले पता लगाएँ कि तीन चरणों में से कौन अस्वीकार हो रहा है: नाम की खोज, पीयर तक जाने वाला बाहरी पैकेट, या लौटता हुआ उत्तर।
टनल और उसका अपना परिवहन एक-दूसरे पर कैसे निर्भर हैं
VPN क्लाइंट को एक ही सॉकेट पथ साझा करने वाली दो नेटवर्क अवस्थाओं की तरह पढ़ें। टनल के अस्तित्व से पहले क्लाइंट भौतिक अडैप्टर पर सॉकेट खोलता है और एन्क्रिप्टेड फ़्रेम पीयर के पते और पोर्ट पर भेजता है। उस अदला-बदली के सफल होने के बाद ही वह टनल डिवाइस बनाता है और रूट स्थापित करता है। किल स्विच दूसरी अवस्था के बारे में नीति है, इतनी व्यापक लिखी गई कि दोनों पर लागू हो।
इंटरफ़ेस-आधारित नियम सामान्य रूप हैं: जो इससे बाहर जाता है उसे स्वीकारें tun0 या wg0, बाकी आउटपुट पथ गिरा दें। यह सूत्र क्लाइंट के अपने सर्वर-कनेक्शन को छूट नहीं दे सकता, इसलिए सही कार्यान्वयन वह अपवाद स्पष्ट रूप से जोड़ता है, और हाथ से नियम लिखते समय आप भी ऐसा करते हैं। Windows और macOS पर प्रति-एप्लिकेशन नियम इंटरफ़ेस के बजाय प्रक्रिया का मिलान करके इसका कुछ हिस्सा बचाते हैं, पर प्रक्रिया को टनल बनने से पहले बाहर निकलना ही होता है।
तीन चरण, उसी क्रम में जिसमें वे होते हैं
पहला चरण रिज़ॉल्यूशन है। जब प्रोफ़ाइल शाब्दिक पते के बजाय होस्टनेम रखती है, तो कुछ भी भेजने से पहले क्लाइंट को DNS उत्तर चाहिए। जो प्रोफ़ाइल DNS को टनल रिज़ॉल्वर की ओर भेजती है वह गतिरोध बनाती है: रिज़ॉल्वर केवल उसी टनल से पहुँच में है जिसे खोज सक्षम करनी चाहिए। टनल के बाहर हल करना, या एंडपॉइंट को किसी पते पर पिन करना, यह अस्पष्टता हटा देता है।
दूसरा चरण बाहरी पैकेट है, जिसे इसी क्रम में पहले रूटिंग और फिर फ़ायरवॉल पार करना होता है। wireguard-tools WireGuard के लिए इसका रूटिंग वाला आधा हिस्सा अपने पैकेट चिह्नित करके और नीति नियम जोड़कर संभालता है ताकि वे अभी स्थापित डिफ़ॉल्ट रूट को छोड़ दें; wg-quick का मैन पेज उस नियम और उस तालिका का वर्णन करता है जो वह उपयोग करता है। उस रूटिंग को हाथ से फिर बनाएँ, या किसी दूसरे उपकरण को नियम फिर से लिखने दें, और चिह्नित पैकेट उसी टनल में वापस भेजे जा सकते हैं जिसे उन्हें बनाना है।
तीसरा चरण वापसी का रास्ता है। बिना उत्तर वाला हैंडशेक बाहर की ओर गिराए जाने का प्रमाण नहीं है; यह सर्वर के इनबाउंड नियम या मैपिंग भूल चुके NAT उपकरण के साथ उतना ही मेल खाता है। क्लाइंट को छूने से पहले इन्हें अलग करें।
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
क्लाइंट वह लक्षण दर्ज करते हैं जो वे पकड़ते हैं, वह चरण नहीं जो विफल हुआ, इसलिए तालिका आमतौर पर लॉग से तेज़ होती है।
काउंटर लॉग से तेज़ निर्णय देते हैं
Linux पर, nft list ruleset या iptables -vnL OUTPUT प्रति नियम एक पैकेट काउंटर छापता है। एक बार कनेक्ट करें, विफल होने दें, फिर काउंटर दोबारा पढ़ें। जिस नियम का काउंटर हिला वही वह नियम है जिससे हैंडशेक टकराया; अगर कहीं कुछ नहीं हिला, तो पैकेट कभी फ़ायरवॉल तक नहीं पहुँचा। मैंने एक नियम-समूह को अपना ही हैंडशेक गिराते देखा है, और यह केवल काउंटरों ने बताया।
कभी फ़ायरवॉल तक न पहुँचा और कभी होस्ट से बाहर न गया—इन्हें अलग करने के लिए इंटरफ़ेस को ही देखें। ip -s link show dev wlan0 भेजे गए पैकेट बताता है, और tcpdump -ni wlan0 udp port 51820 फ़्रेम दिखाता है। अगर क्लाइंट के फिर कोशिश करते समय यह सपाट रहता है, तो खराबी netfilter के ऊपर है: गायब पीयर रूट, ऐसे उपकरण की ओर इशारा करता नीति नियम जो अभी नहीं है, या वह सॉकेट त्रुटि जिसे क्लाइंट निगल जाता है।
दस्तावेज़ी पतों पर अपवाद जाँचें, जैसे 203.0.113.10, ताकि कोई चूक किसी और के होस्ट को न छेड़ सके।
पुराना एंडपॉइंट अपवाद सर्वर बंद होने जैसा पढ़ा जाता है
सबसे भ्रामक संस्करण पीयर का पता बदलने के बाद आता है: किसी गतिशील-पता सेवा ने उसे खिसका दिया, होस्ट फिर से बना, या आपके नेटवर्क का आउटगोइंग पता अलग है। अपवाद अब भी पुराने पते का नाम लेता है, इसलिए नए पते की ओर जाने वाले पैकेट गिराने वाले नियम पर पड़ते हैं। वही कॉन्फ़िगरेशन कल काम कर रहा था, और इसीलिए लोग सर्वर की खराबी खोजने से शुरू करते हैं।
फ़ायरवॉल नियम के अंदर का होस्टनेम आपको नहीं बचाता। nftables में नाम नियम-समूह लोड होते समय हल होता है, इसलिए वह उस क्षण मौजूद पते को पिन कर देता है और शाब्दिक पते की तरह पुराना हो जाता है। टिकाऊ उपाय है कि एंडपॉइंट बदलने पर अपवाद अपडेट करें और उसे संकीर्ण रखें: एक पीयर पता, एक परिवहन पोर्ट। पता-परिवर्तन झेलने लायक चौड़ी श्रेणी असंबंधित ट्रैफ़िक को बाहर जाने देने लायक भी चौड़ी होती है।
जब किल स्विच सर्वर होस्ट पर चलता है
वही निर्भरता दूसरे सिरे पर भी है, और वहाँ इसे चूकना आसान है। अगर आपके VPN सर्वर का काम करने वाला मशीन किल स्विच वाला डेस्कटॉप क्लाइंट भी चलाता है, या लैपटॉप से कॉपी की गई फ़ायरवॉल प्रोफ़ाइल चलाता है, तो उसके गिराने वाले नियम टनल समाप्त करने वाली सेवा पर लागू होते हैं। क्लाइंट के हैंडशेक के उत्तर गिरा दिए जाते हैं, इसलिए सर्वर स्वस्थ दिखते हुए और उसका टनल इंटरफ़ेस बेकार पड़े रहने के बावजूद हर क्लाइंट जुड़ नहीं पाता।
उस होस्ट को गिराने से पहले तीन संकीर्ण स्वीकृतियाँ चाहिए: भौतिक इंटरफ़ेस पर सुनने का पोर्ट, डिक्रिप्टेड ट्रैफ़िक के लिए टनल इंटरफ़ेस, और टनल से उस ओर फ़ॉरवर्डिंग जहाँ क्लाइंट को पहुँचना है। स्थापित समूह को इससे पढ़ें: nft list ruleset, iptables -S, या pfctl -sr कुछ भी बदलने से पहले, और याद रखें कि सहेजा गया नियम-समूह रीबूट के बाद भी टिकता है, इसलिए वहाँ की गलती उसे बनाने वाली प्रक्रिया से अधिक जीती है।
मशीन को बंद रखने वाला पुनर्प्राप्ति क्रम
प्रोफ़ाइल से बाहर की ओर काम करें। क्लाइंट जो पीयर पता और पोर्ट उपयोग करता है उसे पढ़ें, पुष्टि करें कि होस्टनेम बिना टनल के हल होता है, फिर केवल भौतिक अडैप्टर पर उस पते और पोर्ट के लिए एक अपवाद जोड़ें। फिर जुड़ें और भेजने का काउंटर देखें; पूरा हुआ हैंडशेक यह संकेत है कि दूसरा चरण ठीक हो गया।
परीक्षण के दौरान गिराने की बाकी नीति यथास्थान रहने दें। निर्दोष जाँच यह है कि किसी असंबंधित दस्तावेज़ी पते पर कनेक्शन का प्रयास करें और पुष्टि करें कि वह अब भी समय-समाप्ति पर जाता है, जो दिखाता है कि किल स्विच बंद नहीं बल्कि काम कर रहा है। टनल स्थिर होने पर अपवाद कसें, और सुविधा के कारण क्लाइंट प्रोग्राम के लिए स्थायी सब-कुछ-की-अनुमति न छोड़ें।
अगर टनल ऊपर आ जाए और एप्लिकेशन फिर भी विफल हो, तो बाकी चरण यह नहीं हैं: विभाजित DNS, MTU और प्रति-एप्लिकेशन रूटिंग में से हर एक जुड़ी हुई टनल के साथ टूटा ट्रैफ़िक देता है, और हर एक की पहली जाँच अलग है।