OpenVPN TUN बनाम TAP: तीन शर्तें जो फ़ैसला करती हैं

दो टनल एक ही फ़ाइल ट्रांसफ़र ले जा सकते हैं और फिर भी वायर पर जो रखते हैं उसमें पूरी तरह अलग हो सकते हैं। एक दो पतों के बीच IP पैकेट भेजता है; दूसरा Ethernet फ़्रेम भेजता है और उसे किसी सेगमेंट में ब्रिज किया जा सकता है। यही अंतर तय करता है कि कौन-से ऐप्लिकेशन चलेंगे, कौन-से क्लाइंट जुड़ सकेंगे और आप कितना नेटवर्क डिज़ाइन अपने ऊपर लेंगे।

व्यवहार में तीन शर्तें इसे तय करती हैं। इन्हें क्रम से देखें, क्योंकि पहली शर्त अक्सर बहस ख़त्म कर देती है।

हर इंटरफ़ेस वास्तव में क्या ले जाता है

TUN डिवाइस लेयर-3 पॉइंट-टू-पॉइंट इंटरफ़ेस है: कर्नेल उसे IP पैकेट देता है और टनल उन्हें पीयर पते तक ले जाता है। TAP डिवाइस लेयर-2 इंटरफ़ेस है जो Ethernet फ़्रेम ले जाता है, और यही ब्रिजिंग को संभव बनाता है, जैसा कर्नेल दस्तावेज़ बताते हैं। इनमें से कोई भी पेलोड के एन्क्रिप्शन का तरीका नहीं बदलता, और कोई भी ताकत की सेटिंग नहीं है। चुनाव इस बारे में है कि सिरों को क्या बदलना है, इस बारे में नहीं कि ट्रैफ़िक कितनी अच्छी तरह सुरक्षित है।

एक नतीजा तुरंत आता है: दोनों सिरों को सहमत होना चाहिए। एक डिवाइस प्रकार के लिए कॉन्फ़िगर किया गया क्लाइंट दूसरे के लिए कॉन्फ़िगर सर्वर से नहीं जुड़ सकता, बाकी कुछ भी मेल खाए।

शर्त एक: क्या किसी को लेयर दो चाहिए?

ब्रिजिंग अपनी जटिलता तब वसूल करती है जब किसी प्रोटोकॉल को सचमुच एक ही ब्रॉडकास्ट डोमेन चाहिए: ग़ैर-IP ट्रैफ़िक, ऐसी खोज जो राउटर पार नहीं कर सकती, या ऐसा ऐप्लिकेशन जो एक ही सेगमेंट पर रहने की ज़िद करता है। बाकी सब राउटिंग की समस्या है, और राउटिंग उसे बहुत कम मशीनरी से हल कर देती है। किसी सेगमेंट को बड़े क्षेत्र में फैलाने से उसके ब्रॉडकास्ट भी फैलते हैं, इसलिए लूप रोकथाम, पता नियोजन और विफलता डोमेन सब डिज़ाइन का हिस्सा बन जाते हैं। एक ही रूट वाली ज़रूरत के लिए यह बहुत ज़्यादा है।

परीक्षण ठोस है: उस ऐप्लिकेशन का नाम बताएँ जो राउटेड टनल पर विफल होता है और कारण कहें। अगर जवाब यह है कि उसे ब्रॉडकास्ट चाहिए, तो लेयर दो ईमानदार जवाब है। अगर जवाब यह है कि कोई एक सर्वर तक नहीं पहुँच सका, तो ज़रूरत रूट या फ़ायरवॉल नियम है।

शर्त दो: क्या क्लाइंट ऐसा कर सकते हैं?

समर्थन एक-सा नहीं है। डेस्कटॉप क्लाइंट आम तौर पर दोनों डिवाइस प्रकार देते हैं, जबकि मोबाइल और एम्बेडेड क्लाइंट अक्सर सिर्फ़ राउटेड मोड लागू करते हैं, और बिना शिकायत आयात होने वाली प्रोफ़ाइल भी इंटरफ़ेस बनाने की कोशिश में विफल हो सकती है। प्लेटफ़ॉर्म के नाम से सुविधाएँ अनुमान लगाने के बजाय ख़ास क्लाइंट और संस्करण देखें।

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

शर्त तीन: क्या यह सचमुच इंटरफ़ेस का सवाल है?

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

जुड़ने के बाद एक आंतरिक होस्ट तक न पहुँच पाने वाला क्लाइंट आम तौर पर राउटिंग, फ़ायरवॉल नियम या गायब रिटर्न पथ देख रहा होता है।

प्रबंधित सेवा के लिए ऑपरेटर की प्रोफ़ाइल में बताया गया इंटरफ़ेस विन्यास ही इस्तेमाल करें, क्योंकि सर्वर पक्ष पहले से उसी के इर्द-गिर्द बना है। निजी परिनियोजन के लिए ऐप्लिकेशन की असली ज़रूरत से चुनें और चुनाव के साथ कारण लिखें।

सवाल यह नहीं है कि कौन-सा विकल्प ज़्यादा मज़बूत है। सवाल यह है कि ट्रैफ़िक को असल में किसकी ज़रूरत है।