په ASA کې failback: کله چې لاره بېرته راځي، په رېښتيا څه خوځېږي
د لارې اصلي ته بېرته راتلل دا نه مانا کوي چې پخوانۍ بهېدونکې لارې لېږدېدلې. 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. د 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 اټکل وکړئ.