একটি WAN ইন্টারফেস কি সাইট-টু-সাইট ও রিমোট VPN দুটোই সামলাতে পারে?

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

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

যেকোনো কনফিগারেশনের আগে দুটি রেকর্ড

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

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

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

কোথায় পিয়ার মিলকরণ ও প্রমাণীকরণ আলাদা হয়

IOS XE-তে IKEv2 প্রোফাইল সেই প্যারামিটারগুলো বহন করে যা দর-কষাকষি করা যায় না, আর সেই শর্তগুলোও যা পিয়ার বাছাই করতে ব্যবহৃত হয়। এর মানে, শাখার দিক ও রোমিংয়ের দিক—দুটোই নিজের প্রোফাইল চায়, এমনকি একই ইন্টারফেসে শেষ হলেও এবং একই ক্রিপ্টো PKI ভাগ করলেও। Cisco প্রোফাইল, প্রমাণীকরণ ও মিলকরণের ভূমিকা লিখেছে তার IOS XE 17-এর জন্য IKEv2 কনফিগারেশন নির্দেশিকায়।

শাখার প্রোফাইল সাধারণত সংকীর্ণ পরিচয়ের সঙ্গে মেলে: একটি দূরের ঠিকানা, একটি FQDN, বা একটি সার্টিফিকেট সাবজেক্ট। match identity remote address 198.51.100.10 255.255.255.255 যুক্ত একটি শর্ত একটি পিয়ারকে পিন করে, আর প্রতি সাইটে সংরক্ষিত চাবিসহ authentication remote pre-share যথেষ্ট। মিলকরণটি পিয়ার তালিকা যতটা অনুমতি দেয় ততটাই নির্দিষ্ট রাখুন, কারণ বাছাই ক্রমে উপরে থাকা একটি ওভারল্যাপ করা ওয়াইল্ডকার্ড শাখার ট্রাফিককে ভুল প্রোফাইলে টেনে নিতে পারে।

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

ফরওয়ার্ডিং ও ট্রান্সলেশনেও একই বিভাজন দরকার

অনুমোদন ও পৌঁছানো আলাদা সমস্যা। সফল IKE ও IPsec বিনিময় প্রমাণ করে দুই পক্ষ চাবিতে একমত; এটি ক্লায়েন্ট যে পুল পেল সেই পুলে কোনো রুট বানায় না। তাই রিমোট-অ্যাক্সেস পুলের ফেরত পথ দরকার—হয় টানেল ইন্টারফেসের দিকে থাকা স্ট্যাটিক রুট, নয়তো এমন রাউটিং প্রোটোকল যা পুলের সারসংক্ষেপ ঢোকায়। শাখার প্রিফিক্স সাধারণত সাইটের বাকি অংশের সঙ্গে একই রাউটিং প্রক্রিয়াতেই আসে।

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

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

যে গ্রহণযোগ্যতা পরীক্ষা ক্রস হওয়া নীতি ধরে ফেলে

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

তারপর কনফিগারেশন নয়, ডেটা প্লেন যাচাই করুন। show crypto ikev2 sa ও show crypto ipsec sa বলে দেয় কোন প্রোফাইল ও কোন সিলেক্টর প্রতিটি ফ্লো বহন করেছে, আর show ip nat translations ও টানেল কাউন্টার দেখায় ফেরত পথ ও অব্যাহতি সত্যিই মিলেছিল কি না। টানেল ইন্টারফেসে ট্রেসার বা প্যাকেট ক্যাপচার চক্রটি বন্ধ করে।

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