ASA پر failback: راستہ واپس آنے پر واقعی کیا حرکت کرتا ہے
راستے کا بنیادی راستے پر واپس آنا اس بات کا مطلب نہیں کہ پرانے فلو منتقل ہو گئے۔ uplink، ٹنل، کنکشن جدول اور ایپ کا نتیجہ ایک ساتھ دیکھیں۔
دو uplink والے ASA پر failback، failover کا اُلٹ نہیں ہے۔ peer کی طرف راستہ بدلتا ہے، اور پھر پلیٹ فارم کو تین الگ حالت مشینیں ہم آہنگ کرنی ہوتی ہیں: روٹنگ جدول، IKE اور IPsec سکیورٹی ایسوسی ایشنز، اور کنکشن جدول۔ ہر ایک دوسروں سے پیچھے رہ سکتا ہے، اور یہی تاخیر زیادہ تر لوگ ایسی ٹنل کہتے ہیں جو واپس نہیں آتی۔
failback واقعی کیا بدلتا ہے
راستے کی تلاش نظر آنے والا حصہ ہے۔ جب نگرانی شدہ شے بحال ہوتی ہے، peer کے بیرونی پتے تک نگرانی شدہ راستہ واپس آتا ہے، اور ASA جو اگلا پیکٹ بھیجتا ہے وہ پھر بنیادی لنک سے جاتا ہے۔ اس کے بعد سب کچھ اس پر منحصر ہے کہ موجودہ حالت نئے راستے سے مطابقت رکھتی ہے یا نہیں۔
ARP اور NAT خاموش انحصار ہیں۔ نئے next hop کو قابلِ حل گیٹ وے اور ایسا ترجمہ چاہیے جو اب بھی دور سرے سے مطابقت رکھے، ورنہ failback کے بعد پہلے پیکٹ کہیں نہیں جاتے اور کچھ کام نہ کرنے کے باوجود راستہ ٹھیک دکھتا ہے۔
ایک ہی ٹائم لائن پر چار نظارے
وہی چار چیزیں تبدیلی سے پہلے، دوران اور بعد میں ریکارڈ کریں، کیونکہ ایک اسنیپ شاٹ یہ نہیں بتا سکتا کہ کون سی تہہ ہلی۔
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
جو راستہ کبھی نہیں بدلا اور جو راستہ اس وقت بدلا جب پرانے کنکشن نے اپنی فارورڈنگ حالت برقرار رکھی، دونوں ایک ہی شکایت اور بالکل الگ ثبوت دیتے ہیں۔
پرانے کنکشن بیک اپ راستے پر کیوں رہتے ہیں
راستہ بدلنے کی وجہ سے ASA کوئی فلو نہیں توڑتا۔ قائم شدہ کنکشن وہی فارورڈنگ فیصلہ رکھتے ہیں جس کے ساتھ بنائے گئے، اور پلیٹ فارم اس کے لیے الگ کنٹرول دیتا ہے کہ یہ کتنی دیر تک اجازت ہے: floating-connection timeout اور connection holddown۔ Cisco کی ASA 9.24 کنکشن سیٹنگز گائیڈ انہیں الگ سوالات سمجھتی ہے، اور برتاؤ بھی بالکل ویسا ہی ہے۔ ایک موجودہ فلو کی بقا کو کنٹرول کرتا ہے؛ دوسرا یہ کہ نئے فلو کب ترجیحی راستہ استعمال کر سکتے ہیں۔
ان میں سے کوئی بھی بدلنے سے پہلے اپنی ریلیز کے لیے نافذ اقدار پڑھیں۔ انہیں کم کرنا وہ سیشن بند کر دیتا ہے جو لوگ اب بھی استعمال کر رہے ہیں۔ انہیں بڑھانا failback کو ایسا دکھاتا ہے جیسے کبھی ہوا ہی نہ ہو، کیونکہ نئے کنکشن پوری مدت پرانا راستہ لیتے رہتے ہیں۔
راستہ واپس آنے سے ٹنل دوبارہ کلیدوں پر بات چیت نہیں کرتی
IPsec سکیورٹی ایسوسی ایشنز اپنی طے شدہ عمر رکھتی ہیں اور اس راستے کی تبدیلی سے بچ جاتی ہیں جس نے انہیں اٹھایا تھا۔ اس لیے ٹنل failback کے دوران قائم رہ سکتی ہے جبکہ اس کا بیرونی پتہ اب استعمال ہونے والے راستے سے مطابقت نہیں رکھتا؛ یہی DPD اور peer کے پتے کو تیرنے نہ دینے بلکہ جما دینے والے ڈیزائنوں کے حق میں دلیل ہے۔
crypto-map اور VTI ڈیزائن یہاں مختلف انداز میں برتاؤ کرتے ہیں، اور Cisco کی 9.24 VTI دستاویز راستہ بنیاد پر آپشن بیان کرتی ہے۔ یہ پرانا عام دعویٰ کہ ASA راستہ بنیاد پر VPN نہیں چلا سکتا، معاون ریلیزز کے لیے درست نہیں ہے۔
ثبوت اسی ترتیب میں پڑھیں
کنٹرول پلین سے شروع کریں: منتخب راستے کے لیے show route، لنک کی حالت کے لیے show interface، اور نگرانی شدہ شے کے لیے SLA مانیٹر کے کاؤنٹر۔ پھر show crypto ikev2 sa، یا IKEv1 کا متبادل پڑھ کر دیکھیں کہ کون سا peer زندہ ہے، اس کے بعد محفوظ فلو کے لیے show crypto ipsec sa۔ پھر show conn address <host> سے کنکشن جدول محدود کریں اور پرانے اور نئے اندراجات میں انٹرفیس کالم کا موازنہ کریں۔ آؤٹ پٹ وقت کے ٹکڑوں کے ساتھ لکھیں، کیونکہ ان کی ترتیب ہی تشخیص ہے۔
ایپلیکیشن ٹیسٹ سے مکمل کریں: ایک فلو جو پہلے سے موجود تھا اور ایک جو راستہ واپس آنے کے بعد بنا۔ اگر پرانا فلو ناکام ہو اور نیا کام کرے، تو آپ کے پاس کنکشن حالت کی کہانی ہے۔ اگر دونوں ناکام ہوں تو ٹنل یا پالیسی غلط ہے اور کنکشن جدول توجہ ہٹانے والی چیز ہے۔
وہ ریکارڈ تینوں مرحلوں میں ایک ہی شکل میں رکھیں اور درست ریلیز لکھیں۔ جب ٹائم لائن مسلسل ایک ہی تبدیلی کی طرف اشارہ کرے، تو بگ ID کا اندازہ لگانے کے بجائے ریکارڈ سپورٹ کو بھیجیں۔