संपूर्ण टनेल लांब विभाजित-टनेल यादीपेक्षा सोपा आहे का?

विभाजित टनेलची यादी तीन अॅप्सपासून सुरू होते आणि शेवटी मशीनचा मोठा भाग व्यापते, आणि प्रत्येक नवीन ओळ ही कोणाचीतरी अपवाद असते। त्या टप्प्यावर यादी शांतपणे अतिरिक्त पायऱ्यांसह डीफॉल्ट झाली आहे। संपूर्ण टनेल ही रचना उलटते: दस्तऐवजीकृत अपवाद उलट सांगत नसेल तर सर्व काही टनेलमध्ये जाते। ते सोपे आहे का हे गेटवे आणि तुम्ही तोडणार असलेल्या स्थानिक सेवांवर अवलंबून आहे।

तुम्ही सांभाळता ते नियम मोजून सुरुवात करा

नोंदी मोजा, मग त्यातील कितींना नाव असलेला मालक आणि शेवटच्या पडताळणीची तारीख आहे ते मोजा। दुसरा आकडाच महत्त्वाचा आहे, कारण ज्या अपवादाचा कोणी मालक नाही, तो ज्या सॉफ्टवेअरचा उल्लेख करतो त्याचे नाव बदलले किंवा तो बदलला गेला की त्याचे मूल्यमापन करता येत नाही। एक्झिक्युटेबल मार्गाशी जोडलेले नियम अद्ययावतानंतर शांतपणे अपयशी ठरतात, आणि अपयश जुन्या नियमासारखे नव्हे, तर अस्थिर 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

पुन्हा जोडले गेल्यानंतर आणि खंडानंतर तपासणीची पुनरावृत्ती करा, कारण खंडादरम्यान वाहतूक अडवणारा स्विच नंतर योग्यरीत्या पुनर्संचयित होणाऱ्या मार्गापेक्षा वेगळा गुणधर्म आहे। सोपे रचना तीच जिची खरी व्याप्ती अॅप किंवा नेटवर्क बदलल्यानंतरही तुम्ही अजूनही समजावून सांगू शकता।