VPN প্রদানকারী বদলানো: শুধু IP নয়, হোস্টনেম পরিকল্পনা করুন
নতুন DNS রেকর্ড বিদ্যমান সেশন সরায় না। নামটি কে নিয়ন্ত্রণ করে, প্রতিটি ক্লায়েন্ট কখন তা রিজলভ করে এবং পুরোনো এন্ডপয়েন্ট কীভাবে অবসর দেবেন তা পরিকল্পনা করুন।
আপনার DNS রেকর্ড ঠিক আছে, প্রতিস্থাপনটি সুস্থ আছে, তবুও কিছু ক্লায়েন্ট ঘণ্টার পর ঘণ্টা পুরোনো ঠিকানাতেই ডায়াল করে। কয়েকটি এমন নামের বিরুদ্ধে সঙ্গে সঙ্গে ব্যর্থ হয় যা রিজলভ হয় কিন্তু কখনো উত্তর দেয় না। দুটি ফলই একই ফাঁক থেকে আসে: হোস্টনেম বদলায় ক্লায়েন্ট কী খোঁজে, কখন খোঁজে তা নয়, আর উত্তর এলে সে কী বিশ্বাস করে তাও নয়।
লক্ষণ: সঠিক রেকর্ড, পুরোনো টানেল
নাম সংরক্ষণ করা প্রোফাইল মানে এমন ক্লায়েন্ট নয় যে তা বারবার রিজলভ করে। অধিকাংশই একবার রিজলভ করে—কনফিগারেশন প্রয়োগের সময় বা টানেল ওঠার সময়—তারপর সেশন শেষ হওয়া পর্যন্ত ওই ঠিকানাই ব্যবহার করে। তার ওপরে লম্বা TTL থাকাই কাটওভারকে DNS সম্পাদনার বদলে পুনঃসংযোগের চারপাশে পরিকল্পনা করার কারণ।
দুটি আচরণই ত্রুটি নয়, আর সেটাই লক্ষণটিকে বিভ্রান্তিকর করে তোলে। ক্লায়েন্ট আগে পাওয়া একটি উত্তরের ভিত্তিতে কাজ করছে, আর সার্ভারের দিকে কিছুই দেখায় না কোন উত্তরটি ছিল। পুনঃসংযোগটি রক্ষণাবেক্ষণ উইন্ডোতে পরিকল্পনা করুন এবং ব্যবহারকারীদের বলুন তারা কী দেখবেন, নইলে উইন্ডোটি টিকিটের উত্তর দিতে ব্যয় করুন। একই রকমের রিপোর্টের সারি স্বাভাবিক ফল।
নামটি কে নিয়ন্ত্রণ করে, আর ক্লায়েন্ট কী যাচাই করে
জোনের নিয়ন্ত্রণ নির্ধারণ করে মাইগ্রেশন কত দ্রুত এগোতে পারে। রেকর্ডটি এমন রেজিস্ট্রারে রাখুন যেখানে আপনি লগইন করতে পারেন, এবং আর কে এটি বদলাতে পারে তা লিখে রাখুন।
বিশ্বাস নামের পিছনে চলে না। TLS-ভিত্তিক ক্লায়েন্ট সার্টিফিকেট পরিচয় বা পিন করা নাম যাচাই করতে পারে, অন্যদিকে WireGuard পিয়ারের পাবলিক কী প্রমাণ করে এবং হোস্টনেম সম্পূর্ণ উপেক্ষা করে। এই পার্থক্যই ঠিক করে DNS সম্পাদনা যথেষ্ট কি না, নাকি প্রতিটি প্রোফাইলের নতুন ফিঙ্গারপ্রিন্ট দরকার। রেকর্ড পরিবর্তন কখনো এমন এন্ডপয়েন্ট অনুমোদন করা উচিত নয় যা কেউ অনুমোদন করেনি।
প্রশাসনিক ও পুনরুদ্ধার অ্যাক্সেস পাবলিক ক্লায়েন্ট নাম থেকে দূরে রাখুন। হোস্টিং অ্যাকাউন্ট হারালে ক্লায়েন্টদের রিডাইরেক্ট করা রেকর্ডটিও হারানো উচিত নয়। পুনরুদ্ধারের পথ এমন জায়গায় রাখুন যা আপনি যে প্রদানকারী ছাড়ছেন তার ওপর নির্ভর করে না।
প্রতিটি ক্লায়েন্ট কখন নামটি আবার পড়ে
রিজলিউশনের সময় প্রতিটি ক্লায়েন্টের নিজস্ব বৈশিষ্ট্য, তাই কাটওভার উইন্ডোর প্রতিশ্রুতি দেওয়ার আগে আপনি সত্যিই যে বাস্তবায়ন সরবরাহ করেন তা যাচাই করুন। wg-quick ইন্টারফেস ওঠার সময় এন্ডপয়েন্ট রিজলভ করে এবং টানেল রিস্টার্ট না হওয়া পর্যন্ত সেই ঠিকানা ধরে রাখে। OpenVPN ক্লায়েন্ট সংযোগের সময় নামটি খোঁজে, আর পুনঃসংযোগে আবার খোঁজে কি না তা তার অপশনের ওপর নির্ভর করে।
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
মোবাইল ক্লায়েন্টই সাধারণত বিস্ময়, কারণ তারা ঘুম বা নেটওয়ার্ক পরিবর্তনের মধ্যেও রিজলভ করা ঠিকানা ধরে রাখতে পারে। A ও AAAA রেকর্ড কেবল তখনই প্রকাশ করুন যখন প্রতিস্থাপনটি দুই পরিবারেই উত্তর দেয়। এক পরিবারে উত্তর দেওয়া ঠিকানা অন্য পরিবার সম্পর্কে কিছুই প্রমাণ করে না, আর মৃত AAAA রেকর্ড প্রতিটি প্রচেষ্টায় একটি টাইমআউট যোগ করে। আপনি যে প্রতিটি ক্লায়েন্ট সমর্থন করেন তার রিজলিউশন আচরণ নথিভুক্ত করুন, তারপর মানুষ যে ডিভাইস সত্যিই ব্যবহার করে সেগুলোতে পরীক্ষা করুন।
পুনঃসংযোগ বেশিরভাগ ক্লায়েন্টে ব্যবহারকারীর কাজ, আর সার্ভার তা জোর করতে পারে না। সেই ধাপটি রক্ষণাবেক্ষণ নোটে রাখুন, সঙ্গে একটি লাইন যে ঘটলে ব্যবহারকারী কী দেখবেন।
প্রমাণের ভিত্তিতে কাটওভার করুন, তারপর পুরোনো এন্ডপয়েন্ট অবসর দিন
স্যুইচের আগে প্রতিস্থাপনে প্রতিটি স্তর প্রমাণ করুন: লিসেনার উত্তর দেয়, ফায়ারওয়াল পোর্টটি পার করে, রুট সঠিক দিকে ফেরে, নামটি নতুন ঠিকানায় রিজলভ হয় এবং পরিচিত পরিচয় গৃহীত হয়। সংযোগ গ্রহণ করা লিসেনার আর হ্যান্ডশেক সম্পূর্ণ করা লিসেনার এক নয়, তাই পোর্ট নয়, হ্যান্ডশেক পরীক্ষা করুন। বর্তমান প্রত্যাহার তালিকা কনফিগারেশনের পাশে রাখুন, কারণ পুনরুদ্ধার করা ব্যাকআপ পিয়ার তালিকাটি আগের মতোই পুনঃতৈরি করে এবং আপনি ইতিমধ্যে বন্ধ করা অ্যাক্সেস আবার খুলে দিত। কোন পরিচয় দিয়ে পরীক্ষা করেছেন তা লিখে রাখুন, কারণ «এটা কাজ করে» এমন প্রমাণ নয় যা কেউ পুনরাবৃত্তি করতে পারে।
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesরূপান্তরের সময় একই পরিচয়ের জন্য দুই এন্ডপয়েন্টেই সংযোগের প্রচেষ্টা লক্ষ্য করুন। যে ক্লায়েন্ট এখনো পুরোনো ঠিকানার বিরুদ্ধে প্রমাণীকরণ করছে সে এমন প্রোফাইল বা ক্যাশ করা উত্তর যা কখনো সরেনি। নির্ধারিত তারিখের পরিকল্পনায় পুরোনো এন্ডপয়েন্ট অবসর দিন, কারণ একটি পরিচয় গ্রহণ করা দুটি সেবা দুটি দরজা খোলা রাখে।
কাটওভার পরীক্ষা হলো নতুন এন্ডপয়েন্ট দিয়ে একটি অ্যাপ্লিকেশন সেশন, পিং নয়। সেই সেশন কাজ করলে এবং পুরোনো এন্ডপয়েন্ট একটি সম্পূর্ণ পুনঃসংযোগ চক্রে কোনো অনুমোদিত প্রচেষ্টা লগ না করলে, স্থানান্তর শেষ।