ASA کی TACACS+ درخواستیں آپ کی برانچ VPN ٹنل سے کیوں گزر نہیں پاتیں

برانچ ٹنل چل رہی ہے، صارفین دور دراز TACACS+ سرور پر تصدیق کر رہے ہیں، اور فائر وال کا اپنا لاگ ان اب بھی وقت ختم ہو کر ناکام ہوتا ہے۔ وجہ ٹنل میں کوئی خرابی نہیں: LAN-to-LAN ٹنل وہی ٹریفک لے جاتی ہے جو اس کے سلیکٹرز سے میل کھاتی ہے، اور ASA جو اپنے بارے میں مینجمنٹ ٹریفک بناتی ہے وہ اپنے ماخذ پتے والا الگ بہاؤ ہے۔ زیادہ تر ٹیمیں یہ تبدیلی کی ونڈو کے دوران دریافت کرتی ہیں، جب واحد منتظم اکاؤنٹ ہی ناکام ہو رہا ہوتا ہے۔ ASA کے شروع کردہ AAA سیشن کو ایسا بہاؤ سمجھیں جسے آپ کو ڈیزائن کرنا ہے، پہلے سے چل رہی کنیکٹیویٹی کا ضمنی اثر نہیں۔

ASA خود کلائنٹ ہے، اور اس کی اپنی ٹریفک کو اپنا راستہ چاہیے

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

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

aaa-server سطر کا انٹرفیس سجاوٹ نہیں ہے

ASA پر aaa-server ہوسٹ اندراج قوسین میں انٹرفیس تعلق لیتا ہے، اور Cisco کا AAA ہوسٹ کمانڈ حوالہ اسے وہ انٹرفیس بتاتا ہے جہاں تصدیق کار سرور موجود ہے۔ یہی تعلق درخواست کو انٹرفیس اور اس پالیسی سے جوڑتا ہے جو وہ انٹرفیس لاگو کرتا ہے۔ اسے انٹرنیٹ کی طرف منہ والے کسی بھی انٹرفیس کے مطابق چننا، یا پچھلی منتقلی سے بچا ہوا ویسے ہی چھوڑ دینا، ایسا ماخذ پتہ بناتا ہے جس کے لیے دور دراز سرور اور ٹنل کبھی بنائے ہی نہیں گئے۔

inside صرف اسی صورت میں درست جواب ہے جب نامزد انٹرفیس کے پاس وہ پتہ ہو جو آپ کا ڈیزائن ماخذ کے طور پر استعمال کرنا چاہتا ہے۔ برانچ ڈیوائس پر ایسا اکثر ہوتا ہے؛ کئی نجی حصوں والی ڈیوائس پر شاید نہ ہو۔

تعلق بدلنے کا مطلب اندراج دوبارہ بنانا ہے

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

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

سلیکٹرز، ترجمہ اور واپسی راستہ اکٹھے جانچیں

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

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

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

خود کو باہر مقفل کیے بغیر تبدیلی کریں

دور دراز انتظامی تصدیق بدلتے وقت کنسول یا خودمختار انتظامی راستہ استعمال کریں، اور نئے راستے کے حقیقی لاگ ان لانے تک منظور شدہ مقامی متبادل رکھیں۔ پھر تنگ پیمانے پر تصدیق کریں: ایک سرور، ایک ڈیوائس، دونوں سروں پر دیکھا گیا ماخذ پتہ کے ساتھ ایک کامیاب تصدیق۔

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