একটি VPN কাটওভারকে প্রাইভেট সার্কিট থেকে কী সংরক্ষণ করতে হবে

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

সার্কিটটিকে বৈশিষ্ট্যের তালিকায় পরিণত করুন

প্রথম প্রশ্ন হলো পুরোনো সেবাটি আসলে কী হস্তান্তর করত: ছোট সাবনেটসহ একটি রাউটেড লিংক, নাকি সাইটগুলোর মধ্যে ভাগ করা লেয়ার 2 সেগমেন্ট। এই পার্থক্যই নির্ধারণ করে IP টানেল আদৌ এটি পুনরুৎপাদন করতে পারবে কি না, কারণ টানেল দুটি ঠিকানার মধ্যে প্যাকেট বহন করে এবং ব্রডকাস্ট ডিসকভারি বা ইচ্ছামতো EtherTypes বহন করে না। যে সার্কিট নিজেকে একটি সুইচ পোর্ট হিসেবে উপস্থাপন করত, সেটি /30 উপস্থাপন করা সার্কিট থেকে ভিন্ন মাইগ্রেশন।

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

নতুন পথটি দুই দিকেই রুট করুন

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

ip route get 10.20.0.10

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

আগে থেকেই পরীক্ষা করা রোলব্যাক নিয়ে সুইচ করুন

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

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

সার্কিটটি আসলে যে ট্রাফিক বহন করত, তা দিয়েই গ্রহণ করুন

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

ping -M do -s 1400 -c 3 10.20.0.10

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