WireGuard কোনও সাম্প্রতিক হ্যান্ডশেক দেখাচ্ছে না: প্রথমে কী পরীক্ষা করবেন

খালি সাম্প্রতিক-হ্যান্ডশেক ফিল্ড সাধারণত বোঝায় ইন্টারফেস ওঠার পর থেকে কোনো হ্যান্ডশেক সম্পন্ন করেনি, যা দেখে মনে হওয়ার চেয়ে কনফিগারেশন সম্পর্কে কম বলে। WireGuard চুপ থাকে যতক্ষণ না কোনো প্যাকেটকে ইন্টারফেস দিয়ে বেরোতে হয়, তাই পাঠানোর কিছু নেই এমন নিষ্ক্রিয় peer ঠিক সেটাই রিপোর্ট করে। কী পরীক্ষা করার আগে সত্যিই কিছু প্রস্তাব করা হয়েছিল কি না তা নিশ্চিত করুন।

পরীক্ষাটি হলো peer-এর বহন করার কথা এমন গন্তব্যের দিকে একটি অনুমোদিত প্যাকেট। ওই স্টেটাস স্ক্রিনের বাকি সবকিছু কার্যকলাপ নয়, অভিপ্রায় বর্ণনা করে।

নিষ্ক্রিয় ইন্টারফেসের রিপোর্ট করার কিছু নেই

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

দুই পাশেই কাউন্টার শূন্যে থাকলে সমস্যা টানেলের উজানে। কিছুই ইন্টারফেসে পৌঁছেনি যা কিছু ট্রিগার করবে।

peer যে ট্রাফিক বহন করতে পারে তা ট্রিগার করুন

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

রুট কুয়েরি ping-এর চেয়ে বেশি গুরুত্বপূর্ণ। যদি এটি ভৌত ইন্টারফেসের নাম বলে, তবে প্যাকেট কখনও টানেলে ঢোকেনি এবং খালি হ্যান্ডশেক রাউটিংয়ের উত্তর, ক্রিপ্টোগ্রাফিক নয়। peer ডিবাগ করার আগে রুট ঠিক করুন।

কী জোড়া ও এন্ডপয়েন্ট তুলনা করুন

ট্রাফিক সত্যিই প্রস্তাবিত হলে পরের পরীক্ষা পরিচয়। স্থানীয় প্রাইভেট কী অবশ্যই অপর পাশ অনুমোদন করা পাবলিক কী-এর সাথে মিলতে হবে, কনফিগার করা রিমোট পাবলিক কী অবশ্যই উদ্দিষ্ট peer চিহ্নিত করবে, এবং কোনো প্রি-শেয়ার্ড কী দুই পাশেই মিলতে হবে। base64 কী-তে এক অক্ষরের পার্থক্য এমন peer তৈরি করে যা কনফিগার করা দেখায় কিন্তু কখনও বিনিময় সম্পন্ন করে না। কী পুনরায় তৈরি না করে প্রভিশনিং রেকর্ডের সাথে তুলনা করুন, কারণ নতুন কী পুরোনোকে বিশ্বাস করা প্রতিটি peer-কে অকার্যকর করে।

এন্ডপয়েন্টেরও একই যাচাই দরকার: হোস্টনেম, ঠিকানা, UDP পোর্ট এবং সেখানে পৌঁছাতে ব্যবহৃত পরিবার। পুরোনো ঠিকানা বা ভুল পোর্ট বার্তার বদলে নীরবতা দেয়।

বাইরের UDP পথ নজরে রাখুন

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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