سائٹ VPN کے ذریعے دور دراز ASA تک SSH: قدم بہ قدم

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

وہ پتہ منتخب کریں جسے آپ واقعی منتظم کر رہے ہیں

تین ڈیزائن ایک جیسے دکھتے ہیں اور مختلف برتاؤ کرتے ہیں: ASA کے عوامی VPN کی طرف رخ کرنے والے پتے تک پہنچنا، IPsec کے ذریعے اندرونی انٹرفیس تک پہنچنا، اور مخصوص انتظامی انٹرفیس تک پہنچنا۔ کسی بھی اجازت کو چھونے سے پہلے منتظم کا ماخذ پتہ، درست منزل کا پتہ اور TCP 22 لکھ لیں۔ آگے کا سب کچھ اسی جوڑے پر منحصر ہے۔

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

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

management-access انٹرفیس کے لیے مخصوص ہے

management-access کمانڈ ASA کو کہتی ہے کہ VPN کے ذریعے آنے والے انتظامی کنکشنز کو نامزد انٹرفیس پر قبول کرے۔ یہ راستہ نہیں بناتی، SSH اجازت نہیں جوڑتی، اور بیک وقت ہر انٹرفیس پر لاگو نہیں ہوتی۔ اگر منزل کا انٹرفیس نامزد نہ ہو تو کنکشن تصدیق سے پہلے ہی خارج کر دیا جاتا ہے۔

یہاں دو استثنائیں کاٹتی ہیں۔ صرف انتظام کے لیے انٹرفیس اس طریقہ کار سے باہر ہیں، اور ASA 9.20 انتظامی رہنما نوٹ کرتا ہے کہ ڈیفالٹ CiscoSSH اسٹیک VPN کے ذریعے انٹرفیس کے پار SSH کی حمایت نہیں کرتا جبکہ ASA SSH اسٹیک کرتا ہے۔ راستوں پر وقت صرف کرنے سے پہلے تعینات ورژن پر فعال اسٹیک کی تصدیق کریں۔

لاگ ان پرامپٹ سے پہلے چار دروازے

کلائنٹ اور صارف نام کے پرامپٹ کے درمیان چار خودمختار دروازے ہیں: انتظامی جوڑے کے لیے راستہ اور سرنگ کی مطابقت، ASA پتے تک TCP 22 کی اجازت دینے والا انٹرفیس ACL، منتظم کے ماخذ کو ڈھانپنے والی ssh اجازت، اور اس صارف کے لیے AAA تصدیق۔ ان میں سے ہر ایک کلائنٹ کو بتائے بغیر پیکٹ گرا سکتا ہے کہ کون سا دروازہ بند ہوا۔

کچھ بھی بدلنے سے پہلے یہ دیکھنے کے لیے packet-tracer استعمال کریں کہ کون سا دروازہ ناکام ہوتا ہے: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed۔ ٹریس ACL، NAT مرحلہ اور to-the-box فیصلہ بتاتا ہے، جو عام طور پر روٹنگ مسئلے کو داخلے کے مسئلے سے الگ کرنے کے لیے کافی ہوتا ہے۔

تنگ اجازت لکھیں، کشادہ نہیں

اجازت کو منظور شدہ انتظامی سب نیٹ اور سرنگ کی ٹریفک وصول کرنے والے انٹرفیس تک محدود کریں: ssh 10.10.5.0 255.255.255.0 inside۔ بیرونی انٹرفیس پر ہر ماخذ کھولنے کے بجائے اسے aaa authentication ssh console LOCAL جیسے تصدیقی طریقے اور نامزد مقامی اکاؤنٹ کے ساتھ جوڑیں۔

انٹرفیس ACL اور ssh اجازت کو ہم آہنگ رکھیں۔ جس سب نیٹ کو ACL روکتا ہے اس کے لیے اجازت پھر بھی ناکام ہوتی ہے، اور ملتی جلتی ssh اندراج کے بغیر سب نیٹ کی اجازت دینے والا ACL اگلے دروازے پر ناکام ہوتا ہے۔ دونوں بیانات ایک ہی راستے کو مختلف تہوں سے بیان کرتے ہیں، اس لیے چلتی ہوئی تشکیل میں انہیں اکٹھے دیکھیں۔

نامزد ہوسٹ سے تصدیق کریں، پھر دوبارہ تنگ کریں

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

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