SSH اور VPN کے دخول کے قواعد: فہرستِ اجازت دراصل کیا کنٹرول کرتی ہے

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

ایک SSH کوشش کی دخول ہک تک پیروی کریں

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

پھر سننے والے کی تصدیق کریں، کیونکہ جو سروس موجود نہیں اسے کوئی قاعدہ نہیں بچا سکتا۔ ss -ltnp چلائیں اور دیکھیں کہ توقع کردہ پورٹ اور پتوں کے خاندان سے کچھ بندھا ہے، پھر کلائنٹ پر ssh -v پڑھیں تاکہ معلوم ہو کہ یہ کہاں رکتا ہے۔

آگے بھیجنا ایک الگ فیصلہ ہے

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

اندرونی پالیسی کو الگ سوال کے طور پر لکھیں: کون سے کلائنٹ پتے سرنگ کے ذریعے کن منزلوں تک پہنچ سکتے ہیں۔ انتظامی راستہ، مثلاً SSH، کو اپنی ماخذ پابندی کے ساتھ دخول کے راستے پر رکھیں۔ آزمائش کے دوران شامل کیا گیا نرم forward قاعدہ وہی کلاسیکی نقص ہے جو آزمائش سے زیادہ جیتا ہے، اس لیے تبدیلی کے بعد آپ کی ترمیم کردہ ایک سطر کے بجائے پورے مجموعے کا جائزہ لیں۔ سرنگ کا سننے والا کھولنا ہر جڑے ہوئے کلائنٹ کو میزبان کے انتظام کی اجازت نہیں ہے۔

ڈراپ اور رجیکٹ اعمال ہیں، پالیسیاں نہیں

بنیادی چین کی پالیسی قبول کرتی ہے یا ڈراپ، اور یہی اختیارات کی پوری فہرست ہے، جیسا کہ nftables کا حوالہ کہتا ہے۔ رجیکٹ منتخب جواب کے ساتھ قاعدے کے عمل کے طور پر موجود ہے، اسی لیے اسے پالیسی کے طور پر لکھنا nftables اور iptables دونوں پر ناکام ہوتا ہے۔ عملاً drop کلائنٹ کو کوئی معلومات نہیں دیتا، جبکہ reject اسے ایسی خرابی دیتا ہے جس پر وہ عمل کر سکتا ہے۔

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

وہ کنٹرول ٹریفک رکھیں جس کی واقعی ضرورت ہے

تمام ICMP بلاک کرنا ایک مقبول طے شدہ قدر ہے جو راستے کی MTU دریافت کو توڑتی ہے، اور علامت وہ کنکشن ہے جو قائم ہو کر پھر بڑے پیکٹوں پر رک جاتا ہے۔ IPv6 پر ہمسایوں کی دریافت اپنی ICMPv6 اقسام پر منحصر ہے، اور انہیں پھینکنا کسی بھی TCP قاعدے کے دیکھے جانے سے پہلے رابطہ توڑ دیتا ہے۔ دونوں کو وسیع اجازت کے بجائے نامزد انحصار کے طور پر فہرستِ اجازت میں ہونا چاہیے۔ جو پالیسی دریافت کو خاموشی سے توڑتی ہے وہ تھوڑی تشخیصی ٹریفک قبول کرنے والی پالیسی سے بدتر ہے۔

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

پرانا راستہ چھوڑنے سے پہلے بحالی ثابت کریں

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

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