Wi-Fi तून सेल्युलरवर गेल्यानंतर किल स्विच: काय तुटते

एका क्षणी लॅपटॉप कार्यालयाच्या Wi-Fi वर आहे, पुढच्या क्षणी तो फोनला जोडलेला आहे, आणि तुम्ही खिडक्या बदलून पूर्ण करण्यापूर्वीच टनेलचा निर्देशक पुन्हा हिरवा आहे. हिरवा दिवा फक्त टनेल पुन्हा जोडला गेला हे सांगतो; त्या अंतरात राउटिंग आणि ब्लॉकिंग धोरणाने काय केले हा वेगळा प्रश्न आहे. ते धोरण शेवटच्या इन्स्टॉलेशनच्या वेळी संकलित झालेल्या जुळणी अटींचा संच आहे, आणि हस्तांतरणाने नुकतेच काढून टाकलेला इंटरफेस, पत्ता आणि पत्ता-कुटुंब यांची नावे घेते. म्हणून तोच बदल एकसारखे दिसणारे तीन परिणाम देतो: ब्लॉकिंग सुरू राहते, धोरण स्वतःची पुनर्प्राप्ती अडवते, किंवा काहीही न झाकणारा मार्ग उघडतो.

स्क्रीनवर त्या तीन अवस्था वेगळ्या करणारे काहीही नाही, म्हणून निर्देशक कोणता रंग दाखवतो हे न विचारता नियम कोणत्या ओळखींवर पिन केले होते हे विचारा. Linux वर नियम इंटरफेसचे नाव किंवा त्यातून भरलेला ipset सांगू शकतो; Android वर setUnderlyingNetworks द्वारे कोणत्या अंतर्निहित नेटवर्कचा पाठलाग करायचा हे VpnService ला सांगता येते. प्रत्येक जोडणी बदलल्या जाणाऱ्या दुव्याकडे निर्देश करते, आणि प्रत्येकाचे नंतर पुनर्मूल्यांकन करावे लागते.

हस्तांतरण प्रत्यक्षात काय पुन्हा लिहिते

जुना दुवा नाहीसा झाल्यावर कर्नेल त्याचे पत्ते काढून टाकते, त्यातून जाणारे मार्ग मागे घेते, आणि उरलेल्यातून स्रोत-पत्ता निवड पुन्हा बांधते. डीफॉल्ट मार्ग नव्या गेटवेवर जातो, आणि जुन्या नियमांनी संदर्भ दिलेला इंटरफेस निर्देशांक गेला आहे किंवा दुसऱ्या उपकरणासाठी पुनर्वापरला आहे. दुव्यानुसार रिझोल्व्हरही ताजे होतात, पण मार्गांच्या त्याच क्षणी नाही. हे सर्व VPN क्लायंटच्या खाली घडते, म्हणून फक्त स्वतःच्या टनेलची स्थिती पाहणाऱ्या क्लायंटला यातले काहीही दिसत नाही.

अडचण अशी आहे की नियम त्यामागील हेतूऐवजी विशिष्ट ओळख एन्कोड करतो. टनेल इंटरफेसमधून न निघणारे सर्व टाकून देणारा नियम इंटरफेसचे नाव एन्कोड करतो; अंत्यबिंदूला परवानगी देणारा नियम असा पत्ता एन्कोड करतो जो नवे नेटवर्क दुसरीकडे राउट करू शकते. ओळख नाहीशी झाल्यावर नियम दिसण्याजोगा चुकीचा होत नाही: तो एकतर कशाशीही जुळणे थांबवतो किंवा चुकीच्या गोष्टीशी जुळू लागतो.

भोक न पाडता बाहेरील टनेल पुन्हा बांधणे

बाहेरील वाहतूक जुन्या स्रोत-पत्त्याला बांधलेली होती, म्हणून तिला नव्यापासून नवे सॉकेट उघडावे लागते. अंत्यबिंदू शब्दशः पत्ता नसून होस्टनाव असल्यास, ब्लॉक लागू असतानाच शोध यशस्वी व्हायला हवा. हाच क्रमाचा सापळा: अंत्यबिंदू सोडून सर्व टाकण्याइतके कडक धोरण तो शोधण्यासाठी लागणारा शोधही टाकून देईल, जर ब्लॉक उचलण्यापूर्वी निराकरण झाले नाही किंवा अजून जिवंत टनेलमधून नेले नाही तर. दोन्ही क्रम चालू शकतात, पण क्लायंटला तो कोणत्या क्रमात आहे हे माहीत असेल तरच.

निदान करताना महत्त्वाच्या पद्धतीने क्लायंट इथे वेगळे आहेत. काही आधी निराकरण करतात आणि नंतर नियम बसवतात, त्यामुळे हस्तांतरणाला दिसणारा खंड पडतो आणि नंतर ते स्वतः सावरते; इतर ब्लॉक वर ठेवतात आणि शोध वाहून नेण्यासाठी टिकलेल्या टनेलवर अवलंबून राहतात, जे दुव्यासोबत टनेल मेल्यावर पूर्णपणे अपयशी ठरते. कनेक्टिव्हिटी परत आणण्यासाठी रुंद थेट डीफॉल्ट जोडल्यास चाचणी नेहमी पास होते आणि तुम्ही रोखत असलेला गळतीचा मार्ग नेहमी राहतो.

जुन्या गेटवेकडे अजूनही निर्देश करणारा मार्ग वेगळ्या कारणाने तोच अडकलेला सुधार देतो, म्हणून क्लायंटला दोष देण्यापूर्वी तक्ता वाचा. खालील आदेश कर्नेल प्रत्यक्षात वापरणारा इंटरफेस आणि स्रोत-पत्ता सांगतात, आणि त्यामुळे जुना मार्ग अजून बसवलेला आहे का हे एका ओळीत ठरते.

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

नवा दुवा IPv6 आणतो पण नियम आणत नाहीत तेव्हा

सेल्युलर आणि पाहुणे नेटवर्क कार्यालयाच्या तारेच्या LAN ने कधीही न दिलेला जागतिक IPv6 प्रीफिक्स अनेकदा देतात. फक्त 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 किंवा captive portal यांचा सेल्युलरवर समन्वय नाही, आणि त्यांच्यापर्यंत पोहोचणारा अपवाद समन्वय नसलेला नियम बनतो.

प्रत्येक दिशेसाठी इंटरफेसची नावे, दिली जाणारी कुटुंबे, लागू रिझोल्व्हर आणि खंडाची लांबी लिहा. पुन्हा जोडले जाणे म्हणजे वाहतूक सावरली हे सिद्ध होते, अंतरात ब्लॉक टिकला हे नाही, आणि हे तिकिटात टाकायचे वेगळे दावे आहेत. त्या नोंदीसह पुढील हस्तांतरणाची तुलना स्मरणाशी नाही तर ज्ञात स्थितीशी होते.