VPN پورٹ کھولنا کلائنٹس کو LAN تک نہیں پہنچاتا

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

دو سلسلے، دو مختلف منزلیں

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

پوری داستان ایک جملے میں: سننے والے کو اجازت دینا اس کے پیچھے والے نیٹ ورک کو اجازت دینے کے بارے میں کچھ نہیں کہتا۔ یہ الگ ثبوتوں والے دو الگ فیصلے ہیں، اور دونوں پر انٹرفیس کا نام ہونا انہیں ایک نہیں کرتا۔

سننے والے کا قاعدہ دراصل کیا اجازت دیتا ہے

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

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

کلائنٹ سے جانچیں، گیٹ وے سے کبھی نہیں

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

فارورڈنگ کو ایک نہیں، تین چیزیں درکار ہیں

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

دستاویزات میں دونوں قواعد کے مجموعے الگ رکھیں

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

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

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