PPP کا peer پتہ یا VPN اختتامی نقطہ: via میں کون جاتا ہے

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

ایک انٹرفیس سطر کی دو قراءتیں

ایسا سیشن لیں جس میں انٹرفیس inet 10.64.3.9 peer 10.64.3.1/32 بتاتا ہے۔ سب نیٹ قراءت 10.64.3.9 کو /32 جزیرے پر تنہا میزبان مانتی ہے اور پھر اس سے آگے کچھ بھی پہنچنے کے لیے راؤٹر ڈھونڈتی ہے۔ چونکہ ربط پر دوسرا واحد پتہ peer ہے، وہ قراءت آخرکار 10.64.3.9 کو ہی گیٹ وے تجویز کرتی ہے، جو دائروی ہے۔

اختتامی نقطے کی قراءت ہی دستاویزی ہے۔ پوائنٹ ٹو پوائنٹ انٹرفیس پر peer اسی ایک ربط کے دور سرے کا نام لیتا ہے، اس لیے 10.64.3.1 ہی قابل استعمال اگلی چھلانگ ہے اور 10.64.3.9 ہمیشہ صرف ماخذ پتہ ہے۔

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

سیشن پہلے ہی کیا نصب کر چکا ہے

اپنا جدول لکھنے سے پہلے چھاپیں کہ ربط کے ساتھ کیا آیا۔ معاون PPP انضمام عام طور پر سیشن قائم کرتے وقت ایک ڈیوائس راستہ اور ایک peer راستہ نصب کرتا ہے، اور یہ دونوں اندراجات پہلے ہی درست قراءت کو رمز کرتے ہیں۔

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 جیسا ڈیوائس راستہ گیٹ وے نہیں رکھتا کیونکہ انٹرفیس خود راستہ ہے۔ via سے peer کا نام لینے والا راستہ الگ عمر کی الگ شے ہے، اور سیشن گرنے پر وہ غائب ہو جاتا ہے۔ دونوں میں سے کوئی بھی شکل دوبارہ کیسے نصب ہوتی ہے یہ دیکھے بغیر مستقل جدول میں نقل کرنا ہی چلتی سرنگ کا دوبارہ جڑنے کے بعد اپنا راستہ کھو دینے کی عام وجہ ہے۔

یادداشت پر بھروسا کرنے کی بجائے دونوں فہرستیں موازنہ کریں۔ peer راستہ main میں ہونے کے باوجود اگر آپ کا اضافی جدول خالی ہے، تو پتے کی سطر نے جو کبھی نہیں بتایا وہ آپ نے سیکھا۔

قاعدہ اور جدول الگ فیصلے ہیں

جدول چننا اور اسے بھرنا خودمختار اقدامات ہیں، اور ڈی بگ کرتے وقت یہ دونوں اکثر خلط ملط ہو جاتے ہیں اس لیے یہاں موازنہ اہم ہے۔ نشان زدہ ٹریفک کو جدول 100 میں بھیجنے والا قاعدہ کچھ نہیں کرتا اگر جدول 100 میں مطابق راستہ نہ ہو، اور اچھی طرح بھرا جدول بھی اس کی طرف اشارہ کرنے والا قاعدہ نہ ہو تو ناقابل رسائی ہے۔

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

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

تلاش سے وہی سوال پوچھیں جو آپ کی ایپ پوچھتی ہے

ip route get کسی راستے کو حل کرتا ہے، ip route show ذخیرہ شدہ اندراجات کی فہرست دیتا ہے، اور دونوں کسی کے غلط نہ ہونے کے باوجود مختلف ہو سکتے ہیں۔ ماخذ سیاق شامل کریں، کیونکہ ماخذ پر مبنی قواعد صرف اسی وقت منطبق ہوتے ہیں جب تلاش ماخذ ساتھ لے کر چلے۔

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

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

موازنہ کہاں پلٹتا ہے

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

اگر باہر جانے والی راؤٹنگ درست دکھتے ہوئے بھی جواب غائب ہو جائیں، تو انہیں چھونے سے پہلے مؤثر قدریں پڑھیں، اور صرف بیان کردہ پالیسی وجہ سے انہیں بدلیں۔

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

دونوں ڈیزائنوں میں سے ثبوت کی بنیاد پر چنیں: اگر ایپ PPP پتے سے بندھی ہو تو ماخذ قاعدہ اور peer راستہ رکھنے والا جدول کافی ہے۔ اگر باکس اپنے پیچھے کے LAN کے لیے آگے بھیجے تو دخولی سیاق اور واپسی راستہ بھی مطابق ہونے چاہئیں۔ نہ ملیں تو پوری مشین کے لیے توثیق ڈھیلی کرنے کی بجائے راستے کی ملکیت درست کریں۔