আপনি কি মনে করেন Pritunl সার্ভারের নাম বদলালে তার এন্ডপয়েন্ট বদলে যায়?

Pritunl সার্ভারের নাম বদলালে কনসোলে একটি লেবেল বদলায়। এটি ক্লায়েন্ট প্রোফাইল যে ঠিকানায় সংযোগ করে তা বদলায় না, এবং কোনো DNS রেকর্ড তৈরি করে না। যে মানটি গুরুত্বপূর্ণ তা হলো হোস্টের পাবলিক অ্যাড্রেস, এবং এটি ঠিকানার মতোই সহজে একটি নাম গ্রহণ করে।

ক্লায়েন্টরা যে নামে সংযোগ করে তা থাকে হোস্টের একটি ক্ষেত্রে

Pritunl হোস্টের পাবলিক অ্যাড্রেস সেটিংয়ের মাধ্যমে এন্ডপয়েন্ট প্রকাশ করে, যা পাবলিক IP ঠিকানা বা DNS নাম—দুটির যেকোনোটি গ্রহণ করে। সেখানে vpn.example.net বসান, তাহলে তৈরি করা প্রোফাইল এবং প্রমাণিত সিঙ্ক ওই নামটি ক্লায়েন্টদের কাছে পৌঁছে দেবে। রেকর্ডটি আগে থেকেই থাকতে হবে এবং VPN ট্রান্সপোর্ট গ্রহণকারী লিসেনারের দিকে নির্দেশ করতে হবে; এই ক্ষেত্রটি একটি গন্তব্য ঘোষণা করে, তা প্রকাশ করে না। সার্ভার অবজেক্টের প্রদর্শিত নাম প্রশাসনিক মেটাডেটা এবং তা কখনো ক্লায়েন্টের সংযোগের প্রচেষ্টায় পৌঁছায় না।

তাই প্রথম পদক্ষেপ কোনো কিছু নাম বদলানো নয়। হোস্ট সেটিংস খুলুন, পাবলিক অ্যাড্রেস বদলান এবং সমর্থিত ইন্টারফেসের মাধ্যমে সংরক্ষণ করুন।

একই রকম দেখতে তিনটি ক্ষেত্র যা এক নয়

লোকাল অ্যাড্রেস Pritunl হোস্টগুলোর মধ্যে প্রতিলিপি ও রাউটিংয়ের কাজ করে। লিংক অ্যাড্রেস বর্ণনা করে সংযুক্ত সার্ভারগুলো একে অপরকে কীভাবে পৌঁছায়। এর কোনোটিই সেই ঠিকানা নয় যেখানে ক্লায়েন্ট সংযোগ করে, এবং পাবলিক নাম এগুলোতে কপি করলে তারা যে টপোলজি বর্ণনা করে তা ভেঙে যায়। পাবলিক IPv6 অ্যাড্রেস নিজস্ব রেকর্ড ও পথসহ আলাদা একটি ক্ষেত্র; IPv4-এর জন্য A রেকর্ড IPv6 পৌঁছানোর সক্ষমতা তৈরি করে না।

একটি DNS নামও কোনো পোর্ট ম্যাপিং বা লিসেনার বহন করে না। যদি সেবাটি 1194 UDP-তে শোনে, নামটি তবুও এমন হোস্টে নির্দেশ করে যা 1194 UDP গ্রহণ করতে হবে। পোর্ট 443-এ থাকা একটি HTTP রিভার্স প্রক্সি যা ওয়েব কনসোল পরিবেশন করে তা VPN ট্রান্সপোর্ট এন্ডপয়েন্ট নয়, যদিও দুটিই একই নাম ভাগ করে নেয়।

টানেলের ভেতরে ডোমেইনভিত্তিক রাউটিং আরেকটি আলাদা স্তর। বাইরের এন্ডপয়েন্টের নামকরণ ক্লায়েন্ট কোন ব্যক্তিগত গন্তব্যে পৌঁছাতে পারে সে সম্পর্কে কিছুই বলে না।

নতুন নামটি ইতিমধ্যে থাকা ক্লায়েন্টদের কাছে পাঠান

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

ওয়েব কনসোল কোনো লোড ব্যালেন্সারের পেছনে থাকলে Pritunl সিঙ্ক পথের জন্য আলাদা সিঙ্ক অ্যাড্রেস সেটিং নথিভুক্ত করে। শুধু দুটিই Pritunl বলে VPN লিসেনারের জন্য কনসোলের হোস্টনাম পুনরায় ব্যবহার করবেন না।

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

একটি বাস্তব সংযোগ দিয়ে পরিবর্তনটি গ্রহণ করুন

রেজল্যুশন সবচেয়ে দুর্বল সম্ভাব্য পরীক্ষা। dig +short vpn.example.net কোনো ঠিকানা ফেরত দিলে তা কেবল প্রমাণ করে একটি রেকর্ড বিদ্যমান।

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

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