روٹڈ یا برجڈ VPN: اس بنیاد پر چنیں کہ کلائنٹ کو کس چیز تک پہنچنا ہے

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

ٹکٹ ڈیسک پر یکساں دکھنے والی دو درخواستیں

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

یہ مختلف سوالات ہیں، اور دونوں کا جواب پل سے دینا ملازم کی رسائی بلا وجہ پورے دفتر کے LAN تک بڑھا دیتا ہے۔

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

روٹ LAN کی رکنیت سے تنگ ہے

روٹڈ کلائنٹ کو ٹنل ذیلی نیٹ پر پتہ اور آپ کے چنے ہوئے سابقوں کے لیے روٹ ملتے ہیں۔ اگر پالیسی ایسا کہے، تو وہ ایپلیکیشن سرور تک پہنچ سکتا ہے اور کہیں اور نہیں۔ گیٹ وے نفاذ کا مرکز بنتا ہے، بشرطیکہ ہر متعلقہ راستہ اسی سے گزرے۔

روٹ کو اجازت سے نہ ملائیں۔ کلائنٹ کو ذیلی نیٹ تک پہنچنے کا طریقہ بتانا اسے دوسری منزل آزمانے سے نہیں روکتا۔

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

پل داخلے کا سوال بدل دیتا ہے

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

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

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

فلٹرنگ دونوں ٹوپولوجیوں میں موجود ہے

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

حد کا وعدہ کرنے سے پہلے دیکھیں کہ پلیٹ فارم واقعی کس چیز کی تائید کرتا ہے:

bridge link show
nft list ruleset

TUN اور TAP انٹرفیس کی ٹریفک بیان کرتے ہیں، سائفر نہیں۔ انٹرفیس بدلنا ان میں سے کچھ بھی درست نہیں کرتا: ساتھیوں کی توثیق، چوری شدہ کلید اور پرانی کرپٹوگرافک پالیسی سب تبدیلی سے بچ جاتے ہیں۔ دونوں سروں کو اب بھی ایسی سیٹنگز درکار ہیں جو میل کھائیں اور اب بھی معاون ہوں۔

تین کوششوں سے حد ثابت کریں

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

ایک ہی کلائنٹ سے اجازت یافتہ اور مسترد شدہ راستہ چلائیں، اور دونوں درج کریں:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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