دو سائٹس، ایک سب نیٹ: ہر ایک کے لیے عرفی منظر بنائیں

دو گاہک سائٹس دونوں 192.168.50.0/24 چلاتی ہیں، اور ایک دور دراز انجینئر کو ہر ایک میں اسی پتے پر موجود پرنٹر تک پہنچنا ہے۔ کوئی بھی روٹنگ ترکیب اس ابہام کو تنہا حل نہیں کرتی۔ ہر سائٹ کو الگ پتہ منظر درکار ہے، اور گیٹ وے کو کچھ بھی آگے بھیجنے سے پہلے اسی منظر سے سائٹ چننی ہوگی۔

منصوبے کے چار حصے ہیں: عرفی سابقے، ترجمے کی دونوں سمتیں، اوورلے پالیسی اور نام۔ ہر حصے کو باقی سے ہم آہنگ ہونا چاہیے۔

ہر سائٹ کے لیے ایک عرفی سابقہ چنیں

ہر سائٹ کو ایک مکمل عرفی سابقہ دیں جو ماحول میں کسی اور کا نہ ہو۔ دو سائٹس کا منصوبہ سائٹ A کے 192.168.50.0/24 کو 172.21.10.0/24 اور سائٹ B کے یکساں LAN کو 172.21.20.0/24 پر نقش کر سکتا ہے۔ امیدواروں کو ہر شریک نیٹ ورک کے خلاف جانچیں، بشمول کلاؤڈ VPC اور دیگر VPN پول۔ نجی پتہ جگہ ہر تنظیم مشترکہ استعمال کرتی ہے، اس لیے کسی رینج کا RFC 1918 ہونا یہ نہیں بتاتا کہ وہ یہاں خالی ہے۔

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

دونوں سمتوں میں ترجمہ کریں

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

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

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

منصوبے کو اوورلے سے گزار یں

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

پورے سب نیٹ کی اشاعت ایک سروس کی اشاعت سے وسیع تر ہے۔ اگر صرف چند مشینیں یا پورٹس درکار ہوں تو رسائی قواعد کو نقشہ بندی سے تنگ رکھیں۔

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

ہر کال کرنے والے کے دیکھے جانے والے نام درست کریں

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

پہلی دیکھ بھال ونڈو سے پہلے ہر سائٹ کے لیے DNS منظر جانچیں۔ جو نام اصل سب نیٹ میں حل ہوتا ہے وہ کال کرنے والے کو اسی ابہام میں واپس بھیجتا ہے جسے منصوبے نے ہٹانا تھا۔

ہر سائٹ کے لیے ریکارڈ کریں اور تصدیق کریں

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

جب تیسری سائٹ اسی ڈیفالٹ LAN کے ساتھ آتی ہے تو یہی فہرست فرق محفوظ رکھتی ہے۔ پالیسی پر مبنی IPsec NAT رہنما ایک ٹھوس ترجمہ ماڈل کی دستاویز کرتا ہے؛ یہ ہر پلیٹ فارم کے لیے معاہدہ نہیں ہے۔