होम-ल्याब स्प्लिट टनेल: आवश्यक कुरा मात्र रुट गर्नुहोस्, सबै होइन
पूर्ण टनेल ट्युटोरियलको बानी हो, ल्याबको आवश्यकता होइन। तपाईंलाई साँच्चै चाहिने सबनेट, नाम र व्यवस्थापन मार्गहरू सूचीबद्ध गर्नुहोस्, त्यसपछि ती मात्र रुट गर्नुहोस्।
होम-ल्याबलाई पूर्ण टनेल चाहिन्छ भन्ने सल्लाह सामान्यतया त्यस्तो टनेल भएको ट्युटोरियलबाट आउँछ, आवश्यकताबाट होइन। स्प्लिट टनेलिङ उचित VPN को सम्झौताकारी संस्करण होइन; यो त्यो संस्करण हो जसको रुट तालिका तपाईंले व्याख्या गर्न सक्नुहुन्छ। पाँच सेवा र एउटा व्यवस्थापन इन्टरफेस भएको ल्याबलाई घरबाट निस्कने हरेक प्याकेट टनेलबाट जानु आवश्यक छैन। यसलाई चाहिने भनेको एउटा सूची र त्यो सूचीको हरेक वस्तुका लागि एउटा रुट हो।
भ्रम: स्प्लिट टनेलिङ एउटा सम्झौता हो
भ्रम टिकिरहन्छ किनभने पूर्ण टनेल एक पटक सेट गर्न सजिलो र पछि डिबग गर्न गाह्रो हुन्छ। त्यो साटासाट सार्वजनिक Wi-Fi मा ल्यापटपका लागि उचित र तहखानाको र्याकका लागि गलत हो।
यसले दोस्रो अनुमान पनि लुकाउँछ: ल्याबको ठेगाना तपाईं जोडिने नेटवर्कसँग कुनै कुरा साझा गर्दैन।
रुटभन्दा पहिले स्रोतहरूको सूची बनाउनुहोस्
हरेक ल्याब सबनेट, त्यहाँ बस्ने सेवा, त्यसलाई समाधान गर्ने नाम र त्यहाँ पुग्न कसलाई अनुमति छ लेख्नुहोस्; तपाईंको फर्वार्डिङ नोटहरू गेटवेबारे तपाईंले योजना गरिरहेको फिर्ती मार्ग वर्णन गर्छन्। कन्टेनर दायरा र रिमोट क्लाइन्टले पहिले नै प्रयोग गरिरहेको हुनसक्ने LAN दायरा थप्नुहोस्, किनभने ओभरल्याप त्यो असफलता हो जुन यो सूचीले रोक्छ। हरेक निजी ठेगाना ढाक्ने रुट चाँडो वा ढिलो घरको नेटवर्कसँग ठोकिन्छ। सूची नै परीक्षण योजना पनि हो, त्यसैले यो कन्फिगरेसनपछि होइन, अघि गर्न लायक छ।
हरेक स्रोतलाई एउटा मार्ग दिनुहोस्: टनेलबाट, सिधै, वा अस्वीकृत। मार्ग नदिइएको स्रोत नै पछि अन्योलपूर्ण सहायता प्रश्न उत्पन्न गर्ने हो।
पाँच पङ्क्ति र निर्णयको एउटा स्तम्भ कसैले पढ्न नसक्ने रुट तालिकाभन्दा राम्रो हुन्छ।
गेटवेलाई फिर्ती मार्ग चाहिन्छ
गेटवेमा फर्वार्डिङ आधा मात्र हो। ल्याबलाई क्लाइन्ट पूलतिर फर्कने रुट चाहिन्छ, वा फिर्ती सम्भव बनाउने समर्थित अनुवाद व्यवस्था चाहिन्छ। जवाफहरूले क्लाइन्ट भेट्न नसके टनेल जोडिएको देखिन्छ र हरेक अनुरोध समय सकिएर अन्त्य हुन्छ; यो रुटिङको लक्षण हो, VPN को असफलता होइन। फिर्ती मार्गलाई समस्या समाधानको चरण होइन, डिजाइनको भागका रूपमा जाँच्नुहोस्।
ल्याबको आफ्नै ठेगानासँग ओभरल्याप हुने क्लाइन्ट पूल यो समस्याको अर्को आधा हो, र यो ठ्याक्कै त्यही तरिकाले असफल हुन्छ।
दुई दायरा ठोकिएपछि लक्षण होइन, योजना सुधार्नुहोस्।
व्यवस्थापन र इन्टरनेटका भूमिका छुट्टाछुट्टै हुन्
टनेल ल्याबको ट्राफिकले मात्र प्रयोग गर्छ कि यो इन्टरनेट निकास पनि बन्छ निर्णय गर्नुहोस्। ट्युटोरियलले प्रयोग गर्यो भन्दैमा डिफल्ट रुट नथप्नुहोस्, किनभने त्यो निर्णयले हरेक DNS प्रश्न र हरेक अपडेट जाँच कहाँ जान्छ भन्ने बदल्छ। VPN एन्डपोइन्टसम्म बाहिरी मार्ग कायम राख्नुहोस्, नत्र टनेलले आफ्नै बाहिरी जडान बोक्न खोज्नेछ। व्यवस्थापन पहुँच साँघुरो र स्वीकृत पुनःप्राप्ति विधिबाट पुग्न सकिने राख्नुहोस्।
हरेक सार्वजनिक प्रश्नलाई उही रिजोल्भर चाहिन्छ भन्ने नमानी ल्याब नामका लागि निजी DNS छान्न सकिन्छ। त्यो रिजोल्भरको निर्णय हो, रुटको निर्णय होइन।
तिनलाई छुट्टै राख्नु नै पछि असफलताका प्रकारहरू छुट्याउन सकिने बनाउँछ।
LAN बाट होइन, बाहिरबाट परीक्षण गर्नुहोस्
उही LAN बाट परीक्षणको सट्टा बाहिरी अधिकृत जडान प्रयोग गर्नुहोस्, किनभने उही LAN बाट गरिएको परीक्षणले छुटेको फिर्ती रुट पूर्ण रूपमा लुकाउन सक्छ। ल्याब ठेगाना, त्यसको निजी होस्टनाम, इच्छित सिधा गन्तव्य र आवश्यक असफलता व्यवहार जाँच्नुहोस्। सफलताजत्तिकै असफलताको अवस्था पनि महत्त्वपूर्ण छ: पुग्नु नहुने स्रोतमा साँच्चै पुग्न नसकिनु पर्छ। डिजाइन सकियो भन्नुअघि चारै नतिजा रेकर्ड गर्नुहोस्।
त्यसपछि रुट र DNS कन्फिगरेसन सूचीको छेउमा सुरक्षित गर्नुहोस्, मालिकको नामसहित। ल्याबले अर्को सबनेट पाए दुवै अपडेट गर्नुहोस् र फेरि परीक्षण गर्नुहोस्।
अवस्थित घरको नेटवर्कसँग ओभरल्याप हुने अव्याख्यायित रुट त्यो चरण छोड्ने डिफल्ट नतिजा हो।
तयार डिजाइन सानो, अभिलेखित र नरमाइलो हुन्छ, र ल्याबले आफ्नो नेटवर्कबाट ठ्याक्कै त्यही चाहन्छ। रोचक संस्करण त्यो हो जुन तपाईं घरबाट टाढा हुँदा बिग्रन्छ।