OpenVPN TUN বনাম TAP: যে তিনটি শর্ত সিদ্ধান্ত দেয়

দুটি টানেল একই ফাইল স্থানান্তর বহন করতে পারে, কিন্তু তারে যা রাখে তাতে সম্পূর্ণ আলাদা। একটি দুই ঠিকানার মধ্যে IP প্যাকেট সরায়; অন্যটি Ethernet ফ্রেম সরায় এবং একটি সেগমেন্টে ব্রিজ করা যায়। এই পার্থক্যই ঠিক করে কোন অ্যাপ্লিকেশন কাজ করে, কোন ক্লায়েন্ট সংযোগ করতে পারে এবং কতটা নেটওয়ার্ক ডিজাইন আপনি কাঁধে নিচ্ছেন।

বাস্তবে তিনটি শর্তই এটি ঠিক করে। ক্রম অনুযায়ী এগুলো দেখুন, কারণ প্রথমটি সাধারণত আলোচনা শেষ করে দেয়।

প্রতিটি ইন্টারফেস আসলে কী বহন করে

TUN ডিভাইস একটি স্তর 3 পয়েন্ট-টু-পয়েন্ট ইন্টারফেস: কার্নেল তাকে IP প্যাকেট দেয় এবং টানেল সেগুলো সহকর্মী ঠিকানায় বহন করে। TAP ডিভাইস একটি স্তর 2 ইন্টারফেস যা Ethernet ফ্রেম বহন করে, আর এটাই ব্রিজিংকে আদৌ সম্ভব করে, যেমনটি কার্নেল ডকুমেন্টেশন বর্ণনা করে। কোনোটিই পেলোড কীভাবে এনক্রিপ্ট হয় তা বদলায় না, আর কোনোটিই শক্তি সেটিং নয়। নির্বাচনটি প্রান্তগুলোকে কী বিনিময় করতে হবে তা নিয়ে, ট্রাফিক কত ভালোভাবে সুরক্ষিত তা নিয়ে নয়।

একটি পরিণতি সঙ্গে সঙ্গে আসে: দুই প্রান্তকে একমত হতে হবে। এক ধরনের ডিভাইসের জন্য কনফিগার করা ক্লায়েন্ট অন্য ধরনের জন্য কনফিগার করা সার্ভারে যোগ দিতে পারে না, আর যা-ই অন্যথায় মিলুক।

শর্ত এক: কোনো কিছু কি স্তর দুই দরকার করে?

ব্রিজিং তার জটিলতা অর্জন করে যখন কোনো প্রোটোকলের সত্যিই একই ব্রডকাস্ট ডোমেইন দরকার: নন-IP ট্রাফিক, এমন ডিসকভারি যা রাউটার পেরোতে পারে না, বা এমন অ্যাপ্লিকেশন যা এক সেগমেন্টে থাকার জোর দেয়। বাকি সব রাউটিং সমস্যা, আর রাউটিং অনেক কম যন্ত্রপাতিতে তা সমাধান করে। একটি সেগমেন্ট বিস্তীর্ণ এলাকায় বিস্তৃত করলে তার ব্রডকাস্টও বিস্তৃত হয়, তাই লুপ প্রতিরোধ, ঠিকানা পরিকল্পনা ও ব্যর্থতা-ডোমেইন ডিজাইনের অংশ হয়ে যায়। একটি রুটই যা মেটাত, এমন চাহিদার জন্য এটি অনেক কিছু মেনে নেওয়া।

পরীক্ষাটি সুনির্দিষ্ট: যে অ্যাপ্লিকেশন রাউটেড টানেলে ব্যর্থ হয় তার নাম বলুন এবং কেন বলুন। উত্তর যদি হয় যে তার ব্রডকাস্ট দরকার, তাহলে স্তর দুই-ই সৎ উত্তর। উত্তর যদি হয় যে কেউ একটি সার্ভারে পৌঁছাতে পারেনি, তাহলে চাহিদাটি একটি রুট বা ফায়ারওয়াল নিয়ম।

শর্ত দুই: ক্লায়েন্টরা কি এটি করতে পারে?

সমর্থন একরকম নয়। ডেস্কটপ ক্লায়েন্ট সাধারণত দুই ধরনের ডিভাইসই দেয়, অথচ মোবাইল ও এমবেডেড ক্লায়েন্ট প্রায়ই কেবল রাউটেড মোড প্রয়োগ করে, এবং নির্দ্বিধায় ইমপোর্ট হওয়া প্রোফাইলও ইন্টারফেস তৈরি করতে গিয়ে ব্যর্থ হতে পারে। প্ল্যাটফর্মের নাম থেকে বৈশিষ্ট্য অনুমান না করে নির্দিষ্ট ক্লায়েন্ট ও সংস্করণ দেখুন।

অসমর্থিত অপশনের ত্রুটি ইমপোর্ট সফল হওয়া পর্যন্ত অপরিচিত লাইন মুছে ফেলার আমন্ত্রণ নয়। এর অর্থ প্রোফাইল ও ক্লায়েন্ট কী সম্ভব তা নিয়ে একমত নয়, এবং মেরামত সেই অপারেটরের কাজ যিনি প্রোফাইলটি দিয়েছেন। ভ্যালিডেটর চুপ করাতে একটি অপশন সরালে এমন সংযোগ তৈরি হতে পারে যা কাজ করছে বলে মনে হয়, অথচ যে বৈশিষ্ট্যের জন্য এটি ছিল তা নীরবে বাদ দেয়।

শর্ত তিন: এটি কি সত্যিই ইন্টারফেসের প্রশ্ন?

ইন্টারফেস সমস্যার দোষ দুটি পাশাপাশি সিদ্ধান্তের উপর পড়ে। ভার্চুয়াল ডিভাইস ঠিক করে টানেলে কী ঢোকে, আর UDP নাকি TCP ঠিক করে বাইরের ট্রান্সপোর্ট কেমন আচরণ করে, আর কোনোটিই আটকে যাওয়া স্থানান্তর সারায় না। বড় স্থানান্তর আটকে থাকলে আর ছোটগুলো সফল হলে, বরং প্যাকেট আকার ও MTU-ই মনোযোগ পাওয়ার যোগ্য।

যে ক্লায়েন্ট সংযোগ করে তারপর একটি অভ্যন্তরীণ হোস্টে পৌঁছাতে পারে না, সে সাধারণত রাউটিং, ফায়ারওয়াল নিয়ম বা অনুপস্থিত ফেরত পথের দিকে তাকায়।

ম্যানেজড সার্ভিসে অপারেটরের প্রোফাইল যে ইন্টারফেস বিন্যাস নির্দিষ্ট করে তা ব্যবহার করুন, কারণ সার্ভারের দিকটি ইতিমধ্যে তার সাপেক্ষে গড়া। নিজের স্থাপনায় অ্যাপ্লিকেশনের প্রকৃত চাহিদা থেকে বেছে নিন এবং সিদ্ধান্তের পাশে কারণটি লিখুন।

প্রশ্নটি কোন অপশন বেশি শক্তিশালী তা নয়। প্রশ্নটি হলো ট্রাফিকের আসলে কোনটি দরকার।