VPN मार्फत Dante SOCKS: पूर्ण टनेल वा स्रोत-आधारित राउटिङ

तपाईं SOCKS प्रोक्सीको ट्राफिक VPN बाट बाहिर जाओस् र बाँकी होस्टले आफ्नो सामान्य बाटो कायम राखोस् भन्ने चाहनुहुन्छ। दुई डिजाइनले यो गर्छन्, र केही गलत हुँदा के बिग्रन्छ भन्नेमा तिनीहरू फरक छन्। एउटाले टनेलमा पूर्वनिर्धारित रुट धकेल्छ र त्यसपछि त्यसलाई वरिपरि गएर काम गर्छ; अर्कोले मुख्य तालिकालाई छुँदैन र एउटा स्रोत ठेगाना दोस्रो तालिकामा पठाउँछ। दोस्रो बढी सफा छ, र यसका आफ्नै जालहरू छन्।

दुई डिजाइन, दुई फरक क्षति-त्रिज्या

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

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

यो साँघुरोपन नै बाधा पनि हो: प्रोक्सीका बाहिर जाने प्याकेटहरूले साँच्चै त्यो ठेगाना बोकेको खण्डमा मात्र डिजाइन काम गर्छ।

Dante को external सेटिङले के गर्छ

external सेटिङ ले प्रोक्सीले बाहिर जाने जडानका लागि प्रयोग गर्ने ठेगानाहरू छान्छ; यसले कर्नेलको राउटिङ नीतिलाई छुँदैन। यही विभाजनले दोस्रो डिजाइन सम्भव बनाउँछ, र यहीँ मानिसहरूले कागजात गलत पढ्छन्। external लाई टनेलको ठेगानातिर देखाउँदा प्रोक्सीले आफ्ना जडानहरू त्यही ठेगानाबाट उत्पन्न गर्छ, र त्यसपछि राउटिङ तालिकाले ती प्याकेट कहाँ जाने भनेर निर्णय गर्छ।

श्रोता छुट्टै विषय हो। internal लाई प्रोक्सी प्रयोग गर्नुपर्ने क्लाइन्टमा मात्र सीमित राख्नुहोस्, प्रमाणीकरण अनिवार्य गर्नुहोस् र पोर्टलाई फायरवालले बन्द गर्नुहोस्, किनभने खुला श्रोता VPN निकासको विशेषता होइन।

कन्फिगर गरिएको ठेगाना प्रोक्सीको नेटवर्क नामस्थानभित्र साँच्चै टनेलको हो भनी पुष्टि गर्नुहोस्।

स्रोत-चयन तालिका बनाउने

10.90.0.2/24 TUN ठेगाना, 10.90.0.1 मा पुग्न सकिने पियर, र अरू कुनैले प्रयोग नगर्ने तालिका नम्बरका लागि, मिलान यस्तो देखिन्छ:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

पुग्न नसकिने रुट त्यो भाग हो जो मानिसहरूले छोड्छन्। त्यो बिना, टनेल रुट हराएको तालिका सामान्य पूर्वनिर्धारितमा खस्छ र प्रोक्सी चुपचाप WAN बाट बाहिरिन्छ। त्यो सहित, खोजी असफल हुन्छ, जो चुपचाप चुहावटको सट्टा देखिने असफलता हो। नियमको प्राथमिकता पनि त्यो स्रोतसँग मिल्ने अरू सबैभन्दा अघि हुनुपर्छ।

यी मानहरूले एउटा टोपोलोजी वर्णन गर्छन्। पोइन्ट-टु-पोइन्ट पियर, net30 ठेगाना, र फरक प्रिफिक्स दिने क्लाइन्ट सबैलाई आफ्नै रुट चाहिन्छ, त्यसैले ठेगाना होइन, आकार प्रतिलिपि गर्नुहोस्।

स्रोत नियम कहाँ चुहिन्छ

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

DNS अर्को चुहावट हो। रिजोल्भर सकेटले अनिवार्य रूपमा प्रोक्सीको external डाटा-जडान स्रोत प्रयोग गर्दैन, त्यसैले नाम खोजी अझै WAN बाट बाहिर जान सक्छ। जडान स्थापनाबाट छुट्टै रिजोल्युसन परीक्षण गर्नुहोस्, र त्यो नतिजा स्वीकार्य छ कि छैन निर्णय गर्नुहोस्।

IPv6 लाई आफ्नै नियम र रुट चाहिन्छ, किनभने IPv4 को मिलानले यसबारे केही पनि प्रमाणित गर्दैन।

तपाईंले सहन सक्ने असफलता अनुसार छान्नुहोस्

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

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

टनेल खस्ने भए, प्रोक्सी असफल हुनुपर्छ वा पछाडि हट्नुपर्छ भनी अग्रिम निर्णय गर्नुहोस्, र राउटिङ तालिकाले त्यो निर्णय व्यक्त गरोस्।