Wi-Fi से सेल्युलर पर जाने के बाद किल स्विच: क्या टूटता है

एक पल में लैपटॉप ऑफ़िस के Wi-Fi पर है, अगले पल में फ़ोन से जुड़ा है, और खिड़कियाँ बदलना खत्म करने से पहले ही टनल सूचक फिर हरा हो जाता है। हरी बत्ती केवल बताती है कि टनल फिर जुड़ गया; उस अंतराल में रूटिंग और ब्लॉकिंग नीति ने क्या किया, यह दूसरा सवाल है। वह नीति मिलान की शर्तों का एक समूह है जो पिछली बार इंस्टॉल होने पर संकलित हुआ था, और वह उस इंटरफ़ेस, पते और पता-परिवार का नाम लेती है जिन्हें हैंडओवर ने अभी हटाया है। इसलिए वही बदलाव तीन नतीजे देता है जो एक जैसे दिखते हैं: ब्लॉकिंग जारी रहती है, नीति अपनी ही रिकवरी को ब्लॉक कर देती है, या ऐसा रास्ता खुल जाता है जिसे कुछ भी नहीं ढकता।

स्क्रीन पर कुछ भी उन तीन अवस्थाओं को अलग नहीं करता, इसलिए यह पूछें कि नियम किन पहचानकर्ताओं पर टिकाए गए थे, न कि सूचक कौन-सा रंग दिखाता है। Linux पर कोई नियम किसी इंटरफ़ेस का नाम ले सकता है या उससे भरे ipset का; Android पर किसी VpnService को setUnderlyingNetworks के ज़रिए बताया जा सकता है कि किन अंतर्निहित नेटवर्क का पीछा करना है। हर बंधन ऐसी कड़ी की ओर इशारा करता है जो बदली जाने वाली है, और हर एक को बाद में फिर से आँकना पड़ता है।

हैंडओवर असल में क्या फिर से लिखता है

जब पुरानी कड़ी गायब होती है तो कर्नेल उसके पते हटा देता है, उससे होकर जाने वाले रूट वापस खींच लेता है, और जो बचता है उससे स्रोत-पता चुनाव फिर से बनाता है। डिफ़ॉल्ट रूट नए गेटवे पर चला जाता है, और पुराने नियमों ने जिस इंटरफ़ेस इंडेक्स का ज़िक्र किया था वह चला गया है या किसी दूसरे उपकरण के लिए फिर इस्तेमाल हो गया है। हर कड़ी के रिज़ॉल्वर भी ताज़ा होते हैं, हालाँकि रूट के उसी पल नहीं। यह सब VPN क्लाइंट के नीचे होता है, इसलिए जो क्लाइंट सिर्फ़ अपनी टनल की हालत देखता है उसे इसका कुछ नहीं दिखता।

मुश्किल यह है कि नियम अपने पीछे के इरादे की जगह किसी ख़ास पहचानकर्ता को एन्कोड करता है। टनल इंटरफ़ेस से बाहर न निकलने वाली हर चीज़ गिराने वाला नियम एक इंटरफ़ेस नाम एन्कोड करता है; अंतिम बिंदु को अनुमति देने वाला नियम ऐसा पता एन्कोड करता है जिसे नया नेटवर्क कहीं और रूट कर सकता है। पहचानकर्ता के गायब होने पर नियम साफ़ तौर पर ग़लत नहीं हो जाता: वह या तो किसी भी चीज़ से मेल खाना बंद कर देता है या ग़लत चीज़ से मेल खाने लगता है।

छेद किए बिना बाहरी टनल फिर बनाना

बाहरी परिवहन पुराने स्रोत-पते से बंधा था, इसलिए उसे नए पते से नया सॉकेट खोलना पड़ता है। जब अंतिम बिंदु शाब्दिक पता नहीं बल्कि होस्टनाम हो, तो ब्लॉक के चालू रहते ही खोज सफल होनी चाहिए। यही क्रम का जाल है: अंतिम बिंदु के अलावा सब कुछ गिराने के लिए काफ़ी सख़्त नीति उसे खोजने के लिए ज़रूरी खोज भी गिरा देगी, जब तक कि समाधान ब्लॉक उठाने से पहले न हो या किसी अभी ज़िंदा टनल से न ढोया जाए। दोनों क्रम काम कर सकते हैं, पर तभी जब क्लाइंट जानता हो कि वह किस क्रम में है।

क्लाइंट यहाँ उस तरह अलग होते हैं जो निदान के समय मायने रखता है। कुछ पहले हल करते हैं और बाद में नियम लगाते हैं, इसलिए हैंडओवर पर एक दिखने वाला व्यवधान आता है और फिर अपने आप ठीक हो जाता है; कुछ ब्लॉक बनाए रखते हैं और खोज ढोने के लिए बची हुई टनल पर निर्भर करते हैं, जो कड़ी के साथ टनल मर जाने पर पूरी तरह विफल हो जाता है। कनेक्टिविटी लौटाने के लिए चौड़ा सीधा डिफ़ॉल्ट जोड़ना जाँच को हमेशा पास करा देता है और आप जिस लीक को रोक रहे थे उसे हमेशा छोड़ जाता है।

पुराने गेटवे की ओर अब भी इशारा करता रूट किसी दूसरे कारण से वही अटकी हुई रिकवरी देता है, इसलिए क्लाइंट को दोष देने से पहले तालिका पढ़ें। नीचे के आदेश उस इंटरफ़ेस और स्रोत-पते का नाम लेते हैं जो कर्नेल वास्तव में इस्तेमाल करेगा, और यह एक पंक्ति में तय कर देता है कि पुराना रास्ता अब भी लगा है या नहीं।

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

जब नई कड़ी IPv6 लाती है और नियम नहीं

सेल्युलर और अतिथि नेटवर्क अक्सर वैश्विक IPv6 प्रीफ़िक्स देते हैं, भले ही ऑफ़िस के तार वाले LAN ने कभी न दिया हो। सिर्फ़ IPv4 नियमों के रूप में लिखी नीति — हाथ से बनी ज़्यादातर iptables और nftables विधियों का डिफ़ॉल्ट रूप — इसमें से कुछ भी नहीं ढकती। टनल जुड़ी रहती है, IPv6 पहुँच वाले अनुप्रयोग उसके बाहर निकल जाते हैं, और सूचक अंतर नहीं दिखा सकता क्योंकि टनल सचमुच चालू है। उल्टा मामला भी उतना ही आम है: सिर्फ़ IPv6 के लिए नियम-समूह ऐसे नेटवर्क पर कुछ नहीं करता जो v6 नहीं देता।

हैंडओवर के दोनों ओर तुलना करें कि कड़ी क्या देती है और नीति क्या बताती है। ये आदेश वही तथ्य छापते हैं जिनके साथ क्लाइंट काम करता है:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

अगर दूसरा आदेश डिफ़ॉल्ट रूट छापता है जबकि तीसरा शून्य लौटाता है, तो नई कड़ी मशीन को IPv6 से बाहर ले जा सकती है और कोई नियम उस पर नज़र नहीं रख रहा। बदलाव के बाद तीनों फिर चलाएँ, क्योंकि दिलचस्प संख्या दोनों चलानों का अंतर है। अगर दूसरा कुछ नहीं छापता, तो उल्टा मामला लागू है और वहाँ कोई भी v6-भारी नीति सिर्फ़ सजावट है।

रिज़ॉल्वर सत्र के बीच में हाथ बदलता है

आधुनिक सिस्टमों में रिज़ॉल्वर कड़ियों से जुड़े होते हैं, इसलिए नई कड़ी नए रिज़ॉल्वर-समूह के साथ और शायद अलग split-DNS दृश्य के साथ आती है। systemd-resolved प्रति कड़ी एक स्कोप रखता है और रूट के हिसाब से उनके बीच चुनता है, जबकि macOS डायनामिक स्टोर से scoped रिज़ॉल्वर पढ़ता है और इंटरफ़ेस का क्रम मानता है। जो क्लाइंट अपना रिज़ॉल्वर लगाता है वह कड़ी के रिज़ॉल्वर से मुक़ाबला करता है, और जिन प्राथमिकता नियमों को कोई नहीं देखता वही विजेता तय करते हैं। तब नाम-समाधान टूट सकता है जबकि पैकेट फ़िल्टरिंग ठीक वही कर रही हो जिसके लिए उसे लिखा गया था।

कॉन्फ़िगर किए गए रिज़ॉल्वर की जगह सक्रिय रिज़ॉल्वर पढ़ें। systemd होस्ट पर status उपादेश बताता है कि हर स्कोप किस कड़ी से आया और private-DNS नाम लागू है या नहीं:

resolvectl status --no-pager
resolvectl query intranet.example.com

अगर क्वेरी टनल की जगह भौतिक कड़ी से बाहर जाती है, तो क्लाइंट प्राथमिकता की बाज़ी हार गया है और कोई फ़ायरवॉल ट्यूनिंग नामकरण ठीक नहीं करेगी। हैंडओवर के दोनों ओर क्वेरी का रास्ता तुलना करें कि कौन हिला। जो नाम ऐसे निजी पते पर हल होता है जिसे नया नेटवर्क रूट नहीं कर सकता, वह तीसरा मामला है, और वह त्रुटि की जगह समय-समाप्ति के रूप में दिखता है।

हैंडओवर का अभ्यास करें और रिकॉर्ड रखें

बदलाव का इंतज़ार करने की जगह उसे जानबूझकर दोहराएँ। पहली कड़ी पर टनल चालू करें, एक लंबा स्थानांतरण और बार-बार होने वाली खोज शुरू करें, फिर कड़ी बदलें और देखें कौन बचता है। पुरानी कड़ी के गायब होने और टनल के जुड़े होने की सूचना के बीच का अंतराल लिखें, क्योंकि उसी खिड़की में नीति टिकी या नहीं। यह क्रम दूसरी दिशा में भी चलाएँ, ताकि नतीजा एकपक्षीय न हो।

अपवादों के लिए अपना अलग दौर चाहिए, क्योंकि पुराने नेटवर्क पर जायज़ बायपास नए पर अपने आप जायज़ नहीं होता। घर के LAN पर लगा प्रिंटर, NAS या कैप्टिव पोर्टल सेल्युलर पर बराबर का नहीं रखते, और जो अपवाद उन तक पहुँचता था वह बराबर के बिना नियम बन जाता है।

हर दिशा के लिए इंटरफ़ेस नाम, दिए गए परिवार, लागू रिज़ॉल्वर और व्यवधान की लंबाई लिखें। फिर से जुड़ना साबित करता है कि परिवहन लौट आया, यह नहीं कि अंतराल में ब्लॉक टिका रहा, और ये टिकट में डालने के अलग-अलग दावे हैं। उस रिकॉर्ड के साथ अगले हैंडओवर की तुलना याददाश्त से नहीं, ज्ञात स्थिति से होती है।