VPN کے ذریعے ping: بازگشت کے جواب کے قواعد واپسی کا راستہ کیوں کھو دیتے ہیں

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

پیکٹ پورٹ نہیں، قسم بدلتا ہے

بازگشت کی درخواست ICMP قسم 8، کوڈ 0 ہے، اور وہ شناخت کنندہ اور ترتیب نمبر لے کر چلتی ہے۔ جواب قسم 0، کوڈ 0 ہے، اسی شناخت کنندہ اور ترتیب کے ساتھ، اور IP سرے بدلے ہوئے ہیں۔ یہ فیلڈز RFC 792 متعین کرتا ہے، اور شناخت کنندہ ہی بھیجنے والے کو جوابات اپنی درخواستوں سے ملانے دیتا ہے۔

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

پیکٹ کے بارے میں تین سیاق فیصلہ کرتے ہیں

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

ان تین سیاق کے قواعد کے سلسلے اور کاؤنٹر مختلف ہیں، اور انہیں ایک ماننا ہی وہ وجہ ہے کہ «فائروال ICMP کی اجازت دیتا ہے» پھر بھی ناکام ping دے سکتا ہے۔ بیرونی سرنگ چوتھا سیاق ہے: VPN سننے والے کی اجازت دینے سے ڈیکپسولیٹ شدہ اندرونی درخواست خودبخود اجازت نہیں پاتی، اور اندرونی اجازت بیرونی سرنگ کے قائم ہونے کے بارے میں کچھ نہیں کہتی۔

حالت والے اور بے حالت فلٹر جواب کو مختلف طریقے سے سنبھالتے ہیں

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

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

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

ترجمہ شناخت کنندہ بھی بدلتا ہے

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

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

ICMP نقائص کو بازگشت کی پالیسی میں نہ ملائیں

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

یہی احتیاط پتوں کے خاندانوں پر بھی لاگو ہوتی ہے۔ ICMPv6 مختلف پیغام اقسام استعمال کرتا ہے اور ایسے ضروری افعال رکھتا ہے جو IPv4 میں نہیں، اس لیے ان نمبروں کو IPv6 قاعدے میں نقل کرنا سراسر غلط ہے۔

جب بازگشت کا تبادلہ کام کرے تو اصل اطلاقیہ الگ سے جانچیں۔ کامیاب ping ایک ہی پروٹوکول کا ایک ہی حجم میں ایک ہی منزل تک آنا جانا ثابت کرتا ہے، اور یہ HTTPS، SMB یا کسی بھی دوسرے بہاؤ کے اجازت یافتہ ہونے کا لائسنس نہیں۔