سورس پورٹ کا قاعدہ آپ کے ایک SSH راستے کو کیوں توڑتا ہے

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

دو اندراجات، ایک سروس پورٹ

میزبان کے پاس LAN کی طرف کا پتہ اور VPN پتہ ہے، اور sshd دونوں پر سنتا ہے۔ اسی لیے براہِ راست سیشن اور سرنگ سیشن سروس پورٹ بانٹتے ہیں اور صرف اس میں مختلف ہیں کہ کون سا مقامی پتہ کنکشن وصول کرتا ہے۔

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

ہر اندراج کو اپنی پورٹ دینا بھی کام کرے گا، اور اِسے ضرورت ماننا SSH کی خصوصیت نہیں بلکہ ڈیزائن کا انتخاب ہے۔

قاعدہ پڑھیں، پھر جدول

پالیسی قاعدہ ایک ترتیب شدہ سلیکٹر ہے، اور قابلِ استعمال جواب دینے والا پہلا قاعدہ تلاش ختم کر دیتا ہے۔ فہرست کو ترتیب سے پڑھیں اور دیکھیں کون سا قاعدہ جیت سکتا ہے۔

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

ip -4 rule show
ip route show table 100
ip route show table main

یہ دونوں نتائج مل کر نتیجہ واضح کرتے ہیں؛ کوئی بھی اکیلا غلط نتیجے کی دعوت دیتا ہے۔

قاعدے کو اُسی بہاؤ تک محدود کریں جس کا آپ ارادہ رکھتے ہیں

دونوں اندراجات کو الگ کرنے والی خصوصیت مقامی سورس پتہ ہے۔ اُس پتے سے مطابقت رکھنے والا قاعدہ صرف سرنگ سیشنوں کو نجی جدول میں بھیجتا ہے اور براہِ راست سیشنوں کو مرکزی جدول پر رہنے دیتا ہے۔

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

سننے والا، اجازت اور جواب کا انتخاب الگ رکھیں

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

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

ایسا بحالی چینل رکھیں جو اُس راستے پر منحصر نہ ہو جسے آپ بدل رہے ہیں، کیونکہ یہاں کی غلطی خود اصلاح کو بند کر دیتی ہے۔

اِسے نئی سیشن سے ثابت کریں، پرانی سے نہیں

قائم شدہ ٹرمینل کچھ ثابت نہیں کرتا، کیونکہ اُسے تبدیلی سے پہلے داخل کیا گیا تھا۔ ہر مطلوبہ اندراج سے نئی سیشن کھولیں۔

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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