সাইট VPN কাজ করছে, কিন্তু ASA লগ আসছে না: উৎস ঠিকানাটি যাচাই করুন

ভেতরের হোস্টগুলো দূরবর্তী কালেক্টরে পৌঁছায় এবং তাদের syslog লাইন দেখা যায়। একই সেশন নিয়ে ASA-এর নিজের বার্তাগুলো কখনো আসে না। কালেক্টর বা টানেলে কোনো সমস্যা নেই, আর এটাই বিভ্রান্তিকর। ফায়ারওয়াল এমন উৎস থেকে তার লগ পাঠাচ্ছে, যা রক্ষা করার জন্য টানেল কখনো তৈরি হয়নি।

কী আসে আর কী আসে না

ড্যাশবোর্ডে একই রকম দেখানো দুটি প্রবাহ আলাদা করে শুরু করুন। ফরওয়ার্ড করা ট্রাফিক ASA-এর মধ্য দিয়ে যায়: একটি LAN হোস্ট কালেক্টরে পাঠায়, ASA সেটি টানেল নীতির সঙ্গে মেলায়, সেটি এনক্রিপ্ট করে, এবং কালেক্টর হোস্টের ঠিকানা দেখে। উৎপন্ন ট্রাফিক ASA-এর নিজের ভেতরে শুরু হয়: ডিভাইসটি একটি syslog প্যাকেট তৈরি করে, একটি আউটগোয়িং ইন্টারফেস ও উৎস বেছে নেয়, এবং কেবল তারপর জিজ্ঞাসা করে কোনো টানেল নীতি মেলে কি না। প্রথম প্রবাহ প্রমাণ করে টানেল কাজ করছে, আর দ্বিতীয়টি নিয়ে কিছুই বলে না।

ডিভাইসে বাফার করা ইভেন্টও দূরবর্তী বিতরণের প্রমাণ নয়, কারণ লগটি স্থানীয়ভাবে থাকতে পারে এবং কখনো পাঠানো না হয়ে থাকতে পারে। টানেলকে দোষারোপের আগে কালেক্টরের গ্রহণ কাউন্টার দেখুন, কারণ খালি কাউন্টার আর বাড়তে থাকা কাউন্টার ভিন্ন ফলাফল।

উৎপন্ন বার্তা ফরওয়ার্ড করা ট্রাফিক নয়

ASA যখন প্যাকেট উৎপন্ন করে, তখন সে কোনো LAN হোস্টের প্রক্সি করছে না। উৎসটি আসে আউটগোয়িং ইন্টারফেস থেকে বা স্পষ্ট উৎস সেটিং থেকে, এবং প্যাকেটটি ডিভাইস যেসব কিছু পাঠায় তার মতো একই রুট অনুসন্ধান ও নীতি পরীক্ষায় ঢোকে। এর মানে VPN সিলেক্টরে অবশ্যই সেই ঠিকানা থাকতে হবে যা ASA আসলে ব্যবহার করে, এবং সেটি প্রায়ই তার বাইরের ইন্টারফেস, কোনো ভেতরের সাবনেট নয়।

যদি নীতিটি 10.20.0.0/24 রক্ষা করে এবং ASA তার বাইরের ঠিকানাকে উৎস হিসেবে ব্যবহার করে, তবে লগ প্যাকেটটি হয় এমন কালেক্টরের দিকে খোলা টেক্সটে বেরিয়ে যায় যেখানে পৌঁছানো যায় না, নয়তো ফেলে দেওয়া হয়। কালেক্টরের দিক থেকে দুটি ফলই একই রকম দেখায়। একই যুক্তি ম্যানেজমেন্ট ট্রাফিকেও প্রযোজ্য, তাই management-access একটি আলাদা ডিজাইন সিদ্ধান্ত।

ASA নেটওয়ার্কে কোন উৎস বসায়

অনুমান নয়, পরীক্ষা করে উৎসটি খুঁজে বের করুন। পরীক্ষামূলক বার্তার সময় আউটগোয়িং ইন্টারফেসে ক্যাপচার আসল উৎস ও গন্তব্য দেখায়, আর তা কনফিগারেশনের তিনটি অংশ পড়ার চেয়ে কম সময় নেয়। সেই ঠিকানাটি টানেলের স্থানীয় সিলেক্টরের সঙ্গে মিলিয়ে দেখুন।

কিছু সংস্করণে লগিং উৎসকে একটি ইন্টারফেসে পিন করা যায়, আর আপনার সংস্করণের কমান্ড রেফারেন্সই কর্তৃত্বপূর্ণ সেই অপশন আছে কি না এবং তা কী বদলায়। ভিন্ন Cisco প্ল্যাটফর্মের source-interface কমান্ড ASA-তে স্বয়ংক্রিয়ভাবে বৈধ নয়।

যদি উৎস বদলান, তবে সচেতনভাবে বদলান এবং লিখে রাখুন, কারণ কালেক্টরের ACL এবং syslog-ভিত্তিক যেকোনো সম্পর্ক এর ওপর নির্ভর করে।

সিলেক্টরকে লগ প্রবাহের সঙ্গে মেলান

উৎস জানা হয়ে গেলে তিনটি জিনিস ক্রমে দেখুন: কোন ট্রাফিক গুরুত্বপূর্ণ তা ঠিক করা ক্রিপ্টো ACL বা নীতি-ভিত্তিক সিলেক্টর, প্যাকেট কোথায় যায় তা ঠিক করা রুট, এবং এনক্রিপশনের আগে উৎস পুনর্লিখন করতে পারে এমন যেকোনো NAT নিয়ম। যে প্যাকেট রুটের সঙ্গে মেলে কিন্তু সিলেক্টরের সঙ্গে মেলে না, সেটি টানেল হয় না, আর NAT-এ পুনর্লিখিত প্যাকেট কোনোটির সঙ্গেই না মিলতে পারে।

কালেক্টরের দিকের নিজস্ব চাহিদা আছে: ASA-র উৎসকে অনুমোদন করা একটি ACL, একটি ফেরত রুট, এবং আপনি যে পোর্ট কনফিগার করেছেন সেখানে শোনা একটি সার্ভিস। পরিবহনও এখানে গুরুত্বপূর্ণ, কারণ আংশিকভাবে ব্লক করা পথে TCP ও TLS লগিং UDP থেকে ভিন্নভাবে আচরণ করে। একবারে একটি উপাদান বদলান, নইলে পরের ক্যাপচার কোন বদলটি গুরুত্বপূর্ণ ছিল তা বলবে না।

কালেক্টরে যাচাই করুন, তারপর উৎস লিখে রাখুন

বার্তাটি আসছে কি না নিশ্চিত করুন, তারপর ASA যে উৎস ঠিকানা ব্যবহার করেছে, যে সিলেক্টর তা বহন করেছে এবং যে তীব্রতা দিয়ে পরীক্ষা করেছেন তা লিখে রাখুন।

সেই রেকর্ড পরের কালেক্টর ACL পরিবর্তন বা সিলেক্টর সম্পাদনাকে পুনরায় আবিষ্কারের বদলে দুই মিনিটের যাচাইয়ে পরিণত করে। এটি আরও নথিভুক্ত করে দুটি প্রবাহের কোনটি কখনো যাচাই হয়েছিল, আর বেশিরভাগ রানবুকে বাদ পড়ে ঠিক এই অংশটিই। বার্তা এখনো না এলে তীব্রতার সীমা সাময়িকভাবে কমান এবং একটি মাত্র গন্তব্যের বিরুদ্ধে পরীক্ষা করুন।

Cisco-র ASA লগিং সম্পর্কিত সাধারণ প্রশ্ন নথিভুক্ত করে একটি বাইরে-উৎসের ক্ষেত্রে যা সংশ্লিষ্ট সুরক্ষিত ট্রাফিক সংজ্ঞা দরকার, এবং এর ভেতরে-উৎসের উদাহরণে ভেতরে একটি লগিং হোস্ট ও ভেতরে management-access, দুটোই আছে। নথিভুক্ত সমন্বয় ও সফটওয়্যার প্রসঙ্গকে একসঙ্গে বিবেচনা করুন, একটি কপি করা লাইন সব কনফিগারেশনে মানানসই বলে ধরে নেবেন না।

LAN ট্রাফিক বহনকারী টানেল ফায়ারওয়ালের নিজের কণ্ঠ বহনকারী টানেল নয়।