VPN کا ساتھی دوسرے انٹرفیسز پر پنگ کرتا ہے کیونکہ وہ مقامی ہیں

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

ایک راستہ کسی اور کی طرف سے پیکٹ فارورڈ کرتا ہے؛ دوسرا انہیں خود میزبان تک پہنچاتا ہے۔

میزبان کو بھیجا گیا پیکٹ میزبان میں ہی رہتا ہے

دور دراز کلائنٹ میزبان کے پاس موجود پتے پر IP پیکٹ بھیجتا ہے۔ روٹنگ اس پیکٹ کے بارے میں ایک سوال پوچھتی ہے: کیا یہ منزل مقامی ہے؟ میزبان کے پاس موجود ہر پتہ مقامی روٹنگ جدول میں ظاہر ہوتا ہے، اور اس جدول کو مرکزی جدول سے پہلے دیکھا جاتا ہے، اس لیے پیکٹ کسی دوسرے انٹرفیس سے باہر جانے کے بجائے میزبان کے اپنے اسٹیک میں جاتا ہے۔ جواب مقامی طور پر بنتا ہے، اور ٹنل سے واپس آتا ہے کیونکہ سوال وہیں سے آیا تھا۔

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

ip_forward لاگو کیوں نہیں ہوتا

فارورڈنگ ان پیکٹوں کو کنٹرول کرتی ہے جنہیں جس انٹرفیس پر آئے تھے اس کے علاوہ کسی اور انٹرفیس سے باہر جانا ہوتا ہے۔ میزبان کو ہی پنگ کبھی وہ راستہ نہیں لیتی: پیکٹ مقامی طور پر استعمال ہوتا ہے اور جواب مقامی طور پر بنتا ہے۔ اسی لیے net.ipv4.ip_forward=0 مقرر کرنے سے یہاں کچھ نہیں بدلتا، اور فارورڈ چین کا کوئی قاعدہ اس ٹریفک کو کبھی نہیں دیکھتا۔ درست کنٹرول ان پٹ راستے پر ہے، جو آنے والے انٹرفیس یا ماخذ سے محدود ہے۔

اسی لیے فارورڈنگ بند کرنا اور یہ ماننا کہ میزبان الگ تھلگ ہے، سیکیورٹی کا جھوٹا احساس پیدا کرتا ہے۔

وہ مقامی جدول پڑھیں جس نے فیصلہ کیا

ip rule show عام طور پر صفر ترجیح کا قاعدہ بتاتا ہے جو تمام تلاشیں پہلے مقامی جدول میں بھیجتا ہے، اور ip route show table local میزبان کے اپنے پتوں کو مقامی دائرے کے ساتھ فہرست کرتا ہے۔ اس جدول میں ایسے انٹرفیسز کے پتے بھی شامل ہیں جو انتظامی طور پر بند مگر ابھی تک تشکیل شدہ ہیں۔ مستقل طور پر تفویض کردہ IPv4 پتے عام طور پر لنک ٹوٹنے پر بھی رہتے ہیں، اور اسی لیے بند پل پر پنگ اب بھی کامیاب ہو سکتی ہے اور آپریٹر کو حیران کر سکتی ہے۔

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

ایک ساتھی حقیقت میں کہاں تک پہنچتا ہے

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

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

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