روٹنگ ٹیبل بمقابلہ اصل تلاش: VPN ٹریفک کہاں جاتی ہے

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

جدول امیدواروں کا مجموعہ ہے، فیصلہ نہیں

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

اس لیے پہلا قدم فہرست پڑھنے کی بجائے کرنل سے پوچھنا ہے۔ تلاش کا حکم ایک منزل کے لیے جواب دیتا ہے، اور ماخذ کی دلیل کے ساتھ وہ اس عین جوڑے کے لیے جواب دیتا ہے جو فارورڈ شدہ یا بندھا ہوا کنکشن استعمال کرے گا:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

تلاش پہلے قواعد سے، پھر جدولوں سے گزرتی ہے

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 کے اپنے قواعد اور جدول ہیں۔ دونوں خاندانوں کو چلانے والے ڈیزائن کو دونوں تلاشیں درکار ہیں، اور کام کرنے والا IPv4 جواب v6 راستے کے بارے میں کچھ نہیں کہتا جسے دوہری اسٹیک کلائنٹ ترجیح دے سکتا ہے۔

VPN کلائنٹ کیا نصب کرتا ہے

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

اسی لیے "VPN نے میرا ڈیفالٹ راستہ تبدیل نہیں کیا" ناکامی کا ثبوت نہیں ہے۔ دیکھیں کہ اس نے واقعی کیا شامل کیا، اور کیا زیرِ بحث منزل ان سابقوں کے اندر آتی ہے:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

بیرونی راستہ بھی بچنا چاہیے

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

روٹنگ آؤٹ پٹ آپ کو کیا نہیں بتا سکتا

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

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

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