के पूर्ण टनेलिङ लामो स्प्लिट-टनेल सूचीभन्दा सरल हुन्छ?

स्प्लिट-टनेल सूची तीन एपबाट सुरु भएर मेसिनको अधिकांश भाग समेट्छ, र हरेक नयाँ हरफ कसैको अपवाद हुन्छ। त्यस बिन्दुमा सूची चुपचाप थप चरणसहितको पूर्वनिर्धारित बनिसकेको हुन्छ। पूर्ण टनेलिङले व्यवस्था उल्टाउँछ: कागजातमा उल्लेख गरिएको बहिष्कारले अन्यथा नभनेसम्म सबै कुरा टनेलभित्र जान्छ। त्यो सरल छ कि छैन भन्ने गेटवे र तपाईंले बिगार्ने स्थानीय सेवाहरूमा निर्भर गर्छ।

तपाईंले मर्मत गर्ने नियम गनेर सुरु गर्नुहोस्

प्रविष्टिहरू गन्नुहोस्, त्यसपछि कतिमा नाम दिइएको मालिक र अन्तिम पटक प्रमाणित गरिएको मिति छ भनी गन्नुहोस्। दोस्रो सङ्ख्या महत्त्वपूर्ण हुन्छ, किनकि कसैको स्वामित्व नभएको अपवादलाई यसले सन्दर्भ गर्ने सफ्टवेयरको नाम परिवर्तन वा प्रतिस्थापन हुँदा मूल्याङ्कन गर्न सकिँदैन। कार्यान्वयनयोग्य पथमा आधारित नियमहरू अद्यावधिकपछि चुपचाप असफल हुन्छन्, र असफलता पुरानो नियमभन्दा VPN अस्थिर भएजस्तो देखिन्छ। यसबारे धारणा बनाउनुअघि सूची लेख्नुहोस्।

हरेक प्रविष्टिले तीन प्रश्नको उत्तर दिनुपर्छ: यो बिना के बिग्रन्छ, त्यो कसको निर्णय थियो, र कारण समाप्त भएमा तपाईंले कसरी थाहा पाउनुहुन्छ। तीनै प्रश्नको उत्तर दिन नसक्ने प्रविष्टिहरू स्थानान्तरणभन्दा मेटाउने उम्मेदवार हुन्, र पहिले तिनै मेटाउँदा पछिको तुलना इमानदार हुन्छ।

यदि अधिकांश प्रविष्टिले ठूलो हिस्सा ट्राफिक रुट गर्छन् भने, तपाईं पहिले नै मर्मतको भारसहित पूर्ण टनेल चलाइरहनुभएको छ। तब निर्णय पूर्वनिर्धारित कहाँ बस्छ भन्नेमा हुन्छ, पूर्वनिर्धारित चाहिन्छ कि भन्नेमा होइन।

गेटवेले पूर्वनिर्धारित बोक्न सक्छ कि जाँच्नुहोस्

पूर्ण टनेलिङले हरेक प्याकेट एउटै यन्त्रमा सार्छ, जसले त्यस यन्त्रको CPU भार, conntrack तालिका, ठेगाना अनुवाद र अपस्ट्रिम ब्यान्डविथ आवश्यकता एकैसाथ बदल्छ। केही आन्तरिक सबनेटलाई सहजै सेवा दिने गेटवे एउटा प्रयोगकर्ताको सम्पूर्ण ब्राउजिङका लागि आकार दिइएको नहुन सक्छ। औसतभन्दा तपाईंले अपेक्षा गर्ने सबैभन्दा ठूलो एकसाथ सत्र सङ्ख्यालाई हेर्नुहोस्, किनकि शिखरले पहिले बिग्रन्छ।

ip -s link show dev tun0
conntrack -C
ss -s

विनिर्देशबाट तर्क गर्नुको सट्टा परिवर्तनअघि र पछि उही कार्यभार नाप्नुहोस्। एउटै मेसिनमा सामान्य प्रयोगको एउटा दिउँसोले गेटवे सीमाको नजिक छ कि छैन देखाउँछ, र सोमबार बिहान पत्ता लगाउनुको तुलनामा यसको कुनै लागत छैन।

साथै path 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

पुनः जडानपछि र अवरोधपछि जाँच दोहोर्याउनुहोस्, किनकि ड्रपको बेला ट्राफिक रोक्ने kill switch पछि मार्ग सही रूपमा पुनर्स्थापित हुने गुणभन्दा फरक कुरा हो। सरल डिजाइन त्यो हो जसको वास्तविक कभरेज एप वा नेटवर्क बदलिएपछि पनि तपाईं व्याख्या गर्न सक्नुहुन्छ।