OpenVPN TUN بمقابلہ TAP: فیصلہ کرنے والی تین شرطیں

دو ٹنل ایک ہی فائل کی منتقلی لے جا سکتے ہیں اور پھر بھی تار پر رکھی جانے والی چیز میں بالکل مختلف ہو سکتے ہیں۔ ایک دو پتوں کے درمیان IP پیکٹ منتقل کرتا ہے؛ دوسرا Ethernet فریم منتقل کرتا ہے اور اسے کسی حصے میں پل کیا جا سکتا ہے۔ یہی فرق طے کرتا ہے کہ کون سی ایپلیکیشنز کام کرتی ہیں، کون سے کلائنٹ جڑ سکتے ہیں اور آپ کتنا نیٹ ورک ڈیزائن اپنے ذمے لیتے ہیں۔

عملی طور پر تین شرطیں اس کا فیصلہ کرتی ہیں۔ انہیں ترتیب سے دیکھیں، کیونکہ پہلی شرط عموماً بحث ختم کر دیتی ہے۔

ہر انٹرفیس اصل میں کیا لے جاتا ہے

TUN ڈیوائس لیئر-3 پوائنٹ ٹو پوائنٹ انٹرفیس ہے: کرنل اسے IP پیکٹ دیتا ہے اور ٹنل انہیں ہم منصب پتے تک لے جاتا ہے۔ TAP ڈیوائس Ethernet فریم لے جانے والا لیئر-2 انٹرفیس ہے، اور پل کرنا اصل میں ممکن بنانے والی چیز یہی ہے، جیسا کہ کرنل دستاویزات بیان کرتی ہیں۔ دونوں میں سے کوئی پے لوڈ کی انکرپشن کا طریقہ نہیں بدلتا اور کوئی طاقت کی ترتیب نہیں ہے۔ چناؤ اس بارے میں ہے کہ سروں کو کیا تبدیل کرنا ہے، اس بارے میں نہیں کہ ٹریفک کتنی اچھی طرح محفوظ ہے۔

ایک نتیجہ فوراً آتا ہے: دونوں سروں کو متفق ہونا چاہیے۔ ایک ڈیوائس قسم کے لیے ترتیب دیا گیا کلائنٹ دوسرے کے لیے ترتیب دیے گئے سرور میں شامل نہیں ہو سکتا، باقی کچھ بھی مل جائے۔

پہلی شرط: کیا کسی چیز کو لیئر دو درکار ہے؟

پل کرنا اپنی پیچیدگی کا حق ادا کرتا ہے جب کسی پروٹوکول کو واقعی ایک ہی براڈکاسٹ ڈومین درکار ہو: غیر IP ٹریفک، ایسی دریافت جو راؤٹر سے گزر نہیں سکتی، یا ایسی ایپلیکیشن جو ایک ہی حصے پر رہنے کی ضد کرتی ہے۔ باقی سب روٹنگ کا مسئلہ ہے، اور روٹنگ اسے بہت کم مشینری سے حل کرتی ہے۔ کسی حصے کو وسیع علاقے تک پھیلانا اس کی براڈکاسٹ کو بھی پھیلاتا ہے، اس لیے لوپ کی روک تھام، پتوں کی منصوبہ بندی اور ناکامی کے ڈومین سب ڈیزائن کا حصہ بن جاتے ہیں۔ ایک ہی روٹ سے پورا ہونے والی ضرورت کے لیے یہ بہت زیادہ ہے۔

امتحان واضح ہے: روٹ کیے گئے ٹنل پر ناکام ہونے والی ایپلیکیشن کا نام لیں اور بتائیں کیوں۔ اگر جواب یہ ہو کہ اسے براڈکاسٹ درکار ہے تو لیئر دو ایماندار جواب ہے۔ اگر جواب یہ ہو کہ کوئی ایک سرور تک نہیں پہنچ سکا تو ضرورت روٹ یا فائر وال قاعدہ ہے۔

دوسری شرط: کیا کلائنٹ کر سکتے ہیں؟

سپورٹ یکساں نہیں۔ ڈیسک ٹاپ کلائنٹ عموماً دونوں ڈیوائس اقسام پیش کرتے ہیں، جبکہ موبائل اور ایمبیڈڈ کلائنٹ اکثر صرف روٹ شدہ موڈ نافذ کرتے ہیں، اور بغیر شکایت درآمد ہونے والا پروفائل بھی انٹرفیس بنانے کی کوشش میں ناکام ہو سکتا ہے۔ پلیٹ فارم کے نام سے خصوصیات کا اندازہ لگانے کے بجائے مخصوص کلائنٹ اور ورژن دیکھیں۔

غیر تعاون یافتہ آپشن کی خرابی درآمد کامیاب ہونے تک ناواقف سطریں مٹانے کی دعوت نہیں ہے۔ اس کا مطلب ہے کہ پروفائل اور کلائنٹ اس بات پر متفق نہیں کہ کیا ممکن ہے، اور مرمت پروفائل جاری کرنے والے آپریٹر کی ذمہ داری ہے۔ ویلیڈیٹر کو خاموش کرنے کے لیے آپشن ہٹانا ایسا کنکشن بنا سکتا ہے جو کام کرتا دکھے مگر جس خصوصیت کے لیے وہ تھا اسے خاموشی سے چھوڑ دے۔

تیسری شرط: کیا یہ واقعی انٹرفیس کا سوال ہے؟

انٹرفیس کے مسائل کا الزام دو قریبی چناؤ پر ڈالا جاتا ہے۔ ورچوئل ڈیوائس طے کرتا ہے کہ ٹنل میں کیا داخل ہوگا، جبکہ UDP یا TCP طے کرتا ہے کہ بیرونی ٹرانسپورٹ کیسا برتاؤ کرے گا، اور دونوں میں سے کوئی رکے ہوئے منتقلی کا علاج نہیں کرتا۔ جب بڑی منتقلیاں لٹکی رہیں اور چھوٹی کامیاب ہوں تو پیکٹ کے سائز اور MTU پر توجہ دینی چاہیے۔

جڑنے کے بعد ایک اندرونی ہوسٹ تک نہ پہنچ سکنے والا کلائنٹ عموماً روٹنگ، فائر وال قاعدہ یا غائب واپسی راستہ دیکھ رہا ہوتا ہے۔

منظم سروس کے لیے آپریٹر کے پروفائل کی بتائی انٹرفیس ترتیب استعمال کریں، کیونکہ سرور کی جانب پہلے ہی اسی کے گرد بنی ہے۔ نجی تعیناتی کے لیے ایپلیکیشن کی اصل ضرورت سے چنیں اور چناؤ کے ساتھ وجہ لکھیں۔

سوال یہ نہیں کہ کون سا آپشن زیادہ مضبوط ہے۔ سوال یہ ہے کہ ٹریفک کو واقعی کون سا درکار ہے۔