ASA-তে failback: রুট ফিরে এলে আসলে কী সরে
রুট প্রাইমারিতে ফিরে আসা মানে পুরোনো ফ্লো সরে গেছে নয়। আপলিংক, টানেল, কানেকশন টেবিল ও অ্যাপের ফলাফল একসাথে দেখুন।
দুটি আপলিংকযুক্ত ASA-তে failback কখনো failover-এর উল্টো নয়। পিয়ারের দিকে রুট বদলায়, তারপর প্ল্যাটফর্মকে তিনটি আলাদা স্টেট মেশিন মিলিয়ে নিতে হয়: রুট টেবিল, IKE ও IPsec সিকিউরিটি অ্যাসোসিয়েশন এবং কানেকশন টেবিল। প্রত্যেকটি অন্যগুলোর চেয়ে পিছিয়ে থাকতে পারে, আর সেই পিছিয়ে থাকাই বেশিরভাগ মানুষ টানেল ফিরছে না বলে বর্ণনা করেন।
failback আসলে কী বদলায়
রুট লুকআপ হলো দৃশ্যমান অংশ। ট্র্যাক করা অবজেক্ট পুনরুদ্ধার হলে পিয়ারের বাইরের ঠিকানার ট্র্যাক করা রুট ফিরে আসে, এবং ASA যে পরবর্তী প্যাকেট পাঠায় তা আবার প্রাইমারি লিংক ধরে চলে। এরপর সবকিছু নির্ভর করে বিদ্যমান স্টেট নতুন পথের সাথে মিলছে কি না তার উপর।
ARP ও NAT হলো নীরব নির্ভরতা। নতুন নেক্সট হপের জন্য দরকার সমাধানযোগ্য গেটওয়ে এবং এমন ট্রান্সলেশন যা এখনো দূর প্রান্তের সাথে মেলে, নইলে 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-র এবং পিয়ার ঠিকানা ভাসিয়ে না রেখে স্থির রাখা ডিজাইনের যুক্তি।
crypto-map ও VTI ডিজাইন এখানে ভিন্নভাবে আচরণ করে, আর Cisco-র 9.24 VTI ডকুমেন্টেশন রুট-ভিত্তিক বিকল্প বর্ণনা করে। ASA রুট-ভিত্তিক VPN চালাতে পারে না — এই পুরোনো সাধারণ দাবি সমর্থিত রিলিজের ক্ষেত্রে সত্য নয়।
প্রমাণ এই ক্রমে পড়ুন
কন্ট্রোল প্লেন দিয়ে শুরু করুন: নির্বাচিত পথের জন্য show route, লিংক স্টেটের জন্য show interface, এবং ট্র্যাক করা অবজেক্টের জন্য SLA মনিটরের কাউন্টার। তারপর show crypto ikev2 sa, বা IKEv1-এর সমতুল্য, পড়ে দেখুন কোন পিয়ার সক্রিয়, এরপর সুরক্ষিত ফ্লোর জন্য show crypto ipsec sa। এরপর show conn address <host> দিয়ে কানেকশন টেবিল সংকুচিত করুন এবং পুরোনো ও নতুন এন্ট্রিতে ইন্টারফেস কলাম মিলিয়ে দেখুন। আউটপুটগুলো টাইমস্ট্যাম্পসহ লিখে রাখুন, কারণ তাদের ক্রমই নির্ণয়।
অ্যাপ্লিকেশন পরীক্ষা দিয়ে শেষ করুন: একটি ফ্লো যা আগেই ছিল, আরেকটি যা রুট ফেরার পর তৈরি হয়েছে। পুরোনো ফ্লো ব্যর্থ হয়ে নতুনটি কাজ করলে আপনার কাছে কানেকশন-স্টেটের গল্প আছে। দুটোই ব্যর্থ হলে টানেল বা পলিসি ভুল, আর কানেকশন টেবিল কেবল বিভ্রান্তি।
তিনটি ধাপেই সেই রেকর্ড একই আকারে রাখুন এবং সঠিক রিলিজ লিখে রাখুন। সময়রেখা যখন বারবার একটিমাত্র পরিবর্তনের দিকে ইশারা করে, তখন বাগ আইডি আন্দাজ করার বদলে রেকর্ডটি সাপোর্টে পাঠান।