सर्वर बदलते समय kill switch ट्रैफ़िक क्यों गिरा देता है
सर्वर बदलाव के दौरान kill switch ट्रैफ़िक को क्यों रोकता है, उस दौरान क्लाइंट क्या करता है, और सामान्य ठहराव तथा अटके हुए ब्लॉक में कैसे फ़र्क़ करें।
आप कोई नज़दीक दिखने वाला सर्वर चुनते हैं, कनेक्ट दबाते हैं, और नया टनल बनने से पहले ही ब्राउज़र लोड होना बंद कर देता है। आइकन कनेक्ट होने की स्थिति में बदल जाता है और तब तक वहीं रहता है जब तक हर टैब का समय ख़त्म न हो जाए। यह ठहराव आम तौर पर kill switch का डिज़ाइन के मुताबिक काम है: ट्रैफ़िक तब तक अवरुद्ध रहता है जब तक क्लाइंट के पास उसे भेजने का कोई टनल न हो। ठहराव स्वीकार्य है या नहीं, यह इस पर निर्भर है कि क्लाइंट उन सेकंडों में क्या करता है और जब वह कहता है कि ब्लॉक हट गया तो सचमुच हटता है या नहीं।
दो सर्वरों के बीच क्लाइंट क्या करता है
एंडपॉइंट बदलना एक स्विच नहीं, कई चरण हैं। क्लाइंट मौजूदा टनल तोड़ता है, अपने ब्लॉकिंग नियम अपडेट करता है, नया एंडपॉइंट रिज़ॉल्व करके टनल के बाहर से उस तक पहुँचता है, फिर नए रूट लगाता है और ब्लॉक हटाता है। आप जो अंतराल महसूस करते हैं वह पहले चरण और आख़िरी चरण के बीच होता है।
यहाँ क्रम गति से ज़्यादा मायने रखता है। अगर ब्लॉकिंग नियम नए एंडपॉइंट के अपवाद से पहले लागू हो जाएँ, तो क्लाइंट हैंडशेक पूरा नहीं कर पाता और टाइमआउट तक कनेक्ट होने की स्थिति में रहता है। अगर अपवाद पुराने सर्वर के पते की नकल है, तो नया हैंडशेक किसी भी अन्य आउटबाउंड पैकेट जैसा दिखता है और गिरा दिया जाता है। दोनों स्थितियाँ ब्राउज़र से एक जैसी दिखती हैं, इसलिए छह सेकंड बाद सुधरने वाला बदलाव और कभी न सुधरने वाला बदलाव एक ही कारण साझा कर सकते हैं।
नए एंडपॉइंट के लिए ब्लॉक में एक छेद चाहिए
टनल बनाने के लिए क्लाइंट को भौतिक इंटरफ़ेस पर नए सर्वर के पते और पोर्ट पर पैकेट भेजने होते हैं, जैसे किसी सामान्य WireGuard प्रोफ़ाइल के लिए UDP 51820 या OpenVPN के लिए 1194 और 443, जो भी आपकी अपनी प्रोफ़ाइल तय करे। वह ट्रैफ़िक उस टनल के अंदर नहीं है जो अभी बनने वाला है, इसलिए पूरे डिवाइस के लिए लगाया गया ब्लॉक उसे निगल जाता है, जब तक मेल खाता अनुमति नियम मौजूद न हो।
होस्टनाम आधारित प्रोफ़ाइल एक दूसरी शर्त जोड़ती हैं: ख़ुद लुकअप। अगर क्लाइंट ब्लॉक उठने से पहले एंडपॉइंट रिज़ॉल्व कर ले, तो वह कैश किया गया पता इस्तेमाल कर सकता है, लेकिन जब प्रोफ़ाइल पते बदले या कैश प्रविष्टि पुरानी हो जाए, तो हैंडशेक ऐसे पते की ओर जाता है जिसे अनुमति नियम कवर नहीं करता। IPv6 इसे दिखने लायक बनाता है, क्योंकि दोहरे स्टैक वाला एंडपॉइंट A और AAAA दोनों रिकॉर्ड प्रकाशित कर सकता है, और केवल v4 पता कवर करने वाला अनुमति नियम क्लाइंट को अवरुद्ध v6 पते के ख़िलाफ़ फिर से कोशिश करता छोड़ देता है।
विकल्पों के नाम और डिफ़ॉल्ट मान क्लाइंट और संस्करण के हिसाब से बदलते हैं, इसलिए स्क्रीनशॉट से अनुमान लगाने के बजाय अपने क्लाइंट के लिए दस्तावेज़ी सूची पढ़ें। OpenVPN Connect की सेटिंग्स संदर्भ openvpn.net/connect-docs/app-settings-windows पर एक उदाहरण है कि कोई क्लाइंट अपने ब्लॉक और स्प्लिट-टनल विकल्पों का वर्णन कैसे करता है।
Fail-closed एक स्टेट मशीन है, स्विच नहीं
ज़्यादातर क्लाइंट ब्लॉक को फ़ायरवॉल नीति के रूप में तीन स्थितियों में व्यक्त करते हैं: टनल ऊपर, ट्रैफ़िक टनल से जा रहा है और कोई ब्लॉक नहीं; टनल नीचे, ब्लॉक सक्रिय; और संक्रमण, ब्लॉक सक्रिय के साथ एंडपॉइंट के लिए अस्थायी अपवाद। तीसरी स्थिति में ही बग रहते हैं, क्योंकि उसे कुछ सेकंड में दो बार बदलना पड़ता है, और उससे बाहर न निकल पाना ठीक स्थायी ब्लॉक जैसा दिखता है।
तंत्र प्लेटफ़ॉर्म के हिसाब से अलग है, और विफलता भी। Windows Filtering Platform के फ़िल्टर में भार होता है, इसलिए आपकी अनुमति को पछाड़ने वाला ब्लॉक फ़िल्टर अनुमति होने पर भी पैकेट गिराता रहता है, और मारे गए क्लाइंट प्रोसेस द्वारा छोड़े गए फ़िल्टर ऐप जाने के बाद भी मशीन को ऑफ़लाइन रख सकते हैं। macOS क्लाइंट आम तौर पर pf नियम किसी एंकर में लिखते हैं, जहाँ नियमों का क्रम और तेज़ निर्णय तय करते हैं कि कौन-सा नियम लागू होगा। Linux क्लाइंट आम तौर पर drop नीति वाली nftables या iptables चेन चलाते हैं और एंडपॉइंट, टनल इंटरफ़ेस तथा लूपबैक के लिए स्पष्ट अनुमतियाँ देते हैं। Android का always-on VPN, VPN के बिना कनेक्शन ब्लॉक करने के विकल्प के साथ, समूह में सबसे सख़्त है, क्योंकि ऑपरेटिंग सिस्टम ब्लॉक को पूरे डिवाइस पर लागू करता है, प्रति ऐप नहीं।
WireGuard को अपना नोट चाहिए, क्योंकि AllowedIPs एक रूटिंग चयनक है, ब्लॉकर नहीं। यह तय करता है कि कौन-से गंतव्य टनल में जाएँगे; जिस पैकेट के पास अभी टनल नहीं है उसे Wi-Fi से बाहर जाने से रोकने के लिए यह कुछ नहीं करता। केवल WireGuard और बिना फ़ायरवॉल नियम वाले सेटअप में kill switch असल में रूट की अनुपस्थिति है, और गिराए गए हैंडशेक के बाद भौतिक इंटरफ़ेस से असली पैकेट बाहर जा सकता है।
आइकन देखने के बजाय अंतराल नापें
स्टेटस बत्ती नहीं, पैकेट देखें। Linux में एक टर्मिनल में किसी सार्वजनिक पते पर धीमा ping शुरू करें और दूसरे में भौतिक इंटरफ़ेस पर टनल का ट्रांसपोर्ट पोर्ट कैप्चर करें:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
दोनों के चलते हुए क्लाइंट में सर्वर बदलें। तीन बातें मायने रखती हैं: ping कितनी देर रुकते हैं, कैप्चर दिखाता है कि हैंडशेक नए एंडपॉइंट तक पहुँचता है या नहीं, और ट्रैफ़िक क्लाइंट की स्थिति कनेक्टेड होने से पहले लौटता है या बाद में। अगर ping का अंतराल पहले ख़त्म हो, तो या तो ब्लॉक जल्दी हट गया या इंडिकेटर के स्वीकार करने से पहले ही टनल चालू है। अगर अंतराल बाद में ख़त्म हो, तो इंडिकेटर ज़रूरत से ज़्यादा आशावादी है।
Windows में netsh wfp show state एक स्नैपशॉट लिखता है जिसमें आप ऐसे ब्लॉक फ़िल्टर खोज सकते हैं जो अब भी मौजूद हैं जबकि क्लाइंट ख़ुद को डिस्कनेक्टेड बताता है। macOS में sudo pfctl -sr लोड किए गए नियम और उनका क्रम सूचीबद्ध करता है। किसी भी स्नैपशॉट को क्लाइंट के अपने लॉग के साथ मिलाएँ; आपके ping की समयरेखा बताती है कि ब्लॉक देर से ख़त्म हुआ या कभी नहीं।
सामान्य अंधेरा बनाम अटका हुआ ब्लॉक
थोड़ा व्यवधान इस सुविधा का उद्देश्य है, इसलिए कोई भी सेटिंग बदलने से पहले वर्गीकरण करें:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
अगर आप दूसरी या पाँचवीं पंक्ति में पहुँचें, तो जाँच के लिए kill switch बंद न करें, क्योंकि इससे रूटिंग बग लीक में बदल जाता है। क्लाइंट की सेवा फिर शुरू करें, या जहाँ प्रोसेस मारने पर भी फ़िल्टर टिके रहते हैं वहाँ मशीन रीबूट करें, फिर देखें कि ब्लॉक साफ़ होता है या नहीं। अगर होता है, तो दोष ब्लॉक का नहीं बल्कि बदलाव के दौरान सफ़ाई का है।
अगले बदलाव से पहले चार बातें पक्की करें: एंडपॉइंट अनुमति आपकी प्रोफ़ाइल जो भी पता-परिवार रिज़ॉल्व करती है उन सभी को कवर करती है, क्लाइंट लॉग संक्रमण पूरा होना दिखाता है, आपकी ping जाँच आइकन नहीं बल्कि अंतराल नापती है, और क्लाइंट बंद करने से सामान्य कनेक्टिविटी लौट आती है। जो kill switch बदलाव के दौरान टिकता है और बाद में छोड़ता है वह अपना काम कर रहा है। जो जल्दी छोड़ता है, या कभी नहीं, वह डिबग करने लायक है।