VPN ডিক্রিপ্ট করার পরে কোন ASA নিয়ম ট্রাফিক দেখে

প্রথম যে ধারণাটি বাদ দিতে হবে তা হলো, ক্রিপ্টো ACL একটি অ্যাক্সেস নীতি। তা নয়। Cisco ASA-তে ওই তালিকা একটি সংকীর্ণ প্রশ্নের উত্তর দেয়: কোন প্যাকেটগুলো সুরক্ষার যোগ্য, আর সেই উত্তরটি ডিক্রিপ্ট করা প্যাকেট ফায়ারওয়ালের পেছনের সার্ভারে পৌঁছাতে পারবে কি না সে বিষয়ে কিছুই বলে না। অ্যাক্সেসের সিদ্ধান্ত পরে নেওয়া হয় — ইন্টারফেস নীতি, গ্রুপ-পলিসি ফিল্টার, বা দুটোই, টানেল কীভাবে তৈরি হয়েছে তার উপর নির্ভর করে।

ক্রিপ্টো ACL অন্য প্রশ্নের উত্তর দেয়

ক্রিপ্টো ACL একটি ম্যাচ তালিকা। এটি টানেলকে বলে দুই পিয়ারের মধ্যে কী এনক্রিপ্ট করতে হবে; যে প্যাকেট এর সঙ্গে মেলে না তা কেবল সুরক্ষিত থাকে না। এটি প্রশস্ত করলে সুরক্ষার পরিধি বদলায়, আর কিছুই না।

এজন্যই সেখানে একটি সাবনেট যোগ করলে টানেল উঠে আসতে পারে, অথচ প্রকৃত অ্যাপ্লিকেশন তখনও ব্যর্থ হয়। টানেল উঠেছে কারণ এখন একটি ম্যাচ আছে। অ্যাপ্লিকেশন ব্যর্থ হচ্ছে কারণ ওই তালিকায় কিছুই কিছু অনুমোদন করে না। দুটি আলাদা প্রশ্ন, দুটি আলাদা তালিকার উত্তর।

বাইপাস সেটিংটি আসলে কী এড়িয়ে যায়

sysopt connection permit-vpn সুরক্ষিত ট্রাফিককে ইন্টারফেস ACL যাচাই এড়াতে দেয়, যা নাহলে ইনবাউন্ড দিকে প্রযোজ্য হতো। এটি VPN স্থাপনের জন্য একটি সুবিধা, এবং এটি গ্লোবাল। এটি গ্রুপ পলিসি স্পর্শ করে না, এবং প্রতি-ব্যবহারকারী অনুমোদন ফিল্টারও স্পর্শ করে না।

অনুমানের বদলে প্রকৃত মানটি পড়ুন: show running-config all sysopt সেটিংটি ছাপে এমনকি যখন তা কখনও স্পষ্টভাবে কনফিগার করা হয়নি, আর অনেক বিভ্রান্তি ঠিক সেখান থেকেই শুরু হয়।

যেহেতু সেটিংটি গ্লোবাল, একটি ব্যর্থ সাবনেটে দ্রুত পরীক্ষা হিসেবে এটি যাচাই করা খারাপ বিনিময়। ওই ফায়ারওয়ালের প্রতিটি অন্য টানেল ফলাফলটি ভাগ করে নেয়। এটি রোলব্যাক পরিকল্পনাসহ সচেতন পরিবর্তনের জন্য রাখুন।

ডিক্রিপ্ট দিকে ফিল্টারটি পড়ুন

LAN-to-LAN vpn-filter টানেলের দৃষ্টিকোণ থেকে লেখা হয়, ইন্টারফেসের নয়। দূরবর্তী নেটওয়ার্ক উৎসের অবস্থানে যায় এবং স্থানীয় নেটওয়ার্ক গন্তব্যের অবস্থানে, কারণ ডিক্রিপ্টের পরে প্যাকেটটি এমনই দেখায়। এরপর একই ফিল্টার এনক্রিপশনের আগে বিপরীত দিকে আবার মূল্যায়িত হয়, ঠিকানার ভূমিকা উল্টে গিয়ে।

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

কোন ফিল্টারটি আসলে সংযুক্ত তা নিশ্চিত করুন: show running-config group-policy এবং show vpn-sessiondb detail l2l একসঙ্গে বলে দেয় সেশনটি কী উত্তরাধিকারে পেয়েছে। যে ACL-এ কোনো নীতি উল্লেখ করে না তা সম্পাদনা করলে কিছুই বদলায় না।

একটি ACL অবজেক্ট দুটি কাজে পুনরায় ব্যবহার করবেন না

ইন্টারফেসের access-group এবং vpn-filter একই ধরনের অবজেক্ট মনে হয়, কিন্তু ভিন্ন বিন্দুতে ভিন্ন ঠিকানা-অভিমুখে মূল্যায়িত হয়। একটি তালিকা দুটিতেই বরাদ্দ করলে এমন পরিবর্তনের আমন্ত্রণ থাকে যা টানেল ঠিক করে আর ভৌত ইন্টারফেসটি নিঃশব্দে ঢিলে করে দেয়।

এগুলিকে আলাদা রাখুন, তাদের কাজ অনুযায়ী নাম দিন, এবং দিকের পার্থক্যটি নামেই দৃশ্যমান হতে দিন।

নতুন সংযোগ দিয়ে যাচাই করুন, দুই দিকেই

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

ইনস্পেকশনের হিসাবও রাখুন। প্রস্তুতকারকের ডকুমেন্টেশন উল্লেখ করে যে VPN ফিল্টার প্রাথমিক সংযোগ যাচাই করে, ইনস্পেকশন ইঞ্জিন যে প্রতিটি গৌণ সংযোগ খোলে তা নয়, তাই একটি কন্ট্রোল চ্যানেল ও তার সংশ্লিষ্ট মিডিয়া প্রবাহ ভিন্ন ব্যবহার পেতে পারে। অ্যাপ্লিকেশন যদি প্রোটোকল-সচেতন হয়, একটি পোর্ট প্রোবের বদলে প্রকৃত প্রবাহ পরীক্ষা করুন।

প্রশস্ত বাইপাসের পরে ব্যবহারযোগ্য হয়ে ওঠা একটি টানেল বলে সীমাবদ্ধতা সরানো হয়েছে, সেটি পূরণ হয়েছে নয়। যে ফলাফলটি ধরে রাখা মূল্যবান তা হলো একটি নামযুক্ত প্রয়োগ-বিন্দু, যেটি পরবর্তী পর্যালোচনায় দেখাতে পারবেন।