VPN کلائنٹ کے پیچھے موجود سرور سرنگ کے ذریعے کیوں جواب دیتا ہے
جب جواب آمد کے راستے کے بجائے VPN کے ڈیفالٹ راستے کی پیروی کریں تو آنے والے کنکشن ناکام ہو جاتے ہیں۔ پالیسی روٹنگ یا ماخذ NAT واپسی کا راستہ بحال کرتا ہے۔
جس ہوسٹ پر VPN کلائنٹ بھی چل رہا ہو، اس پر آنے والے کنکشن بہت مخصوص انداز میں ناکام ہوتے ہیں: ہینڈ شیک آتا ہے، ڈیمن جواب دیتا ہے، اور کلائنٹ کو کچھ واپس نہیں ملتا۔ پورٹ کو کوئی چیز روک نہیں رہی۔ جواب سرنگ سے باہر گیا، کیونکہ سرنگ ڈیفالٹ راستے کی مالک ہے اور کرنل جوابات کو منزل کے مطابق روٹ کرتا ہے، اس یاد کے مطابق نہیں کہ درخواست کہاں سے آئی تھی۔ یہی ایک کوتاہی آگے آنے والی ہر علامت کی وضاحت کرتی ہے۔
جواب روٹ ہوتا ہے، یاد نہیں رکھا جاتا
ڈیفالٹ راستہ نصب کرنے والا VPN کلائنٹ ایسی اندراج شامل کرتا ہے جو LAN گیٹ وے سے آگے نکل جائے، یا تو میٹرک سے یا جگہ کو دو زیادہ مخصوص حصوں میں تقسیم کر کے۔ باہر جانے والے پیکٹ اب سرنگ کا انٹرفیس منتخب کرتے ہیں۔ کرنل کبھی نہیں پوچھتا کہ جس پیکٹ کا جواب دیا جا رہا ہے وہ اصل میں کہاں سے آیا۔ یہی ایک کوتاہی آگے آنے والی ہر علامت کی وضاحت کرتی ہے۔
آگے کی سمت منزل کے مطابق روٹ ہوتی ہے، اور پیچھے کی سمت بھی۔ جواب ایک عوامی کلائنٹ کو مخاطب ہے، جسے سرنگ خوشی سے لے جائے گی۔ دور کا سرا ایسا پیکٹ وصول کرتا ہے جس کا ماخذ اس کا نہیں، اسے پھینک دیتا ہے، اور اصل کلائنٹ وقت ختم ہونے تک انتظار کرتا ہے۔
سخت ریورس پاتھ فلٹرنگ آنے والے پیکٹ کو ڈیمن کے پڑھنے سے پہلے ہی گرا سکتی ہے۔ پہلے وہ کاؤنٹر دیکھیں، کیونکہ فلٹر کی گراوٹ اور روٹنگ کی غلطی باہر سے ایک جیسی دکھتی ہیں۔
ip route show default sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter nft list ruleset | grep -A3 'hook forward'
پہلا کمانڈ دکھاتا ہے کہ ابھی کون سا ڈیفالٹ جیت رہا ہے۔ دوسرا بتاتا ہے کہ سخت فلٹرنگ عالمی سطح پر لاگو ہے یا ہر انٹرفیس کے لیے، اور تیسرا فارورڈ چین کا کوئی بھی قاعدہ دکھاتا ہے جو شامل ہو سکتا ہے۔
واپسی کا راستہ برقرار رکھنے کے تین طریقے
سروس کی منزل کو سرنگ سے باہر رکھنا سب سے تنگ آپشن ہے۔ LAN گیٹ وے کی طرف اشارہ کرنے والا ہوسٹ راستہ، ساتھ میں ہر پتے کے بجائے طبعی پتے سے بندھا ڈیمن، اس ایک بہاؤ کو سرنگ سے باہر رکھتا ہے۔ تبدیلی مقامی ہے اور واپس کرنا آسان ہے۔
پالیسی روٹنگ عام جواب ہے۔ ماخذ پتے یا فائر وال نشان پر کلید کیا گیا قاعدہ ایسی جدول منتخب کرتا ہے جس کا ڈیفالٹ WAN گیٹ وے کی طرف اشارہ کرتا ہے، جبکہ ہوسٹ کے اپنے کنکشن سرنگ استعمال کرتے رہتے ہیں۔ ترجیح واضح رکھیں تاکہ قاعدہ بعد میں چھایا نہ جائے۔
ip rule add from 203.0.113.25/32 table 100 priority 100 ip route add default via 192.0.2.1 dev eth0 table 100 ip route get 198.51.100.7 from 203.0.113.25
پہلے دو کمانڈ عوامی پتے سے آنے والے جوابات کے لیے متبادل راستہ بناتے ہیں۔ تیسرا کرنل سے پوچھتا ہے کہ بالکل وہی ماخذ اور منزل کون سا راستہ لیں گے، اور اسی طرح آپ تصدیق کرتے ہیں کہ قاعدے کا کوئی اثر ہے۔
ماخذ کی ترجمانی تیسرا آپشن ہے اور واحد ہے جو سروس کے آگے پہلے سے NAT کرنے والے راؤٹر کے سامنے ٹکتا ہے۔ جواب کو اسی راؤٹر کی طرف واپس جانا ہوتا ہے، اور WAN انٹرفیس پر ماسکریڈنگ یہ حاصل کرتی ہے اور کلائنٹ کو سروس لاگز سے چھپاتی ہے۔ جڑنے کے بعد ڈیفالٹ راستہ ہاتھ سے بدلنا ایک تشخیص ہے، کیونکہ کلائنٹ اگلی بار دوبارہ جڑنے پر جدول دوبارہ لکھتا ہے۔
جب باکس LAN کے لیے بھی روٹ کرتا ہے
یہی ناکامی ایک ہاپ مزید دور ظاہر ہوتی ہے جب ہوسٹ اپنے پیچھے کے آلات کے لیے روٹ کرتا ہے۔ آنے والا کنکشن اندرونی آلے کی طرف بھیجا جاتا ہے جس کا واحد واپسی راستہ سرنگ ہے، اور جواب فراہم کنندہ کے پتے سے بیرونی کلائنٹ تک پہنچتا ہے۔ اندرونی آلہ پورے وقت درست کام کر رہا ہوتا ہے۔
پھر کنکشن ٹریکنگ کو ایسے بہاؤ کا جواب نظر آتا ہے جو اس نے کبھی ریکارڈ نہیں کیا اور وہ اسے گرا دیتی ہے۔ منزل کی ترجمانی آنے والا کنکشن آلے تک پہنچاتی ہے، اور ماخذ کی ترجمانی جواب کو ایسا دکھاتی ہے جیسے وہ خود راؤٹر سے آیا ہو۔
وہ پالیسی راستہ جو بھیجا گیا پورٹ WAN پر رکھتا ہے اور راؤٹر کی اپنی ٹریفک سرنگ استعمال کرتی ہے، زیادہ صاف متبادل ہے۔ ماخذ کی ترجمانی کے بغیر جواب بیرونی کلائنٹ کو مخاطب ہوتا ہے، اور اندرونی آلے کے پاس اس پتے کا کوئی راستہ نہیں۔
اسباب کو الگ کرنے والے تین جائزے
تین جائزے کریں: انٹرنیٹ سے باکس میں کنکشن، اس سے عوامی ہوسٹ کی طرف کنکشن، اور نام کی تلاش۔ جب پہلے دو متفق نہ ہوں تو واپسی کا راستہ قصوروار ہے۔ جب نام دونوں سمتوں میں ناکام ہوں تو حل کنندہ ایک اور خرابی ہے جو صرف سرنگ شیئر کرتی ہے۔
پہلے روٹنگ کا سوال درست کریں، پھر نام دیکھیں۔ دونوں کو ملانا ہی وہ طریقہ ہے جس سے کام کرنے والا سرور خراب حل کنندہ کا ذمہ دار ٹھہرایا جاتا ہے۔
لکھیں کہ استثنا کس انٹرفیس کا نام لیتا ہے اور ترتیب کو ورژن کنٹرول میں رکھیں۔ اپ گریڈ کے بعد نام بدلنے والے انٹرفیس کے خلاف لکھا گیا قاعدہ آج پاس ہوتا ہے اور اگلی ری بوٹ کے بعد ناکام ہوتا ہے۔