সাইট-থেকে-সাইট VPN-এর উপর স্ট্যাটিক রুট, নাকি রাউটিং প্রোটোকল?

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

তিনটি শর্তই সিদ্ধান্ত দেয়

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

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

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

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

স্ট্যাটিক রাউটিং আসলে কত খরচ করে

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

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

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

ডাইনামিক রাউটিং আসলে কত খরচ করে

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

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

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

রাউটিং সেশন কী বলতে পারবে তা নিয়ন্ত্রণ করুন

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

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

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

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

ব্যর্থতার পথ পরীক্ষা করুন, সুখী পথ নয়

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

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

কাজের ক্রম: প্রিফিক্সগুলো গুনুন, ব্যর্থতা কীভাবে শনাক্ত হবে তা ঠিক করুন, কে প্রোটোকল চালাতে পারে তা দেখুন, কী ঘোষণা হবে তা নিয়ন্ত্রণ করুন, তারপর একটি বিভ্রাট শুরু থেকে শেষ পর্যন্ত পরীক্ষা করুন। প্রতিটি ধাপ পরের ধাপের দরকারি একটি তথ্য তৈরি করে।