OpenVPN TUN र TAP: निर्णय गर्ने तीन सर्तहरू

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

व्यवहारमा तीन सर्तले यो निर्णय गर्छन्। तिनीहरूलाई क्रममा हेर्नुहोस्, किनकि पहिलो सर्तले सामान्यतया बहस अन्त्य गर्छ।

प्रत्येक इन्टरफेसले वास्तवमा के बोक्छ

TUN यन्त्र लेयर-3 बिन्दु-देखि-बिन्दु इन्टरफेस हो: कर्नेलले यसलाई IP प्याकेट दिन्छ र टनेलले तिनलाई साथी ठेगानासम्म पुर्याउँछ। TAP यन्त्र Ethernet फ्रेम बोक्ने लेयर-2 इन्टरफेस हो, र ब्रिजिङलाई सर्वथा सम्भव बनाउने कुरा यही हो, जसरी कर्नेल कागजात वर्णन गर्छ। दुवैले पेलोड कसरी इन्क्रिप्ट हुन्छ भन्ने बदल्दैनन् र दुवैमध्ये कुनै पनि बलको सेटिङ होइन। छनोट दुवै छेउले के साटासाट गर्नुपर्छ भन्नेबारे हो, ट्राफिक कति राम्ररी सुरक्षित छ भन्नेबारे होइन।

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

पहिलो सर्त: केहीलाई लेयर दुई चाहिन्छ?

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

परीक्षण ठोस छ: राउट गरिएको टनेलमा असफल हुने अनुप्रयोगको नाम भन्नुहोस् र किन भन्नुहोस्। जवाफ यो हो कि त्यसलाई प्रसारण चाहिन्छ भने, लेयर दुई इमानदार जवाफ हो। जवाफ यो हो कि कसैले एउटा सर्भरसम्म पुग्न सकेन भने, आवश्यकता मार्ग वा फायरवाल नियम हो।

दोस्रो सर्त: के क्लाइन्टहरू यो गर्न सक्छन्?

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

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

तेस्रो सर्त: के यो साँच्चै इन्टरफेसको प्रश्न हो?

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

जोडिएपछि एउटा आन्तरिक होस्टसम्म पुग्न नसक्ने क्लाइन्टले सामान्यतया राउटिङ, फायरवाल नियम वा हराएको फर्किने मार्ग हेरिरहेको हुन्छ।

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

प्रश्न कुन विकल्प बलियो छ भन्ने होइन। प्रश्न ट्राफिकलाई साँच्चै कुन चाहिन्छ भन्ने हो।