کیوں /32 ہوسٹ روٹ VPN کا آخری نقطہ قابل رسائی رکھتا ہے

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

ایک پتہ، جدول میں ایک اندراج

IPv4 ہوسٹ روٹ /32 سابقہ رکھتا ہے اور IPv6 ہوسٹ روٹ /128 رکھتا ہے، یعنی اندراج ٹھیک ایک منزل کے پتے سے مطابقت رکھ سکتا ہے۔ جدول میں کوئی اور چیز نہیں ہلتی: ڈھانپنے والا سب نیٹ اور ڈیفالٹ روٹ جہاں تھے وہیں رہتے ہیں۔ تنگ اندراج اس پتے کے لیے جیتتا ہے کیونکہ اس کا سابقہ لمبا ہے، اس لیے نہیں کہ یہ بعد میں شامل کیا گیا۔

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

اندراج کو کلائنٹ سے باہر کی طرف پڑھیں

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

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

آخری نقطے کا استثنا اور تکرار کا جال

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

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

اپلیکیشن واقعی جو راستہ استعمال کرتی ہے اس کی تصدیق کریں

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

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

اگر راستہ غلط ہے تو کچھ بھی ترمیم کرنے سے پہلے طے کریں کہ ضرورت نیٹ ورک ہے یا ایک پتہ۔ ایک پتے کی ضرورت تبصرہ اور مالک کے ساتھ ہوسٹ روٹ کو جائز ٹھہراتی ہے؛ گھومتے پتوں والی خدمت کو ڈومین پر مبنی روٹنگ یا ایماندار سب نیٹ فیصلے کی ضرورت ہے۔

اب حقیقی منزل سے مطابقت نہ رکھنے والے اندراجات ہٹا دیں اور رکھے جانے والے نوٹ کریں۔ غیر واضح /32 تین ماہ بعد بگ سے الگ نہیں پہچانا جا سکتا، اور اگلا شخص یہ جانے بغیر اسے مٹا دے گا کہ اس پر کیا منحصر تھا۔