क्या पूरा टनल लंबी विभाजित-टनल सूची से ज़्यादा सरल है?
ज़्यादातर ऐप्स को कवर करने वाली अपवाद-सूची एक छिपा हुआ डिफ़ॉल्ट है। नियम गिनें, गेटवे जाँचें, फिर एक प्रोफ़ाइल माइग्रेट करें और दोनों किनारों की पुष्टि करें।
विभाजित-टनल सूची तीन ऐप्स से शुरू होकर मशीन का ज़्यादातर हिस्सा ढक लेती है, और हर नई पंक्ति किसी का अपवाद होती है। उस बिंदु पर सूची चुपचाप अतिरिक्त क़दमों वाला डिफ़ॉल्ट बन चुकी है। पूरा टनल व्यवस्था को उलट देता है: सब कुछ टनल में जाता है जब तक कोई दर्ज अपवाद उलटा न कहे। यह ज़्यादा सरल है या नहीं, यह गेटवे और उन स्थानीय सेवाओं पर निर्भर करता है जिन्हें आप तोड़ेंगे।
आप जिन नियमों का रखरखाव करते हैं, उन्हें गिनकर शुरू करें
प्रविष्टियाँ गिनें, फिर गिनें कि कितनों का नामित मालिक है और अंतिम सत्यापन की तारीख़ है। दूसरा आँकड़ा ही मायने रखता है, क्योंकि जिस अपवाद का कोई मालिक न हो, उसे तब मूल्यांकित नहीं किया जा सकता जब जिस सॉफ़्टवेयर का वह हवाला देता है, उसका नाम बदले या वह बदल दिया जाए। निष्पादन-योग्य पथ से जुड़े नियम अपडेट के बाद चुपचाप विफल हो जाते हैं, और विफलता पुराने नियम जैसी नहीं, बल्कि अस्थिर VPN जैसी दिखती है। इस पर राय बनाने से पहले सूची लिख लें।
हर प्रविष्टि को तीन सवालों के जवाब देने चाहिए: इसके बिना क्या टूटता है, यह किसने तय किया, और अगर कारण ख़त्म हो गया तो आप कैसे पता लगाएँगे। जो प्रविष्टियाँ तीनों का जवाब नहीं दे सकतीं, वे माइग्रेशन के बजाय हटाने की उम्मीदवार हैं, और उन्हें पहले हटाना बाद की तुलना को ईमानदार बनाता है।
अगर ज़्यादातर प्रविष्टियाँ ट्रैफ़िक का बड़ा हिस्सा रूट करती हैं, तो आप पहले से ही रखरखाव के बोझ के साथ पूरा टनल चला रहे हैं। तब फ़ैसला इस पर है कि डिफ़ॉल्ट कहाँ रहता है, इस पर नहीं कि वह होना चाहिए या नहीं।
जाँचें कि गेटवे डिफ़ॉल्ट उठा सकता है या नहीं
पूरा टनल हर पैकेट को एक ही डिवाइस पर ले जाता है, जो एक साथ उस डिवाइस का प्रोसेसर भार, conntrack तालिका, पता अनुवाद और अपस्ट्रीम बैंडविड्थ की ज़रूरत बदल देता है। जिस गेटवे ने कुछ आंतरिक सबनेट आराम से संभाले थे, वह किसी उपयोगकर्ता की पूरी ब्राउज़िंग के लिए नापा नहीं गया हो सकता है। औसत के बजाय उस सबसे बड़ी समवर्ती सत्र संख्या को देखें जिसकी आप अपेक्षा करते हैं, क्योंकि सबसे पहले शिखर टूटता है।
ip -s link show dev tun0
conntrack -C
ss -s
बदलाव से पहले और बाद में वही कार्यभार मापें, विनिर्देशों से तर्क करने के बजाय। एक मशीन पर एक दोपहर का सामान्य उपयोग दिखा देगा कि गेटवे किसी सीमा के क़रीब है या नहीं, और सोमवार सुबह उसे खोजने की तुलना में इसमें कुछ ख़र्च नहीं होता।
पथ का MTU भी शुरू से अंत तक जाँचें, क्योंकि पूरा डिफ़ॉल्ट हर ऐप को टनल के अधिकतम पैकेट आकार के सामने खोल देता है। जो ऐप्स टनल के बाहर काम करते थे, वे अब ऐसे विखंडन व्यवहार पर निर्भर हो सकते हैं जिसके बारे में आपको कभी सोचना नहीं पड़ा।
पुष्टि करें कि स्थानीय सेवाएँ और निजी DNS अब भी काम करते हैं
क्या स्थानीय रहना चाहिए, इसे ऐप के नाम के बजाय प्रोटोकॉल के हिसाब से सूचीबद्ध करें: प्रिंटर और डिस्प्ले के लिए खोज प्रोटोकॉल, स्मार्ट-होम ब्रिज, राउटर का प्रबंधन पृष्ठ, स्थानीय विकास सर्वर जिस तक ऐसे नाम से पहुँचा जाता है जो केवल LAN पर हल होता है। डिफ़ॉल्ट रूट के टनल की ओर इशारा करते ही ये टूटते हैं, और चुपचाप टूटते हैं क्योंकि क्लाइंट पर कुछ भी त्रुटि दर्ज नहीं करता।
निजी DNS दूसरी निर्भरता है। अगर आंतरिक नाम पहले टनल के रिज़ॉल्वर से हल होते थे, तो कुछ नहीं बदलता; अगर वे स्थानीय रूप से हल होते थे, तो पूरे डिफ़ॉल्ट को उन्हें ऐसे रिज़ॉल्वर तक ले जाना होगा जो ज़ोन जानता है। बदलाव के बाद एक आंतरिक और एक सार्वजनिक नाम जाँचें, बजाय यह मानने के कि रिज़ॉल्वर सूची बच गई।
स्थानीय अपवाद उसी प्रोफ़ाइल में लिखें जिसका वे हैं। केवल किसी की याद में रखा अपवाद ही अगले माइग्रेशन में सबसे पहले खोता है।
एक प्रोफ़ाइल माइग्रेट करें और सीमाओं की पुष्टि करें
प्रोफ़ाइल को उसकी अपनी कॉन्फ़िगरेशन से बदलें, पहले के प्रयोगों द्वारा छोड़े गए मैनुअल रूटों के ऊपर नया डिफ़ॉल्ट चढ़ाने के बजाय। वही बचे हुए रूट आम तौर पर ऐसे माइग्रेशन का कारण होते हैं जो काम करता दिखता है और एक दिन बाद असंगत व्यवहार करता है। पुरानी प्रोफ़ाइल उपलब्ध रखें ताकि वापसी पुनर्निर्माण नहीं, चयन हो।
फिर दो सीमाएँ अलग-अलग जाँचें: सार्वजनिक और निजी गंतव्य दोनों काम करते हैं, और अनचाहा ट्रैफ़िक टनल के बाहर नहीं जाता। सफल पृष्ठ लोड पहली बात साबित करता है और दूसरी के बारे में कुछ नहीं कहता।
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com
फिर से कनेक्ट होने के बाद और कटौती के बाद जाँच दोहराएँ, क्योंकि कटौती के दौरान ट्रैफ़िक रोकने वाला स्विच उस रूट से अलग गुण है जो बाद में सही ढंग से बहाल होता है। ज़्यादा सरल डिज़ाइन वह है जिसकी वास्तविक कवरेज आप ऐप या नेटवर्क बदलने के बाद भी समझा सकें।