VPN گیٹ وے کو IP فارورڈنگ کی ضرورت ہے: کیا جانچنا چاہیے
گیٹ وے اپنے ہی پتے پر جواب دے سکتا ہے جبکہ انٹرفیس کے درمیان کچھ نہیں گزرتا۔ ہر خاندان کے لیے فارورڈنگ، پھر واپسی کا راستہ جانچیں۔
آپ کا کلائنٹ گیٹ وے کے پتے پر پنگ کر سکتا ہے جبکہ اس کے پیچھے ہر وسیلہ ناقابل رسائی رہتا ہے۔ یہ دو مشاہدے ایسے میزبان کی وضاحت کرتے ہیں جو آپ سے بات کر رہا ہے اور ایسے روٹر کی جو روٹنگ نہیں کر رہا، جو ایک ہی مشین پر الگ کردار ہیں۔ فارورڈنگ ان کے درمیان سوئچ ہے۔
دونوں کردار آزاد ہیں، اور دونوں پتہ خاندان بھی۔
اپنے ہی پتے پر جواب دینا کچھ ثابت نہیں کرتا
جب کوئی پیکٹ گیٹ وے ہی کو مخاطب کیا جائے، مقامی اسٹیک اسے استعمال کر لیتا ہے اور کوئی فارورڈنگ فیصلہ نہیں ہوتا۔ اسی لیے ٹنل کے پتے یا انتظامی انٹرفیس پر کامیاب پنگ آپ کو بتاتی ہے کہ ڈیمون زندہ ہے اور ٹنل چالو ہے، مگر باکس کے پیچھے کے نیٹ ورک کے لیے بھیجی گئی ٹریفک کے بارے میں کچھ نہیں بتاتی۔ کرنل اپنے فارورڈنگ راستے کو صرف ان پیکٹوں کے لیے دیکھتا ہے جو اسے مخاطب نہیں کیے گئے۔
ضرورت کو سیٹنگ نہیں، کردار کے طور پر پڑھیں: اس میزبان کو دو انٹرفیس کے درمیان پیکٹ منتقل کرنے ہوں گے۔ جس لیپ ٹاپ کو صرف دور دراز نیٹ ورک تک پہنچنا ہے وہ یہ کردار کبھی نہیں لیتا، اور سائٹ سے سائٹ اینڈ پوائنٹ ہمیشہ لیتا ہے۔ ضرورت کو اس طرح پڑھنا واضح کرتا ہے کہ کام کرنے والی کلائنٹ کنفیگریشن گیٹ وے پر منتقل ہونے پر کیوں ناکام ہوتی ہے۔
یہی جملہ فارورڈنگ فیصلے کے سامنے والے فائر وال پر بھی لاگو ہوتا ہے، جس کی اپنی پالیسی ہے کہ کیا فارورڈ کیا جا سکتا ہے۔
ہر پتہ خاندان کو الگ الگ جانچیں
IPv4 فارورڈنگ ایک سوئچ ہے، اور IPv6 فارورڈنگ دوسرا ہے جس کا ہر انٹرفیس پر اپنا رویہ ہے۔ پہلے کو فعال کرنا دوسرے کے بارے میں کچھ نہیں بتاتا، اور دوہرے اسٹیک والا کلائنٹ آدھے نیٹ ورک تک پہنچ سکتا ہے جبکہ باقی اندھیرے میں رہتا ہے۔ اس لیے مختلف خاندانوں کے دو کلائنٹ ایک ہی گیٹ وے پر متفق نہیں ہو سکتے۔ کوئی بھی سیٹنگ بدلنے سے پہلے پوچھیں کہ ناکام کلائنٹ نے کون سا خاندان استعمال کیا۔ روٹنگ ڈیزائن غلط ہے کا نتیجہ اخذ کرنے سے پہلے دونوں کی تصدیق کریں۔
sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40
بہت سی تقسیموں میں رن ٹائم میں آپ جو قدر پڑھتے ہیں وہ وہاں کسی سروس یا کنفیگریشن فائل نے رکھی ہوتی ہے، اس لیے ایک بار کے کمانڈ سے کیا گیا تبدیلی ری بوٹ پر غائب ہو سکتا ہے۔ رن ٹائم قدر میں ترمیم سے پہلے وہ فائل تلاش کریں جس کے پاس یہ سیٹنگ ہے۔
فارورڈنگ چار ضرورتوں میں سے ایک ہے
کام کرنے والے فارورڈ شدہ بہاؤ کو بیک وقت چار چیزیں درکار ہیں: کلائنٹ کو معلوم ہو کہ منزل ٹنل کے پیچھے ہے، گیٹ وے کے پاس آگے کا راستہ ہو، جوابات کے پاس واپسی کا راستہ ہو، اور فائر وال ٹریفک کی اجازت دے۔ ماخذ ترجمہ اس ڈیزائن میں قاعدہ نہیں بلکہ اختیار کے طور پر شامل ہے، کیونکہ ہم آہنگ راستوں والا نجی روٹ شدہ نیٹ ورک اسے ضروری نہیں سمجھتا اور غیر ہم آہنگ کو عام طور پر ضرورت ہوتی ہے۔ چاروں میں سے ہر ایک آزادانہ طور پر ناکام ہوتا ہے، اسی لیے ایک کو ٹھیک کرنے سے علامت شاذ و نادر ہی بدلتی ہے۔ کوئی بھی بدلنے سے پہلے چاروں لکھ لیں۔
کلاؤڈ پلیٹ فارم پانچویں پہلو کا اضافہ کرتے ہیں۔ کچھ انسٹانسز پر ماخذ اور منزل کی جانچ لازمی کرتے ہیں، جو مہمان کرنل کی تشکیل سے قطع نظر فارورڈ شدہ پیکٹ گرا دیتی ہے۔ وہاں اختیار پلیٹ فارم کی اپنی نیٹ ورکنگ دستاویزات کا ہے، VM کے اندر sysctl کے اخراج کا نہیں۔
گیٹ وے سے نہیں، کلائنٹ سے جانچیں
گیٹ وے کے اپنے شیل میں چلائی گئی جانچ اس فارورڈنگ راستے کے کسی حصے سے نہیں گزرتی جو آپ نے ابھی فعال کیا۔ مسئلہ والے کلائنٹ سے ٹریفک پیدا کریں، اور تصدیق کریں کہ وہ گیٹ وے کے پیچھے کسی چیز تک پہنچتی ہے، خود گیٹ وے تک نہیں۔ یہ واحد جانچ ہے جو آپ کے بدلے ہوئے کردار کو آزماتی ہے۔
سننے والے کے قواعد اور فارورڈنگ کے قواعد کو اپنے ذہن میں اور تبدیلی کے ریکارڈ میں الگ رکھیں۔ VPN پورٹ کھولنا کلائنٹوں کو سروس میں داخل کرتا ہے؛ یہ انہیں اس کے پیچھے کے نیٹ ورک پر کچھ نہیں دیتا، اور برسوں میں بڑھی فائر وال فہرست میں دونوں ایک جیسے دکھائی دیتے ہیں۔
اگر پیکٹ آئیں اور سروس صارف کو مسترد کر دے، تو آپ نیٹ ورکنگ سے آگے بڑھ چکے ہیں۔ فارورڈنگ پالیسی دوبارہ وسیع کرنے کے بجائے ایپلیکیشن کی اجازت کے ساتھ آگے بڑھیں۔