وہ L2TP پتہ IPCP ہے، LAN پر DHCP لیز نہیں

کنکشن آتا ہے اور اڈاپٹر دفتر کی رینج میں پتہ دکھاتا ہے، اس لیے فطری نتیجہ یہ ہے کہ VPN نے آپ کو LAN پتہ دیا اور اس طرح آپ کو LAN پر رکھا۔ اس کے دونوں نصف حصے پوری طرح درست نہیں ہیں۔ L2TP PPP سیشن لے کر چلتا ہے، اور PPP IPCP کے ساتھ اندرونی IPv4 پتے پر گفتگو کرتا ہے۔ وہ پتہ دو فریقوں کے درمیان طے شدہ سیشن پیرامیٹر ہے، دفتر کے DHCP سرور کی دی ہوئی لیز نہیں، اور اسے رکھنا آپ کو دفتر کی تار پر پڑوسی نہیں بناتا۔

ایک کنکشن میں دو پتے

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

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

IPCP بالکل کیا کرتا ہے

IPCP PPP کے لیے IPv4 کنٹرول پروٹوکول ہے۔ ہر فریق اپنے مطلوبہ اختیارات بیان کرنے والے Configure-Request پیغامات بھیجتا ہے، اور پتے کا اختیار ان میں سے ایک ہے۔ جس کلائنٹ کے پاس ابھی پتہ نہیں وہ عام طور پر 0.0.0.0 کے ساتھ پوچھتا ہے، اور سرور وہ پتہ لے کر Configure-Nak سے جواب دیتا ہے جو وہ کلائنٹ سے استعمال کروانا چاہتا ہے۔ پھر کلائنٹ وہی پتہ مانگتا ہے، اور سیشن مقامی اور دور کے پتے کے ساتھ چل پڑتا ہے۔

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

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

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

LAN آپ کو جواب کیوں نہیں دے سکتا

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

اسی لیے اوورلیپ ہوتی رینجیں اپنے ظاہری حجم کے حساب سے ناموزوں مشکلات پیدا کرتی ہیں۔ اگر پول کلائنٹ کی پہلے سے استعمال شدہ LAN سے اوورلیپ ہو جائے، تو کلائنٹ کی روٹنگ جدول میں اب ایک ہی سابقے پر دو دعوے ہیں، اور غلط دعوہ اکثر ایسی وجوہات سے جیت جاتا ہے جن کا سرنگ سے کوئی تعلق نہیں۔

پہلے سیشن جانچیں، پھر راستہ

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

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

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

تینوں مراحل الگ رکھیں

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

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