সাইট-থেকে-সাইট VPN-এ কী লিখে রাখবেন: সিলেক্টর ও পরিসর

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

কনফিগার করা মানে সমঝোতা করা নয়

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

দুটো কলামই রাখুন, যে তারিখে দেখেছেন সেই তারিখসহ। কনফিগার করা সিলেক্টর হলো আপনি যা বুঝিয়েছেন; সমঝোতা করা সিলেক্টর হলো কার্নেল এখন যা প্রয়োগ করছে। যখন দুটি আলাদা হয়, সেই পার্থক্যই রাউটিং বাগের চেয়ে অনেক বেশি বার একটি অপ্রত্যাশিত ব্যর্থতার ব্যাখ্যা দেয়।

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

রুট-ভিত্তিক টানেল ভিন্নভাবে বেছে নেয়

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

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

অনুবাদ একই টেবিলে পড়ে

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

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

ব্যক্তিগত DNS একই জায়গায় পড়ে। এমন নাম যা সংশ্লিষ্ট সাইট থেকে অব্যবহারযোগ্য ঠিকানায় সমাধান হয় তা সাপোর্ট টিকিটসহ একটি নথিভুক্তি ত্রুটি, এবং এর দায় টানেলের উপর চাপানো হবে।

সেবার প্রয়োজনীয়তা সংযুক্ত করুন

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

তারপর নিয়মটি রক্ষণাবেক্ষণকারী নেটওয়ার্ক প্রশাসকের নাম লিখুন। মালিকহীন সিলেক্টর তালিকা চুপচাপ পুরোনো হয়, আর রাত দুটোয় টানেল ভাঙলে পুরোনোকে ভুল থেকে আলাদা করা যায় না। মালিকও সেই ব্যক্তি যিনি নিশ্চিত করতে পারেন পরিবর্তনটি ইচ্ছাকৃত ছিল।

রেকর্ডটিকে পরীক্ষার পরিকল্পনায় রূপ দিন

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

swanctl --list-sas

পাঁচ লাইনের কাঠামো সাধারণত রেকর্ডটি সৎ রাখতে যথেষ্ট। নিচের সংস্করণটি কাটছাঁট ছাড়াই একটি পরিবর্তন টিকিটে ধরে:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

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