ISP পরিবর্তন করুন সাইট VPN ঠিকানা পুনঃনম্বর না করেই

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

স্বাধীনভাবে চলা দুটি ঠিকানা পরিকল্পনা

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

প্রদানকারী পরিবর্তন বাইরের পরিকল্পনায় ছোঁয়। এটি নিজে থেকে ভেতরের পরিকল্পনা বদলানোর দাবি করে না।

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

বাইরের টানেল ভেতরের কথোপকথন বহন করে

গেটওয়ে-থেকে-গেটওয়ে টানেলে বাইরের IP হেডার দুই গেটওয়েকে ঠিকানা দেয়। ভেতরের হেডার এখনও প্রকৃত অ্যাপ্লিকেশন প্রান্তবিন্দুর নাম উল্লেখ করে। RFC 7296-এর গেটওয়ে-থেকে-গেটওয়ে বর্ণনা এটিকে সাধারণ রাউটিং হিসেবে দেখে যা টানেল প্রান্তবিন্দু দিয়ে ট্রাফিক পৌঁছায়।

এজন্যই গেটওয়ের পাবলিক ঠিকানা বদলালেও শাখা সার্ভার 10.55.8.20 ধরে রাখতে পারে। ভেতরের প্যাকেটে প্রদানকারীর ঠিকানা আদৌ থাকে না।

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

প্রদানকারী সরানোর তবুও একটি চেকলিস্ট আছে

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

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

অন্য সংযুক্ত সাইটের সঙ্গে ঠিকানা ওভারল্যাপ আলাদা পরিকল্পনা সমস্যা। প্রদানকারী পরিবর্তন তা তৈরি করে না, তবে মাইগ্রেশনই সাধারণত সেই সময় যখন তা প্রকাশ পায়।

যা টেকে না: পাবলিক উৎস ও সেশন

স্থিতিশীল প্রাইভেট সার্ভার ঠিকানা স্থিতিশীল পাবলিক উৎস নয়। ব্রাউজিং সরাসরি নতুন প্রদানকারীর মধ্য দিয়ে বেরোলে ওয়েবসাইটগুলো নতুন প্রদানকারী-মুখী ঠিকানা দেখে।

সেই ঠিকানা স্থিতিশীল রাখতে নিজস্ব প্রাপ্যতা ও নীতি সহ সুচিন্তিত ইগ্রেস ডিজাইন দরকার। এটি টানেলের সঙ্গে বিনামূল্যে আসে না।

প্রতিষ্ঠিত সেশনও পথ পরিবর্তন সয় না। টানেল কয়েক সেকেন্ডে পুনঃস্থাপিত হতে পারে এবং তবুও পুরনো পথে বাঁধা দীর্ঘস্থায়ী সংযোগ ভেঙে দিতে পারে। যে সময়ে পুনঃসংযোগ গ্রহণযোগ্য এমন একটি জানালার জন্য কাটওভার পরিকল্পনা করুন। নির্দিষ্ট ক্লায়েন্ট ও তাদের টাইমআউট পরীক্ষা না করে মাইগ্রেশন অদৃশ্য হবে বলে দাবি করবেন না।

চারটি পরীক্ষায় সরানো যাচাই করুন

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

Linux গেটওয়েতে এই তিনটি সেই তালিকার মাঝের অংশ ঢাকে:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

ট্রান্সপোর্ট ঠিকানা একটি তালিকায় আর অ্যাপ্লিকেশন ঠিকানা অন্যটিতে রাখুন। কেবল যে এন্ট্রিগুলো সত্যিই সরে গেছে সেগুলো হালনাগাদ করুন। টানেলের বাইরের ঠিকানা বদলেছে বলে অভ্যন্তরীণ নির্ভরতা পুনঃনম্বর করা এড়ানো যায় এমন কাজ।