OpenVPN TUN विरुद्ध TAP: ठरवणाऱ्या तीन अटी

दोन टनेल एकाच फाइल ट्रान्सफरचे वहन करू शकतात आणि तरीही वायरवर ठेवण्याच्या गोष्टीत पूर्णपणे वेगळे असू शकतात। एक दोन पत्त्यांमध्ये IP पॅकेट्स हलवतो; दुसरा Ethernet फ्रेम्स हलवतो आणि त्याला सेगमेंटमध्ये ब्रिज करता येते। हा फरकच ठरवतो की कोणती ॲप्लिकेशन्स चालतील, कोणते क्लायंट जोडू शकतील आणि तुम्ही किती नेटवर्क डिझाइन स्वीकाराल।

प्रत्यक्षात तीन अटी हे ठरवतात। त्या क्रमाने पाहा, कारण पहिली अट सहसा चर्चा संपवते।

प्रत्येक इंटरफेस प्रत्यक्षात काय नेतो

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

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

पहिली अट: कशाला लेयर दोन हवा आहे का?

ब्रिजिंग आपली गुंतागुंत तेव्हा सार्थ करते जेव्हा प्रोटोकॉलला खरोखर एकच ब्रॉडकास्ट डोमेन हवा असतो: बिगर-IP ट्रॅफिक, राउटर ओलांडू न शकणारा शोध, किंवा एकाच सेगमेंटवर राहण्याचा आग्रह धरणारे ॲप्लिकेशन। बाकी सर्व राउटिंगची समस्या आहे आणि राउटिंग ती खूप कमी यंत्रणेने सोडवते। सेगमेंट मोठ्या भागात पसरवल्यास त्याचे ब्रॉडकास्टही पसरतात, त्यामुळे लूप प्रतिबंध, पत्ता नियोजन आणि अयशस्वी डोमेन सर्व डिझाइनचा भाग होतात। एकाच मार्गाने पूर्ण होणाऱ्या गरजेसाठी हे खूप जास्त आहे।

चाचणी ठोस आहे: राउटेड टनेलवर अपयशी ठरणारे ॲप्लिकेशन सांगा आणि का ते सांगा। उत्तर हे असेल की त्याला ब्रॉडकास्ट हवा आहे, तर लेयर दोन हे प्रामाणिक उत्तर आहे। उत्तर हे असेल की कोणाला एका सर्व्हरपर्यंत पोहोचता आले नाही, तर गरज मार्ग किंवा फायरवॉल नियम आहे।

दुसरी अट: क्लायंट हे करू शकतात का?

सपोर्ट एकसारखा नाही। डेस्कटॉप क्लायंट सहसा दोन्ही उपकरण प्रकार देतात, तर मोबाइल आणि एम्बेडेड क्लायंट बहुतेक वेळा फक्त राउटेड मोड लागू करतात, आणि तक्रारीशिवाय आयात होणारे प्रोफाइलही इंटरफेस तयार करण्याचा प्रयत्न करताना अपयशी ठरू शकते। प्लॅटफॉर्मच्या नावावरून वैशिष्ट्ये गृहीत धरण्याऐवजी विशिष्ट क्लायंट आणि आवृत्ती तपासा।

असमर्थित पर्यायाची त्रुटी म्हणजे आयात यशस्वी होईपर्यंत अनोळखी ओळी पुसण्याचे निमंत्रण नाही। याचा अर्थ प्रोफाइल आणि क्लायंट काय शक्य आहे यावर सहमत नाहीत आणि दुरुस्ती प्रोफाइल जारी करणाऱ्या ऑपरेटरची जबाबदारी आहे। व्हॅलिडेटरला शांत करण्यासाठी पर्याय काढून टाकल्यास, ज्या गुणधर्मासाठी तो होता तो गुपचूप वगळून कार्यरत दिसणारे कनेक्शन तयार होऊ शकते।

तिसरी अट: हा खरोखर इंटरफेसचा प्रश्न आहे का?

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

जोडल्यानंतर एका अंतर्गत होस्टपर्यंत पोहोचू न शकणारा क्लायंट सहसा राउटिंग, फायरवॉल नियम किंवा गहाळ परतीचा मार्ग पाहत असतो।

व्यवस्थापित सेवेसाठी ऑपरेटरचे प्रोफाइल सांगते तेच इंटरफेस संरचना वापरा, कारण सर्व्हर बाजू आधीच त्याभोवती बांधलेली आहे। खाजगी तैनातीसाठी ॲप्लिकेशनच्या खऱ्या गरजेतून निवडा आणि निवडीजवळ कारण लिहा।

प्रश्न कोणता पर्याय अधिक मजबूत आहे हा नाही। प्रश्न हा आहे की ट्रॅफिकला खरोखर कोणता हवा आहे।