OpenVPN کے ذریعے دو بورڈز کے درمیان الگ تھلگ TAP پل

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

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

پل دراصل کیا منتقل کرتا ہے

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

دونوں کمپیوٹرز پر یکساں نام مقامی نام ہیں، مشترک اشیاء نہیں۔ بینچوں کے درمیان ایک Ethernet راستہ ہے، دوسری کیبل اور لوپ بند کرنے والی دوسری سرنگ کے بغیر، ایک ہی MAC کو دو پورٹس پر آتا دیکھنے والا پل خوشی سے دائروں میں منتقل کرے گا۔

پل کو پتہ دیں، اس کے ممبر پورٹس کو نہیں

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

ہر بینچ کے لیے ایک مخصوص پورٹ کیوں

مخصوص تار والا پورٹ ہی تجربے کو دفتر بھر کی تبدیلی بننے سے روکتا ہے۔ انتظامی انٹرفیس SSH، ڈیفالٹ راستہ اور بیرونی VPN کنکشن لے جاتا ہے، اور ان میں سے کچھ بھی ایسے پل پر نہیں ہونا چاہیے جس کا مقصد لیب فریم منتقل کرنا ہے۔

انتظامی ایڈاپٹر جوڑنے سے دفتر کا LAN ڈیولپمنٹ بورڈ سے ایک فارورڈنگ فیصلے کی دوری پر آ جاتا ہے، اور لیئر دو پر بدسلوکی کرنے والا بورڈ اسی قسم کا آلہ ہے جو آپ اس حصے میں نہیں چاہتے۔ Wi-Fi ایڈاپٹر اس سے بھی بدتر ہے: انفراسٹرکچر موڈ میں وائرلیس انٹرفیس کو پل کرنا Ethernet کو پل کرنے کی طرح برتاؤ نہیں کرتا، اور ناکامی صاف نہیں بلکہ الجھانے والی ہوتی ہے۔

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

وہ حد جو پل نہیں بناتا

پل کرنا روٹنگ نہیں ہے، اور یہ الگ تھلگ کرنا بھی نہیں۔ پل عبور کرنے والے فریم اب بھی ہوسٹ کے فلٹرنگ ہکس تک پہنچ سکتے ہیں، نصب شدہ bridge-netfilter راستے کے مطابق، اس لیے مؤثر پالیسی کو فرض کرنے کے بجائے جانچنا چاہیے۔ ایک فریم گم ہونے پر فائر وال بند کرنا ایک مخصوص خرابی کو عام خرابی سے بدل دیتا ہے۔

پل اور ہر انتظامی یا اپ لنک انٹرفیس کے درمیان IP فارورڈنگ بند رہنی چاہیے یا واضح طور پر مسترد ہونی چاہیے، اور یہ پل کی رکنیت سے الگ کنٹرول ہے۔ کمپیوٹر کے لیب پتے کو اپنا گیٹ وے چننے والا بورڈ بالکل یہی آزماتا ہے: اگر انتظامی گزر کامیاب ہو، تو جس حد کا آپ نے ارادہ کیا وہ کبھی تھی ہی نہیں۔

مزید دو خاندان واضح فیصلے کے حقدار ہیں۔ پتہ منصوبہ پل کو صرف IPv4 نہیں بناتا، اس لیے IPv6 اور دیگر EtherType کو اپنا منصوبہ یا فلٹر درکار ہے۔ اور کامیاب ping اس بارے میں کچھ نہیں کہتا کہ بورڈ کے دریافت نشر، ملٹی کاسٹ گروپس یا جمبو فریم راستہ عبور کریں گے یا نہیں، کیونکہ وہ مختلف ڈیفالٹ کے ساتھ مختلف ٹریفک طبقے ہیں۔

آخر میں، نقل و حمل اور رازداری دو الگ خریداریاں ہیں۔ TAP Ethernet لے جاتا ہے؛ OpenVPN سروس اس کے گرد تحفظ دیتی ہے۔ VXLAN تہہ بھی Ethernet لے جاتی ہے اور خود کسی رازداری کی ضمانت نہیں دیتی، اس لیے ایک کو دوسرے سے بدلنا ٹوپولوجی خاکہ یکساں دکھنے پر بھی حفاظتی خصوصیات بدل دیتا ہے۔

استحکام اور اسے ثابت کرنے والے ٹیسٹ

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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