ایک TAP سرور یا کئی؟ پل پر OpenVPN کلائنٹس

کئی TAP کلائنٹس کو ہر ایک کے لیے ایک سرور پروسیس، ایک UDP پورٹ اور میزبان پر ایک TAP ڈیوائس کی ضرورت نہیں ہوتی۔ Ethernet موڈ میں ایک OpenVPN سرور بہت سے تصدیق شدہ کلائنٹس قبول کر سکتا ہے اور انہیں ایک ہی پل سے جوڑ سکتا ہے، اور سطح 2 کے کسی حصے کو بڑھانے کا یہی دستاویزی طریقہ ہے۔ ایک پروسیس کا ڈیزائن وہی ہے جو دستی میں درج ہے، اور عام طور پر یہی درست طے شدہ ہے۔

اصل سوال یہ ہے کہ کیا ان کلائنٹس کو وہ حصہ مشترک کرنا چاہیے۔ پروسیس کی تعداد اس کا جواب نہیں دیتی، کیونکہ تنہائی کی خصوصیات ٹوپولوجی سے آتی ہیں، اس سے نہیں کہ کتنے ڈیمون چل رہے ہیں۔ اس موازنے کا باقی حصہ دو ٹوپولوجیوں اور یہ کہ ہر ایک کیا آسان بناتی ہے، کے بارے میں ہے۔

دو معماریاں، دو ترتیبات نہیں

راوٹڈ TUN تعیناتی ہر کلائنٹ کو سرور کے راوٹنگ ڈومین میں پوائنٹ ٹو پوائنٹ لنک دیتی ہے۔ براڈکاسٹ سرور پر رک جاتے ہیں، کلائنٹس ایک دوسرے کے فریم نہیں دیکھ سکتے، اور کلائنٹس کے درمیان ٹریفک ہو تو اسے واضح طور پر راوٹ اور فلٹر کرنا پڑتا ہے۔

پل والی TAP تعیناتی کلائنٹس کو ایک ہی Ethernet حصے کے ارکان بنا دیتی ہے۔ وہ براڈکاسٹ دیکھتے ہیں، ARP سے ایک دوسرے کو ڈھونڈ سکتے ہیں، اور الگ رہنے کے لیے راوٹنگ کے بجائے پل اور فائر وال کی پالیسی پر انحصار کرتے ہیں۔ یہ تب مفید ہے جب کلائنٹس ایسے دکھائی دینے چاہئیں جیسے وہ اسی سوئچ میں لگے ہوں۔

لہٰذا موازنہ اس بارے میں ہے کہ کلائنٹس کو کہاں پہنچنا ہے، کارکردگی کے بارے میں نہیں۔ پہلے سطح منتخب کریں، پھر طے کریں کہ کتنی پروسیس اس کی خدمت کریں گی۔

server-bridge مددگار کیا کرتا ہے

server-bridge مددگار کثیر کلائنٹ Ethernet موڈ ترتیب دیتا ہے۔ اس کی پتہ تالاب کی شکل گیٹ وے، نیٹ ماسک اور پل والے ذیلی نیٹ کے اندر مخصوص رینج لیتی ہے، مثلاً 192.168.50.1 پر گیٹ وے اور 192.168.50.160 سے 192.168.50.199 تک تالاب۔

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

ایسی تعیناتیوں کے لیے DHCP پراکسی شکل موجود ہے جہاں بیرونی سرور پتے دیتا ہے۔ اس کی اپنی پیشگی شرائط ہیں، اور دونوں شکلوں کو ملانے سے بالکل وہی تصادم پیدا ہوتا ہے جس سے دستاویزات خبردار کرتی ہیں۔ پل والے ذیلی نیٹ کے لیے ایک ہی تقسیم کنندہ منتخب کریں۔

تنہائی پروسیس کی تعداد سے نہیں آتی

اسی غیر محدود پل سے جڑی آٹھ OpenVPN پروسیس اب بھی ایک ہی براڈکاسٹ ڈومین مشترک کرتی ہیں۔ کلائنٹس پل کے پار ایک دوسرے کے لیے ARP بھیج سکتے ہیں، اور سامعین کی تعداد نے اس میں کچھ نہیں بدلا۔

اگر ضرورت یہ ہے کہ کلائنٹ گروہ سطح 2 پر ایک دوسرے کو نہ دیکھیں، تو ڈیزائن کو الگ پل یا VLAN جوڑ اور ان کے ساتھ آنے والے رسائی قواعد درکار ہیں۔ یہ نیٹ ورک ڈیزائن کا فیصلہ ہے، اور ایک سرور پروسیس ہو یا آٹھ، فیصلہ وہی ہے۔ پل کی فلٹرنگ کچھ ٹریفک محدود کر سکتی ہے، مگر الگ براڈکاسٹ ڈومین نہیں بناتی۔ اسے تقسیم کا ضمیمہ سمجھیں، اس کا متبادل نہیں۔

اگر ضرورت صرف یہ ہے کہ کلائنٹس کچھ IP خدمات تک پہنچیں، تو راوٹڈ TUN ڈیزائن عام طور پر پل بنانے اور فلٹرنگ سے سادہ ہے۔ ہر کلائنٹ کو اپنا لنک ملتا ہے، اور پالیسی پل کے اندر نہیں بلکہ راوٹنگ اور فائر وال قواعد میں رہتی ہے۔

کب کئی پروسیس پھر بھی درست ہیں

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

اگر کئی استعمال کریں تو ہر ایک کو اپنا سامع اور ڈیوائس کی ملکیت دیں اور پتہ رینجز میں ہم آہنگی کریں۔ جو دونوں سرور یہ سمجھتے ہیں کہ اسی پل پر وہی تالاب ان کا ہے، وہ آخرکار وہی پتہ دیں گے۔

پھر ایک ہی وقت میں کئی کلائنٹس کے ساتھ ڈیزائن کی تصدیق کریں۔ دیکھیں کہ پتے منفرد ہیں، کلائنٹس کے درمیان مطلوبہ ٹریفک کام کرتا ہے، اور جس جوڑی کو رابطہ نہیں کرنا چاہیے وہ نہیں کر سکتی۔ ایک کلائنٹ کا کامیاب ping کئی کلائنٹ والے ڈیزائن میں کچھ بھی نہیں جانچتا۔

نقشے پر بھروسہ کرنے سے پہلے چلتے ہوئے میزبان سے پل اور سرور موڈ پڑھیں۔ اہم کنفیگریشن وہی ہے جو کرنل اور ڈیمون نے واقعی لوڈ کی، اور جائزہ لینے والا بھی وہی جانچ سکتا ہے۔