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

প্রথমে ক্লায়েন্ট তালিকা ধরে হাঁটুন

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

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

পরিচয় প্রত্যাহার করুন, শুধু ফাইল নয়

দুটি ভিন্ন কাজকেই প্রত্যাহার বলা হয়। WireGuard-এ একটি পিয়ার কেবল তার পাবলিক কী দ্বারাই অনুমোদিত হয়, যা AllowedIPs এন্ট্রিসহ পিয়ার সেকশনে থাকে, তাই ল্যাপটপ থেকে কনফিগ ফাইল মুছে দিলে সার্ভারে কিছুই বদলায় না। পিয়ার ব্লকটি সরান এবং যে পিয়ারগুলো রাখছেন সেগুলো না ফেলে ফাইলটি আবার প্রয়োগ করুন, যেমনটি ব্যাখ্যা করে wg(8) ম্যানুয়াল:

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

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

X.509 সেটআপে প্রত্যাহারের ধাপটি ফাইল নয়, সার্টিফিকেট: openssl ca -revoke client.crt এবং তারপর openssl ca -gencrl -out crl.pem। এর প্রভাব কেবল সেখানেই যেখানে যাচাইকারী এটি পড়ে, অর্থাৎ OpenVPN সার্ভার যেখানে crl-verify কনফিগার করা এবং পরে পুনরায় লোড করা হয়েছে। এই গেটওয়ে যদি সেই CA-এর একমাত্র ব্যবহারকারী হয়, তবে সেটি মরে যাওয়ার দিনই CRL গুরুত্বহীন হয়ে যায়; একই CA যদি দ্বিতীয় গেটওয়ের জন্য সাইন করে, তবে আপনি যে সার্টিফিকেট কখনো প্রত্যাহার করেননি তা সেখানে কাজ করতে থাকে।

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

লিসেনারগুলো এবং সেগুলোর পথ বন্ধ করুন

সেবাটি এমনভাবে থামান যা রিবুটেও টিকে থাকে, তারপর ইউনিট অবস্থার বদলে একটি সকেট তালিকা দিয়ে নিশ্চিত করুন। systemctl disable --now wg-quick@wg0 ইন্টারফেস থামায় এবং wg-quick যে রুট ও নিয়ম যোগ করেছিল তা সরায়; systemctl disable --now openvpn-server@server একটি টেমপ্লেটেড OpenVPN ইনস্ট্যান্সের জন্য একই কাজ করে। যেকোনোটির পরে ss -lunp এবং ss -ltnp চালান। পুরোনো পোর্টের জন্য খালি ফলাফলই একমাত্র প্রমাণ যা গণনা করা যায়।

wg-quick যা যোগ করেছে, wg-quick তা সরায়। আপনি হাতে যা যোগ করেছেন তা থেকে যায়: একটি স্থায়ী NAT নিয়ম, একটি ফায়ারওয়াল অনুমতি, একটি রাউটার পোর্ট-ফরওয়ার্ড, একটি ক্লাউড সিকিউরিটি-গ্রুপ ইনগ্রেস নিয়ম, একটি লোড-ব্যালেন্সার লিসেনার। এগুলো স্পষ্টভাবে সরাতে হবে, এবং DNS রেকর্ডও, অর্থাৎ A, AAAA এবং নামের দিকে থাকা যেকোনো CNAME। মৃত হোস্টে রিজলভ হওয়া নাম না-রিজলভ হওয়া নাম থেকে ভিন্নভাবে ব্যর্থ হয়, আর সেই পার্থক্য কাউকে এক বিকেল খরচ করাবে।

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

পুরোনো এন্ডপয়েন্টের দিকে এখনও যা ইশারা করে তার পিছু নিন

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

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

যাচাই করুন, তারপর লিখে রাখুন

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

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

টিকিট বন্ধ করার আগে:

  • ক্লায়েন্ট প্রোফাইল সরানো বা প্রতিস্থাপিত, অজানা ডিভাইস নিষ্পত্ত
  • পিয়ার সরানো এবং কনফিগ আবার প্রয়োগ, অথবা সার্টিফিকেট প্রত্যাহার ও CRL প্রকাশ
  • ডিরেক্টরি অ্যাকাউন্ট নিষ্ক্রিয়, কেবল স্থানীয় ফাইল মুছেই নয়
  • সেবা নিষ্ক্রিয়, পুরোনো পোর্টে কোনো লিসেনার নেই
  • ফায়ারওয়াল, পোর্ট ফরওয়ার্ড, সিকিউরিটি গ্রুপ ও DNS এন্ট্রি সরানো
  • ব্যাকআপ লেবেলযুক্ত, স্ন্যাপশট পুনরুদ্ধার পথ থেকে বাদ
  • মনিটরিং ও অটোমেশন ক্রেডেনশিয়াল অবসরপ্রাপ্ত

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

সম্পর্কিত নিবন্ধ