ICMP ری ڈائریکٹ اور آپ کے VPN راستے: اصل میں کیا بدلتا ہے

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

ری ڈائریکٹ راؤٹر کی طرف سے ایک تجویز ہے

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

بھیجنے والا اسے نظر انداز کرنے کے لیے آزاد ہے۔ پروٹوکول میزبان سے اپنی جدول بدلنے کا مطالبہ نہیں کرتا، اور پکڑا گیا ری ڈائریکٹ صرف یہ ثابت کرتا ہے کہ راؤٹر نے ایک بھیجا تھا۔

زیادہ تر ری ڈائریکٹ تحقیقات اسی فرق پر غلط ہوتی ہیں۔

IPv4 اور IPv6 اسے مختلف طریقے سے پہنچاتے ہیں

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

پالیسی کی ترتیبات بھی الگ ہیں، اس لیے میزبان IPv4 ری ڈائریکٹ قبول کر سکتا ہے اور IPv6 کو نظر انداز کر سکتا ہے، یا اس کے برعکس۔

اگر زیر بحث بہاؤ دونوں میں سے کوئی بھی استعمال کر سکتا ہے تو دونوں خاندان جانچیں۔

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

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

محفوظ ری ڈائریکٹ کی ترتیبات مزید محدود کرتی ہیں کہ کون سے گیٹ ویز پر بھروسہ کیا جا سکتا ہے۔

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

ری ڈائریکٹ کیا واضح نہیں کر سکتا

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

پرانا کیپچر دوسرا جال ہے، کیونکہ نیٹ ورک بدلنے والے کلائنٹ کا مقامی گیٹ وے مختلف ہوتا ہے۔

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

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

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

ری ڈائریکٹ کبھی اس بات کا سبب نہیں ہونا چاہیے کہ محفوظ راستہ خاموشی سے غیر محفوظ ہو جائے، اسی لیے قبولیت کی پالیسی ڈیزائن جائزے میں شامل ہونی چاہیے۔ RFC 792 کی تعریف اس بات کا حوالہ رہتا ہے کہ IPv4 پیغام کیا کہہ سکتا ہے۔

راستے کی تلاش کا نتیجہ اور کیپچر کا وقت اکٹھے لکھیں، پھر اگلا شخص آپ کا نتیجہ دہرا سکے گا۔