VPN اڈاپٹر /32 دکھاتا ہے: اس کا مطلب ایک ہی منزل نہیں

اڈاپٹر 255.255.255.255 دکھاتے ہیں، اور اکثر یہ نتیجہ نکالا جاتا ہے کہ VPN بالکل ایک ہی پتے تک پہنچتا ہے۔ یہ قرأت کلائنٹ کے اپنے پتے کو ٹنل سے گزرنے والے منزلوں کے مجموعے سے ملا دیتی ہے۔ پوائنٹ ٹو پوائنٹ یا روٹ شدہ انٹرفیس پر یہ دو الگ چیزیں ہیں، اور ان میں سے صرف ایک رسائی کو محدود کرتی ہے۔ یہ افسانہ اس لیے زندہ ہے کہ ماسک Ethernet پر سیکھے گئے سب نیٹ ماسک جیسا لگتا ہے۔

افسانہ: میزبان ماسک کا مطلب ایک ہی قابلِ رسائی میزبان ہے

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

اس الجھن کی حقیقی جڑ ہے: Ethernet پر میزبان ماسک واقعی اسی حصے میں ایک ہی پتہ مراد لیتا۔ ٹنل Ethernet کا حصہ نہیں، اور اس میں سے کیا گزرتا ہے یہ ماسک نہیں، کلائنٹ کی روٹنگ جدول طے کرتی ہے۔ اسی لیے وہی /32 پورے ڈیٹا سینٹر کے سامنے کھڑا ہو سکتا ہے۔

پتے اور راستوں کو الگ الگ چیزوں کے طور پر پڑھیں

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

اگر تلاش غلط انٹرفیس کی طرف اشارہ کرے تو رکیں۔ یہ کلائنٹ کی روٹنگ کا مسئلہ ہے، اور یہ کلائنٹ پر ہی درست ہوتا ہے۔

ماسک چوڑا کرنے سے عام طور پر صورتحال مزید خراب کیوں ہوتی ہے

دفتر کے LAN جیسا دکھنے کے لیے تقسیم کو /24 میں بدلنا لنک پر سابقہ بنا سکتا ہے: کرنل اب یقین رکھتا ہے کہ پورا /24 براہِ راست ٹنل انٹرفیس سے جڑا ہے۔ جن پتوں کا گیٹ وے سے گزرنا چاہیے تھا ان کی ٹریفک پھر ایسے بھیجی جاتی ہے جیسے لنک پر کوئی پڑوسی ہو۔ نتیجہ ایک سیاہ شگاف ہے جو سرور کی خرابی جیسا لگتا ہے۔

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

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

جب راستہ درست ہو اور بہاؤ پھر بھی ناکام ہو

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

جس افسانے کو ریٹائر کرنا چاہیے وہ یہ ہے کہ ماسک رسائی کی حد ہے۔ پتہ، راستے اور گیٹ وے کی پالیسی کو تین الگ حقائق سمجھ کر پڑھیں، پھر /32 حد جیسا لگنا بند کر دیتا ہے اور عام ٹنل تقسیم جیسا لگنے لگتا ہے۔