WireGuard ডেটা পাঠায় কিন্তু কিছু ফেরত পায় না: কোন দিক?
বাড়তে থাকা ট্রান্সমিট কাউন্টার একটি দিক, রোগনির্ণয় নয়। কিছু সম্পাদনা করার আগে নির্ধারণ করুন অনুরোধটি কখনও টানেল ছাড়েনি, নাকি উত্তরটি কখনও ফেরেনি।
ট্রান্সমিট কাউন্টার বাড়তে থাকা আর রিসিভ কাউন্টার শূন্যে থাকা একটি দিক নির্দেশ করে, রোগনির্ণয় নয়। একই পাঠ দেখা যায় যখন পিয়ার কখনও হ্যান্ডশেক সম্পন্ন করেনি, যখন গন্তব্য ভুল পিয়ার বেছেছে, যখন দূর প্রান্তের ফেরার কোনো রুট নেই এবং যখন কোনো ফিল্টার ফেরার পথে উত্তরটি ফেলে দেয়। এর প্রতিটি আলাদা জায়গায় মেরামত করা হয়।
যে তুলনা কাজটি ছোট করে তা হলো এমন একটি অনুরোধ যা কখনও টানেল ছাড়েনি এবং এমন একটি উত্তর যা কখনও ফেরেনি। সঠিক ইন্টারফেসে একটি ক্যাপচার তাদের মধ্যে সিদ্ধান্ত দেয়।
কাউন্টার আয়তন বোঝায়, ত্রুটির দিক নয়
WireGuard-এর কাউন্টার লিপিবদ্ধ করে ইন্টারফেস পিয়ারকে কী দিয়েছে এবং তার কাছ থেকে কী পেয়েছে। সেগুলি বলে না কোন গন্তব্য, কোন পিয়ার বা বিনিময়ের কোন অর্ধেক ব্যর্থ হয়েছে। ব্যাকগ্রাউন্ড ট্রাফিক মোটকে আরও কম তথ্যবহুল করে, কারণ কিছু বাইট কীপঅ্যালাইভ বা অসম্পর্কিত প্রবাহ হতে পারে। সেগুলিকে ইন্টারফেস সক্রিয় থাকার সূচক হিসেবে পড়ুন, তারপর প্রমাণ হিসেবে বিবেচনা করা বন্ধ করুন।
উপকারী প্রথম তথ্য হলো হ্যান্ডশেকটি চলতি কি না। এটি ছাড়া এই পিয়ারের জন্য কিছুই এনক্রিপ্ট হয়নি এবং রিসিভ কাউন্টারের নড়ার কোনো কারণ নেই।
পিয়ার নির্বাচন নাকি উত্তরের পথ: দুটি ব্যাখ্যা
প্রথম ব্যাখ্যা হলো প্যাকেটটি কখনও অভীষ্ট পিয়ারে পৌঁছায়নি, কারণ রুটটি অন্যত্র ইঙ্গিত করছিল বা পিয়ারের অনুমোদিত প্রিফিক্সগুলি গন্তব্যকে ঢাকেনি। দ্বিতীয়টি হলো প্যাকেটটি পৌঁছেছে কিন্তু উত্তরটি ফিরতে পারেনি, যা দূর প্রান্তে একটি রাউটিং সমস্যা। সারণিটি প্রতিটি বিন্দুতে আপনি কী পর্যবেক্ষণ করবেন তার ভিত্তিতে সেগুলিকে আলাদা করে।
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
সারণিটি উপরে থেকে পড়ুন। হ্যান্ডশেক অনুপস্থিত থাকলে আপনাকে কী, এন্ডপয়েন্ট এবং বাইরের পথে পাঠায়, কারণ এখনও পরীক্ষা করার মতো আর কিছু নেই। সার্ভারে অনুরোধ দৃশ্যমান থাকা অবস্থায় চলতি হ্যান্ডশেক সমস্যাটিকে ফেরার দিকে সরিয়ে দেয়, যেখানে গন্তব্যের নিজের রুট টেবিল সিদ্ধান্ত নেয়। সার্ভারে কখনও না দেখানো অনুরোধ একটি নির্বাচন সমস্যা, এবং উভয় পিয়ারের অনুমোদিত প্রিফিক্স প্রথমেই তুলনা করার জিনিস।
এই চারটি সারির দুটি ক্লায়েন্টে এবং দুটি সার্ভারে ঠিক করা হয়। আপনি কোন জোড়ায় আছেন তা জানাই কাজের বড় অংশ।
উত্তরগুলি কোথায় হারিয়ে যায়
একটি উত্তর গন্তব্য ছেড়ে সার্ভারের টানেল ইন্টারফেসে পৌঁছায় এবং সেই পিয়ারের জন্য এনক্রিপ্ট করা হয় যার অনুমোদিত ঠিকানাগুলি ক্লায়েন্টের অভ্যন্তরীণ ঠিকানার সঙ্গে মেলে। যদি সেই মিল ব্যর্থ হয়, উত্তরটি নিঃশব্দে বাতিল হয়, যা ক্লায়েন্টের দিক থেকে ঠিক নেটওয়ার্ক ত্রুটির মতো দেখায়। যদি উত্তরটি এনক্রিপ্ট করা থাকে এবং ক্লায়েন্টের নিজের ফিল্টার তা প্রত্যাখ্যান করে, উপসর্গ আবার একই রকম। দুই ক্ষেত্রেই কাউন্টার নয়, ক্যাপচার দরকার।
এই ভুলের সবচেয়ে শক্তিশালী রূপ হলো এমন সার্ভার যা ক্লায়েন্টের জন্য প্যাকেট ফরওয়ার্ড করে কিন্তু ক্লায়েন্টের অভ্যন্তরীণ রেঞ্জে ফেরার কোনো রুট নেই। এটি অনুরোধ গ্রহণ করে, উত্তরটি তার ডিফল্ট গেটওয়ের দিকে পাঠায়, এবং টানেল তা কখনও দেখে না। সার্ভারে যোগ করা একটি বিস্তৃত অনুবাদ নিয়ম রুটটি মেরামত করার বদলে সেই ত্রুটি লুকিয়ে রাখে।
একটি গন্তব্য শুরু থেকে শেষ পর্যন্ত পরীক্ষা করুন
পিয়ারের রেঞ্জের ভিতরে একটি একক গন্তব্য বাছুন, এবং হ্যান্ডশেক স্পষ্টভাবে চলতি থাকা অবস্থায় তা পরীক্ষা করুন। নিচের কমান্ডগুলি পিয়ারের অবস্থা, নির্বাচিত রুট এবং বিনিময়ের উভয় দিক পড়ে। এনক্রিপ্টেড প্যাকেটগুলি প্রকৃতপক্ষে যে ইন্টারফেস ব্যবহার করে সেখানেই ক্যাপচার চালান।
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5টানেল ইন্টারফেসে অনুরোধ দেখিয়ে কিছু ফিরে না আসার ক্যাপচার হলো সার্ভার-দিকের উত্তর, এবং গন্তব্যের রুট টেবিলই পরবর্তীতে দেখার জায়গা। কিছুই না দেখা গেলে প্যাকেটটি অন্য পথ নিয়েছে, তাই স্থানীয় রুটই সন্দেহভাজন। উভয় ক্যাপচারে দৃশ্যমান কিন্তু অ্যাপ্লিকেশনে কোনো অগ্রগতি নেই এমন বিনিময় প্রশ্নটিকে প্যাকেট আকার বা এমন ফিল্টারের দিকে সরায় যা ইন্টারফেস পরিসংখ্যান কখনও দেখায় না। পরীক্ষায় একটি গন্তব্য ও একটি ক্লায়েন্ট রাখুন, কারণ দ্বিতীয় চলক প্রমাণকে আবার ধারণায় ফিরিয়ে দেয়।
যদি নাম ব্যর্থ হয় অথচ অনুমোদিত ঠিকানা কাজ করে, উত্তরটি টানেলে নয়, DNS-এ। যদি কেবল বড় স্থানান্তর আটকে যায়, প্যাকেট আকার আলাদাভাবে পরীক্ষা করুন।