دو دفتر دونوں 192.168.77.0/24 استعمال کرتے ہیں، اور کوئی تجویز دیتا ہے کہ ایک سرنگ بنائی جائے تاکہ وہ ایک نیٹ ورک ہوں۔ یہ جملہ سادہ لگتا ہے اور تین مختلف ڈیزائن چھپاتا ہے: ٹکرانے والے دو آزاد LAN، WAN پر جان بوجھ کر کھینچا گیا ایک ایتھرنیٹ حصہ، اور دور دراز پتوں کی طرف سے جواب دینے والا proxy-ARP انتظام۔ آپ کے پاس ان میں سے کون سا ہے یہ طے کرتا ہے کہ ہوسٹ پیکٹ کے ساتھ کیا کرتا ہے، اور جواب VPN گیٹ وے شامل ہونے سے پہلے ہی نظر آتا ہے۔

ہوسٹ راؤٹر سے پہلے فیصلہ کرتا ہے

192.168.77.10/24 پتہ والا ہوسٹ منزل کا موازنہ اپنے سابقہ سے کرتا ہے۔ اس سابقہ کے اندر سب کچھ سیدھے لنک پر ہے، اس لیے ہوسٹ منزل کا لنک سطحی پتہ سیدھا حل کرتا ہے۔ باہر کا سب کچھ ڈیفالٹ گیٹ وے کی طرف جاتا ہے۔

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

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

ARP مقامی لنک کا سوال ہے

ARP پوچھتا ہے کہ اس لنک پر پتہ کس کا ہے، اور جواب کسی ایسی چیز سے آنا چاہیے جو نشریات سن سکے۔ IPsec سرنگ کے دوسرے سرے پر راؤٹر اسے نہیں سنتا، جب تک ڈیزائن دونوں سائٹوں کو ایک نشریاتی ڈومین نہ بنا دے۔

ایک ہی پتہ والے دو آلات صورتحال کو مزید خراب کرتے ہیں: کامیاب حل بھی نہیں بتا سکتا کہ کس نے جواب دیا۔

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

کھینچا ہوا حصہ فریم لے جاتا ہے، راستے نہیں

پلوں سے جڑی ایتھرنیٹ لے جانے والی سرنگ دونوں سائٹوں کو ایک لنک سطحی ڈومین کا حصہ بناتی ہے۔ ARP نشریات دوسری طرف پہنچتی ہیں، اور ہر پل سیکھتا ہے کہ کون سے MAC پتے کہاں ہیں۔ Linux پل کی دستاویز اس MAC پر مبنی ارسال کی حد بیان کرتی ہے۔

یہاں دور کا گیٹ وے دو یکساں سب نیٹ کے درمیان بالکل راؤٹنگ نہیں کرتا۔ فریم ایسی نچلی تہہ سے گزرتے ہیں جو خود IP راؤٹ کرتی ہے، جبکہ پل ایتھرنیٹ گفتگو کو بڑھاتے ہیں۔

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

Proxy ARP تیسرا ڈیزائن ہے

راؤٹر دور دراز پتہ کے لیے ARP کا جواب دے کر پھر ادھر راؤٹ کر سکتا ہے۔ یہ نشریاتی ڈومین کھینچے بغیر بھیجنے والے کو دور کا ہوسٹ سیدھے لنک پر دکھاتا ہے۔

یہ پل بنانے سے تنگ آلہ ہے: یہ ارسال، واپسی راستوں اور ہر پتہ کے واضح مالک پر منحصر ہے۔

یہ من مانی غیر IP پروٹوکولز کو راؤٹ کے قابل بھی نہیں بناتا، اور ایتھرنیٹ نشریاتی ڈومین دوبارہ پیدا نہیں کرتا۔ جب ضرورت بالکل وہی متبادل ہو تب استعمال کریں، ملتوی دوبارہ شمار کے شارٹ کٹ کے طور پر نہیں۔

ضرورت سے منتخب کریں، پھر تصدیق کریں

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

یقینی بنائیں کہ اصل میں کون سا ڈیزائن آپ کے پاس ہے ہوسٹ سے پوچھ کر کہ وہ منزل کے ساتھ کیا کرتا ہے:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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

متعلقہ مضامین