VPN راستہ ip route کے آؤٹ پٹ میں کوئی گیٹ وے کیوں نہیں دکھاتا
ڈیوائس والی مگر گیٹ وے کے بغیر لائن سیدھا راستہ ہے، ٹوٹا ہوا نہیں۔ منزل، dev اور scope پڑھیں، پھر ip route get سے تصدیق کریں۔
گیٹ وے کالم خالی دکھنے پر روٹنگ جدولوں کو ٹوٹا ہوا پڑھا جاتا ہے، حالانکہ لائن عموماً بذات خود مکمل ہوتی ہے۔ via فیلڈ صرف اُس وقت ظاہر ہوتا ہے جب کرنل پیکٹ کو اگلی ہاپ کے پتے کے حوالے کرتا ہے؛ انٹرفیس سے منسلک راستہ اپنے منزلوں تک اس کے بجائے لنک لیئر تحلیل یا پوائنٹ ٹو پوائنٹ ساتھی کے ذریعے پہنچتا ہے۔ کالموں کو بائیں سے دائیں پڑھنا بتاتا ہے کہ آپ کس صورت میں ہیں، اور یہ پڑھائی کسی کے ڈیفالٹ راستہ ترمیم کرنے سے پہلے ہونی چاہیے۔ گمشدہ گیٹ وے کے بارے میں زیادہ تر ٹکٹس اسی فرق پر ختم ہوتے ہیں۔
راستے کی لائن کو کالم بہ کالم پڑھیں
ہر اندراج منزل اور اس کے سابقے کی لمبائی سے شروع ہوتا ہے، پھر مقررہ الفاظ میں ترمیم کنندگان شامل کرتا ہے: via، dev، proto، scope، src اور metric۔ 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 جیسی لائن گھنی مگر مکمل طور پر متعین ہے۔ اس میں کچھ بھی غائب نہیں، اور کوئی راؤٹر پتہ مضمر نہیں۔
دلچسپ حصہ via کی عدم موجودگی ہے۔ اگلی ہاپ کے بغیر کرنل منزل کو براہ راست نامزد انٹرفیس پر حل کرتا ہے، جس کا ٹنل کے لیے مطلب ہے کہ فریم ٹنل ڈیوائس کو دیا جائے اور انکیپسولیشن کو وہیں سے سنبھالنے دیا جائے۔ proto kernel درج کرتا ہے کہ اندراج پتہ تفویض ہونے پر خودکار طور پر نصب ہوا تھا، کسی منتظم نے ٹائپ نہیں کیا۔ scope link کہتا ہے کہ منزل اُس لنک پر راؤٹر سے گزرے بغیر قابل رسائی ہے، اور src اُس پتے کا نام دیتا ہے جسے کرنل مماثل ٹریفک کے لیے ماخذ کے طور پر ترجیح دے گا۔
اب ڈیفالٹ راستہ اسی طرح پڑھیں: default via 192.0.2.254 dev eth0 proto static metric 100۔ یہاں via موجود ہے کیونکہ پیکٹ کو واقعی اگلی ہاپ درکار ہے، اور وہ ہاپ خود eth0 پر قابل رسائی ہونی چاہیے۔ یہ دونوں لائنیں ایک دوسرے کی اقسام نہیں؛ یہ اس بارے میں مختلف سوالات کے جواب دیتی ہیں کہ ٹریفک کہاں جاتی ہے۔
دو راستہ شکلیں جو آپس میں خلط ملط ہوتی ہیں
ٹنل سب نیٹ راستہ اور ڈیفالٹ راستہ اسکرین شاٹ میں ایک جیسے دکھتے ہیں مگر بالکل مختلف برتاؤ کرتے ہیں۔ نیچے دیا گیا جدول فیلڈز پڑھنے میں مدد کے طور پر استعمال کریں، پھر کسی گائیڈ کے نمونے پر بھروسہ کرنے کے بجائے اُسی مشین پر اصل اعداد کی تصدیق کریں جسے آپ ڈیبگ کر رہے ہیں۔
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
جدول جو نہیں بتا سکتا وہ نیت ہے۔ ٹنل کے ذریعے نجی رینج تک سیدھا راستہ جان بوجھ کر بنایا گیا اسپلٹ ٹنل ڈیزائن ہے؛ جس ہوسٹ کو سب کچھ VPN سے بھیجنا چاہیے وہاں وہی شکل دکھنا ایک علامت ہے۔ نیت اُس کنفیگریشن میں رہتی ہے جس نے اندراج بنایا، اس لیے یہ نتیجہ اخذ کرنے سے پہلے کہ کرنل نے کچھ غلط کیا، اُس آلے کو دیکھیں جس نے اسے نصب کیا۔
اسی طرح، گمشدہ گیٹ وے کسی ایک کو گھڑ لینے کی اجازت نہیں۔ اگر راستے کو واقعی اگلی ہاپ درکار ہو، تو وہ ہاپ اُس انٹرفیس پر قابل رسائی ہونی چاہیے جو اسے اٹھائے، اور پوائنٹ ٹو پوائنٹ ٹنل کے لیے ساتھی کا پتہ مقامی پتے جیسی وہی چیز نہیں۔ مقامی ٹنل پتے کو ایتھرنیٹ راؤٹر سمجھنا ایک ایسا راستہ بنانے کا عام طریقہ ہے جو درست دکھتا ہے اور کچھ آگے نہیں بھیجتا۔
کرنل سے پوچھیں کہ واقعی کون سی لائن استعمال کرے گا
جدول پڑھنا تلاش کرنے کے مترادف نہیں، کیونکہ جواب دینے سے پہلے کرنل پالیسی قواعد، متعدد جدولوں اور کیش شدہ اندراجات سے مشورہ کرتا ہے۔ اصل تلاش کرنے والا فعل ip route get ہے، اور یہ وہ راستہ چھاپتا ہے جو اُن خصوصیات والا پیکٹ اختیار کرے گا۔
ip route get 203.0.113.37 from 198.51.100.2 iif tun0وہ منزل رکھیں جس کی آپ کو واقعی پرواہ ہے، پھر جب ٹریفک ماخذ کے مطابق منتخب ہو یا آگے بھیجا جائے تو from یا iif شامل کریں، کیونکہ عام مقامی تلاش آگے بھیجے گئے کلائنٹ سے مختلف راستہ چن سکتی ہے۔ جواب انٹرفیس، منتخب ماخذ پتہ اور کوئی بھی اگلی ہاپ بتاتا ہے، جو اُس لمحے پیکٹ کی روٹنگ کے لیے استعمال ہونے والی وہی معلومات ہیں۔
اگر جواب آپ کو حیران کرے تو کچھ بھی بدلنے سے پہلے قواعد چھاپیں: ip -4 rule show انہیں ترجیحی ترتیب میں درج کرتا ہے، اور جو VPN کلائنٹ اپنا جدول یا نشان زدہ پیکٹوں کے لیے قاعدہ نصب کرتا ہے وہ مرکزی جدول میں بالکل نظر نہیں آئے گا۔ ہر جدول کی فہرست بنانا اُس خلا کو بھر دیتا ہے۔
ip -4 route show table all | grep -E 'tun|default'ڈیفالٹ بدلنے سے پہلے نیچے کی تہہ جانچیں
ٹنل کے اپنے پیکٹوں کو دور دراز کے آخری سرے تک پہنچنا ہے، اور وہ یہ VPN کے ابھرنے سے پہلے موجود راستے کو استعمال کرتے ہوئے طبعی انٹرفیس کے ذریعے کرتے ہیں۔ اُس سرے کو پن کیے بغیر پورا ڈیفالٹ راستہ بدلنا انکیپسول شدہ پیکٹوں کو اُسی ٹنل میں بھیجتا ہے جسے انہیں بنانا تھا، اور کنکشن ڈھیر ہو جاتا ہے۔ پہلے صرف آخری سرے کے پتے کی تلاش سے اُس کا راستہ تصدیق کریں۔
تبدیلی کرتے وقت تین چیزیں الگ رکھیں: آخری سرے کا راستہ جو طبعی انٹرفیس پر رہنا چاہیے، نجی رینجیں جو ٹنل میں داخل ہونی چاہئیں، اور ڈیفالٹ جو باقی سب کچھ طے کرتا ہے۔ انہیں اسی ترتیب میں الگ کریں، ایک وقت میں ایک لاگو کریں، اور ہر قدم کے بعد تلاش دوبارہ چلائیں۔ بعد میں ناکام ping بذات خود بہت کم ثابت کرتا ہے، کیونکہ اجازتیں، جواب کی روٹنگ، DNS اور خدمت خود سب درست راستے کے نیچے بیٹھے ہیں۔
ترمیم سے پہلے وہ چار قدریں لکھیں جو لائن نے آپ کو دیں: منزل، اگلی ہاپ یا اس کی عدم موجودگی، ڈیوائس، اور منتخب ماخذ۔ اگر بعد کی کوئی تبدیلی ان میں سے کسی کو ہلائے، تو آپ جانتے ہیں کہ کون سا فیصلہ واقعی بدلا، اور پورے جدول کا اندازہ لگانے کے بجائے ایک اندراج بحال کر سکتے ہیں۔