Linux VPN کے جوابات غائب ہو رہے ہیں؟ rp_filter اور راستہ جانچیں

درخواستیں مشین سے نکلتی ہیں، VPN ساتھی جواب دیتا ہے، اور جواب کبھی ساکٹ تک نہیں پہنچتا۔ ٹنل قائم ہے، ساتھی کے لاگ پیکٹ بھیجے جانے کو ظاہر کرتے ہیں، اور ایپلیکیشن میں کوئی چیز اس خاموشی کی وضاحت نہیں کرتی۔ Linux میں عام مشتبہ افراد میں سے ایک الٹے راستے کی فلٹرنگ ہے: آنے والا IPv4 پیکٹ مسترد ہو سکتا ہے جب ماخذ کی تصدیق اس راستے سے نہ ملے جو کرنل اس ماخذ کے لیے توقع کرتا ہے۔ ترتیب سے اس پر چلنا بتاتا ہے کہ یہ وجہ ہے یا اتفاق۔ یہ آپ کو کسی غائب راستے کو ٹھیک کرنے کے لیے حفاظتی کنٹرول بند کرنے سے بھی روکتا ہے۔

ماخذ کی تصدیق کیا طے کرتی ہے

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

اہم لفظ معقول ہے۔ پیکٹ مکمل طور پر جائز ہو سکتا ہے اور پھر بھی جانچ میں ناکام ہو سکتا ہے، کیونکہ جائز ہونے کی جانچ نہیں ہوتی۔

مؤثر موڈ پڑھیں، ایک فیلڈ نہیں

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

جانچ بدلنے سے پہلے عدم مطابقت تلاش کریں

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

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

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

ایک انتخاب شدہ ایڈجسٹمنٹ جس کا آپ دفاع کر سکتے ہیں

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

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

IPv4 اور IPv6 کو الگ رکھیں

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

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