DNS পরিবর্তনের পরেও WireGuard পুরোনো এন্ডপয়েন্টই ব্যবহার করে

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

নামটি একবারই রিজলভ হয়, ক্রমাগত নয়

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

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

রেকর্ডটির সঙ্গে ব্যবহৃত ঠিকানার তুলনা করুন

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

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

এই লাইনগুলো যে show সাবকমান্ড ব্যবহার করে, wg(8) ম্যানুয়াল সেগুলো নথিভুক্ত করে। ঠিকানার পাশাপাশি ঠিকানার ফ্যামিলিও তুলনা করুন, কারণ যে রেকর্ডে IPv6 এন্ট্রি যোগ হয়েছে তা এমন রেকর্ডের চেয়ে আলাদা তুলনা যার IPv4 ঠিকানা বদলেছে। এন্ডপয়েন্ট যদি রেকর্ডের চেয়ে আলাদা হয়, তবে ইন্টারফেস বাসি তথ্যে চলছে আর নামটি কখনোই সমস্যা ছিল না। যদি দুটো মিলে যায় এবং টানেল তবুও ব্যর্থ হয়, তবে প্রোফাইলের বদলে লিসেনার ও নিয়মের দিকে যান।

হ্যান্ডশেকের টাইমস্ট্যাম্প ওই ব্লকে আছে কারণ এন্ডপয়েন্ট একা বলে না পিয়ারটি পৌঁছানো যায় কি না। সঠিক এন্ডপয়েন্টের পাশে বাসি টাইমস্ট্যাম্প মানে পথের সমস্যা, রিজলভিংয়ের সমস্যা নয়, আর এই পার্থক্যই ঠিক করে এরপর আপনি কী ধরবেন।

ইন্টারফেসের ম্যানেজার দিয়ে রিস্টার্ট করুন

এন্ডপয়েন্ট বাসি বলে নিশ্চিত হওয়ার পর, ইন্টারফেসের মালিক যে ব্যবস্থা, তার মাধ্যমেই এটি রিফ্রেশ করুন লাইভ কনফিগারেশন সম্পাদনা করার বদলে। wg-quick দিয়ে চালু করা ইন্টারফেসের জন্য এটি down ও up, systemd ইউনিটের জন্য এটি রিস্টার্ট, আর ম্যানেজারের মালিকানাধীন ইন্টারফেসের জন্য এটি সেই ম্যানেজারেই করা পরিবর্তন, কারণ রানটাইম সম্পাদনা পরের প্রয়োগেই মুছে যায়:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

আগে হ্যান্ডশেক, তারপর ডেটা পথ

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

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