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 को सेलुलरमा समकक्ष हुँदैन, र तिनीहरूसम्म पुग्ने अपवाद समकक्षविहीन नियम बन्छ।

प्रत्येक दिशाका लागि इन्टरफेसका नाम, दिइने परिवार, लागू रिजोल्भर र अवरोधको लम्बाइ लेख्नुहोस्। पुनः जोडिनु भनेको यातायात सुधारियो भन्ने प्रमाण हो, अन्तरालमा ब्लक टिक्यो भन्ने होइन, र यी टिकटमा राख्ने छुट्टै दाबी हुन्। त्यो अभिलेखसँग अर्को हस्तान्तरणको तुलना स्मृतिसँग होइन, ज्ञात अवस्थासँग गरिन्छ।