جواب LAN سے نکلتا ہے، ٹنل سے نہیں: کیوں اور کیسے
ٹنل سے آنے والی درخواست کا مطلب یہ نہیں کہ جواب بھی اسی راستے سے جائے گا۔ Linux منزل تلاش کرتا ہے، اور عام طور پر مقامی سب نیٹ جیت جاتا ہے۔
گیٹ وے کے ذریعے شائع شدہ سروس انٹرنیٹ کے بیشتر حصوں سے کام کرتی ہے اور ایک دفتر سے ناکام ہو جاتی ہے۔ کوئی ٹنل کی جانچ کرتا ہے، درخواست آتے دیکھتا ہے اور یہ نتیجہ اخذ کرتا ہے کہ جواب کو اسی راستے سے واپس جانا چاہیے۔ Linux ایسے کام نہیں کرتا، اور ٹنل کی کتنی بھی جانچ جواب نہیں بدلے گی۔ جواب منزل کے مطابق روٹ ہوتا ہے، اور وہ ایک ناکام کال کرنے والا ایسے سب نیٹ پر ہے جہاں میزبان پہلے ہی براہ راست پہنچتا ہے۔
باہر جانے والے پیکٹ کا اصل فیصلہ کون کرتا ہے
کرنل پیکٹ کی منزل کے لیے راستہ تلاش کرتا ہے، پالیسی قواعد کو ترجیحی ترتیب میں دیکھتا ہے اور پھر وہ جدول دیکھتا ہے جسے مماثل قاعدہ منتخب کرتا ہے۔ پیکٹ جس انٹرفیس سے آیا اس کا کوئی کردار نہیں، جب تک اسے اہم بنانے کے لیے کوئی قاعدہ یا نشان نہ لکھا گیا ہو۔ یہ اس میزبان کی روٹنگ کی حقیقت ہے، ٹنل کی خرابی نہیں۔
اس لیے ٹنل پر موصول ہونے والی درخواست ایسا جواب دے سکتی ہے جو طبعی انٹرفیس سے باہر جائے، اور کسی بھی آلے کے نقصان کی اطلاع دیے بغیر بہاؤ یک طرفہ ہو جاتا ہے۔ ٹنل کے بارے میں نتیجہ اخذ کرنے سے پہلے دونوں سمتوں کی جانچ کریں۔ غلط سمت میں جانے والا جواب ٹنل کے شمار کنندگان سے غائب ہو جاتا ہے، اسی لیے دونوں سرے اس بات پر متفق نہیں کہ کچھ بھیجا گیا یا نہیں۔ کسی قاعدے کو چھونے سے پہلے دیکھیں کہ کون سا شمار کنندہ بدلا۔
مقامی سب نیٹ کیوں جیتتا ہے
مقامی نیٹ ورک پر پتہ رکھنے والے میزبان کے پاس مرکزی جدول میں اس سابقے کے لیے جڑا ہوا راستہ ہوتا ہے، اور جڑا ہوا راستہ براہ راست مماثلت ہے۔ جب کال کرنے والا اسی سب نیٹ سے آتا ہے تو تلاش ٹنل پر غور کرنے سے پہلے ہی مقامی لنک ڈھونڈ لیتی ہے۔
یہی عدم توازن تشخیص کو مبہم بناتا ہے۔ وسیع تر انٹرنیٹ سے آنے والے کال کرنے والے کام کرتے ہیں کیونکہ وہ کسی مقامی راستے سے مماثل نہیں ہوتے، جبکہ دفتر کا سابقہ بانٹنے والا واحد کال کرنے والا ناکام ہوتا ہے، اور کوئی جانچ کے لیے وہی استعمال کرتا ہے۔
ہم منصب کی کوریج نصب شدہ راستوں جیسی نہیں
ٹنل کی طرف، ہم منصب کی اجازت شدہ حدود بتاتی ہیں کہ ٹنل میں کیا بھیجا جا سکتا ہے اور اس سے کون سے مصادر قبول کیے جاتے ہیں۔ یہ نہیں بتاتیں کہ مقامی روٹنگ جدول پیکٹ کہاں بھیجے گا۔
اگر ٹنل کا اوزار میزبان پر طے شدہ راستہ نصب کرے تو یہ غیر متعلق ٹریفک کو ضمنی نقصان کے طور پر ٹنل میں کھینچ سکتا ہے۔ جہاں اس کے بجائے پالیسی قاعدے کو فیصلہ کرنا چاہیے، وہاں اوزار کا راستہ نصب کرنے کا اختیار اسی کو روکنے کے لیے ہے، اور پتے، چابیاں اور اینڈ پوائنٹ کی ترتیبات بالکل ویسی ہی رہتی ہیں۔ سہولت کے لیے شامل کیا گیا طے شدہ راستہ میزبان کے اپنے مقامی نیٹ ورک کے کھو جانے کا عام طریقہ ہے۔
جدول ماخذ پتے کے مطابق منتخب کریں
ماخذ پر مبنی قاعدہ سروس کے پتے سے آنے والے جوابات کو ایسے نجی جدول میں بھیجتا ہے جس کا طے شدہ ٹنل ہے، جبکہ باقی سب مرکزی جدول ہی استعمال کرتا رہتا ہے۔ ایسے جدول اور ترجیحی نمبر منتخب کریں جو مقامی طور پر استعمال نہ ہوں، اور کچھ بھی داخل کرنے سے پہلے موجودہ قواعد پڑھیں۔ محفوظ شدہ فائل کے بجائے فعال قواعد پڑھیں، کیونکہ ری بوٹ کے بعد دونوں مختلف ہو سکتے ہیں۔
ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachableآخری سطر غیر موجود راستے کو مقامی لنک پر واپس جانے کے بجائے نمایاں طور پر ناکام کرتی ہے۔ ماخذ واقعی میزبان کو تفویض ہونا چاہیے، اور عام مقامی اور مرکزی تلاشیں اپنی سابقہ جگہوں پر ہی رہنی چاہئیں۔ قاعدہ ماخذ کے مطابق جدول منتخب کرتا ہے؛ یہ جدولوں کے درمیان سابقے کی لمبائی کا موازنہ نہیں کرتا۔
پہلے راستہ، پھر سروس کی تصدیق کریں
کیپچر سے اندازہ لگانے کے بجائے کرنل سے پوچھیں کہ وہ کیا کرے گا، سروس کے پتے کو ماخذ منتخب کرنے والا بنا کر۔ یہاں درست جواب پورا پیکٹ ٹریس بچا لیتا ہے۔
ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20آؤٹ پٹ میں ٹنل کا نام ہونا چاہیے۔ پھر ایسے ماخذ کی جانچ کریں جسے آپ نے نہیں چھوا اور تصدیق کریں کہ وہ اب بھی مقامی لنک لیتا ہے، تاکہ تبدیلی ایک ہی پتے تک محدود رہے۔ زیادہ وسیع منتخب کنندہ اصل شکایت کے بارے میں کچھ ثابت نہیں کرتا۔
یہ کیا درست نہیں کرتا
گیٹ وے پر فارورڈنگ، فائر وال قواعد اور ICMPv6 رویہ پہلے جیسا ہی رکھیں، کیونکہ ماخذ راستہ ان میں سے کسی کی جگہ نہیں لیتا۔ غائب Packet Too Big پیغام کسی بھی جدول کی جیت کے باوجود بڑے جوابات کو توڑتا ہے۔ روٹنگ قواعد شامل کرنے سے پہلے اسے ٹھیک کریں، ورنہ تبدیلی کے بعد بھی علامت رہے گی۔
ان میں سے کچھ بھی لاگو کرنے سے پہلے اشاعت کے ماڈل کی تصدیق کریں۔ جو ریورس پراکسی اپنا بیک اینڈ کنکشن کھولتی ہے وہ اپنا ماخذ پیش کرتی ہے اور کال کرنے والے کو محفوظ نہیں رکھتی، اس لیے اس ڈیزائن میں یہ خرابی واقع نہیں ہو سکتی۔ وہاں قاعدہ لاگو کرنے سے ایسی روٹنگ استثنا شامل ہو گی جو کچھ حل نہیں کرتی اور اصل وجہ چھپاتی ہے۔
آخر میں، قواعد کے نمبر اور جدول میزبان کی کنفیگریشن مینجمنٹ میں لکھیں۔ ہاتھ سے شامل کیا گیا پالیسی قاعدہ اگلی تعمیر نو میں غائب ہو جاتا ہے، اور دفتر کا کال کرنے والا اسی شکایت کے ساتھ واپس آتا ہے۔