failback در ASA: چه چیزی واقعا جابه جا می شود وقتی مسیر بازمی گردد
بازگشت مسیر به مسیر اصلی به معنای جابه جایی جریان های قدیمی نیست. uplink، تونل، جدول اتصال ها و نتیجه برنامه را با هم ببینید.
در یک ASA با دو uplink، 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. راهنمای تنظیمات اتصال ASA 9.24 از Cisco آن ها را دو پرسش جدا می بیند و رفتارشان دقیقا همین است. یکی بقای جریان موجود را اداره می کند و دیگری اینکه جریان های جدید چه وقت می توانند از مسیر ترجیحی استفاده کنند.
پیش از تغییر هر یک از این دو، مقادیر مؤثر نسخه خود را بخوانید. کاهش آن ها نشست هایی را می بندد که مردم هنوز از آن استفاده می کنند. افزایش آن ها 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> محدود کنید و ستون رابط را در ورودی های قدیمی و جدید مقایسه کنید. خروجی ها را با مهر زمانی بنویسید، چون ترتیب آن ها همان تشخیص است.
با یک آزمون برنامه تمام کنید: جریانی که از پیش وجود داشت و جریانی که پس از بازگشت مسیر ساخته شد. اگر جریان قدیمی شکست بخورد و جدید کار کند، داستانی درباره وضعیت اتصال دارید. اگر هر دو شکست بخورند، تونل یا سیاست اشتباه است و جدول اتصال ها حواس پرتی است.
آن سابقه را در هر سه مرحله به یک شکل نگه دارید و نسخه دقیق را یادداشت کنید. وقتی خط زمانی همچنان به یک گذار واحد اشاره می کند، سابقه را به پشتیبانی بفرستید نه اینکه شناسه باگ را حدس بزنید.