VPN پتے سے بندھی ایپ پھر بھی غلط راستہ استعمال کرتی ہے

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

اس رہنما کا بقیہ حصہ وہ جانچ ترتیب ہے جو میں استعمال کرتا ہوں، ہر مشاہدہ دینے والی کمانڈ کے ساتھ۔

بائنڈ اصل میں کیا طے کرتا ہے

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

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

Linux IP ساکٹ حوالہ بائنڈ کے معنی بیان کرتا ہے۔ روٹنگ کا آدھا حصہ ip-rule اور ip-route میں رہتا ہے، اور یہ کسی وجہ سے الگ مینول ہیں۔

یقینی بنائیں کہ پتہ اسی نیم اسپیس کا ہے

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

اس ماخذ اور منزل کے لیے تلاش پڑھیں

ایک کمانڈ اس سوال کا جواب دیتی ہے جو بائنڈ نے نہیں دیا:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

پھر ip rule show بتاتا ہے کہ کیا کوئی قاعدہ دوسری جدول منتخب کرتا۔ یہاں ترجیحات اہم ہیں، کیونکہ پہلا مماثل قاعدہ جیتتا ہے، اور آپ کے قاعدے کے اوپر سب کچھ پکڑنے والا قاعدہ آپ کے قاعدے کو نادیدہ کر دیتا ہے۔

پالیسی قاعدہ صرف اسی صورت میں نصب کریں جب یہی ڈیزائن ہو

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del اور ip route flush table 100 سے واپس لیں۔ اس طرح شامل کیا گیا سب کچھ ری بوٹ پر غائب ہو جاتا ہے، جب تک کوئی منتظم اسے نہ لکھے؛ یہ ایک حفاظتی خصوصیت بھی ہے اور واحد نقل اپنی شیل تاریخ میں نہ رکھنے کی وجہ بھی۔

تین مشاہدات سے تصدیق کریں

ایپ نے جو ماخذ مانگا، تلاش نے جو راستہ چنا، اور سرور نے واقعی جو ماخذ دیکھا، تینوں درج کریں۔

یہ تین مختلف ہو سکتے ہیں، اور ہر اختلاف کہیں اور اشارہ کرتا ہے۔ سرنگ انٹرفیس پر کیپچر ثابت کرتا ہے کہ پیکٹ درست ماخذ کے ساتھ نکلا۔ جسمانی انٹرفیس پر کیپچر ثابت کرتا ہے کہ یہ غلط راستے سے نکلا۔ راستے کو شروع سے آخر تک ثابت کرنے والا صرف سرور کی طرف کا منظر ہے۔

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