wg-quick সংযোগে DNS ভেঙে দেয়: সেটআপ ত্রুটি পড়ুন

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

সহায়কটি যে প্রথম বার্তা ছেপেছে সেটি পড়ুন, শেষটি নয়, আর অনুপস্থিত ইউটিলিটি ও অপ্রাপ্য সার্ভারের পার্থক্য স্পষ্ট হয়ে যাবে।

DNS লাইনটি সহায়কের একটি বৈশিষ্ট্য

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

তাই একটি কনফিগারেশন ফাইল প্রোটোকলের জন্য বৈধ হয়েও সেটআপের সময় ব্যর্থ হতে পারে: ব্যর্থতাটি এমন একটি হুকের, যা প্রোটোকল কখনো দেখে না।

মূল কনফিগারেশনে একটি বর্ধিত ক্ষেত্র লিখে প্রোটোকল সরঞ্জাম এটি গ্রহণ করবে বলে আশা করা বিপরীত দিক থেকে একই বিভ্রান্তি তৈরি করে। দুটি পার্সার দুটি আলাদা ফাইল পড়ে।

কোনটি চলছে তা জানা প্রথম ডায়াগনস্টিক ধাপ, এবং এটি সাধারণত কনফিগারেশন ফাইলে নয়, আপনি যে কমান্ডটি টাইপ করেছেন সেখানেই দেখা যায়।

সহায়কটি যে প্রথম ত্রুটি ছাপে সেটি পড়ুন

ইন্টারফেসটি সামনের দিকে তুলুন এবং আউটপুট ক্রমে পড়ুন। অনুপস্থিত রিজলভার ইউটিলিটি, ব্যর্থ হুক এবং অপ্রাপ্য সার্ভার সবাই একই কমান্ডকে আলাদা জায়গায় থামায়, আর প্রতিটির মেরামত আলাদা।

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

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

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

হোস্টের আসলে কোন রিজলভার আছে

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

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

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

সেটআপের মতোই পরিষ্কার করাও জরুরি

ইন্টারফেসটি নামিয়ে আবার রিজলভার অবস্থা দেখুন। যে সহায়ক আগের কনফিগারেশন ফিরিয়ে দেয় সে হোস্টটিকে ব্যবহারযোগ্য রাখে; যে নিজের সার্ভারগুলো পিছনে ফেলে যায় সে পরের ব্যর্থতা তৈরি করে, প্রায়ই কয়েক ঘণ্টা পরে যখন টানেল বহু আগেই চলে গেছে।

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

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