WireGuard হ্যান্ডশেক সফল হয়, কিন্তু কোনো উত্তর ফেরত আসে না
সাম্প্রতিক হ্যান্ডশেক প্রমাণ করে কীগুলো কাজ করছে। টানেল, ফার্মওয়্যার বা কীকে দোষ দেওয়ার আগে একটি ভেতরের ঠিকানা অনুসরণ করুন এবং ট্রান্সফার কাউন্টার পড়ুন।
সাম্প্রতিক হ্যান্ডশেক সুসংবাদ, এবং মানুষ যে বাক্যটি লিখতে চায় তার চেয়ে অনেক ছোট একটি দাবি। দুই পক্ষ প্রমাণিত হ্যান্ডশেক বার্তা বিনিময় করেছে। একটি অ্যাপ্লিকেশন প্যাকেটকে তবুও তার ভেতরের গন্তব্যে পৌঁছে ফিরে আসতে হবে।
সুস্থ কন্ট্রোল প্লেন ও নীরব ডেটা প্লেনের মধ্যেকার এই ফাঁকই এখানে পুরো বিষয়। একই কাউন্টারের দুটি পাঠ আপনাকে বলে আপনি তার কোন পাশে আছেন।
হ্যান্ডশেক কী প্রমাণ করে, ডেলিভারি নয়
WireGuard হ্যান্ডশেক হলো প্রমাণীকরণসহ একটি কী চুক্তি। দুই পক্ষ একে অপরের কাছে পৌঁছাতে ও বৈধ কী ধারণ করতে পারলেই এটি সফল হয়। রাউটিং, ফায়ারওয়াল নীতি এবং গন্তব্যটি নিজেই এমন প্রশ্ন যা হ্যান্ডশেক কখনও করে না।
তাই একটি টানেল নিখুঁতভাবে প্রতিষ্ঠিত থাকতে পারে, অথচ তার ভেতরের প্রতিটি প্যাকেট ফেলে দেওয়া হচ্ছে। ভুল রাউট করা ভেতরের প্যাকেট আর অন্য পথে যাওয়া উত্তর ক্লায়েন্টের দিক থেকে একই রকম দেখায়।
একটি ভেতরের ঠিকানাই পুরো পরীক্ষা
একটি গন্তব্য বেছে নিন এবং সেটাতেই থাকুন। অন্য পক্ষের নিজের টানেল ঠিকানাই সবচেয়ে সহজ ক্ষেত্র, আর তার পেছনের একটি হোস্ট ঠিক একটি হপ যোগ করে। পরিবর্তন না লিখে দুটির মধ্যে পালাবদল এমন ফল দেয় যা কেউ তুলনা করতে পারে না।
তারপর ক্লায়েন্ট যে রুট বেছে নেয় তা দেখুন। আরও নির্দিষ্ট কোনো স্থানীয় রুট WireGuard-কে জিজ্ঞাসা করার আগেই প্যাকেটটি অন্যত্র পাঠাতে পারে, আর এটি ঘটে যখনই হোম LAN দূরবর্তী রেঞ্জের সঙ্গে ওভারল্যাপ করে।
ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0
যে ঠিকানা ভৌত ইন্টারফেসে গিয়ে ঠেকে, সে ইতিমধ্যেই প্রশ্নের উত্তর দিয়ে দিয়েছে। টানেল কিছু ফেলছে না। প্যাকেট কখনও তার ভেতরে ঢোকেনি।
কাউন্টার প্রমাণ, রায় নয়
wg show প্রতি পক্ষের পাঠানো ও প্রাপ্ত বাইট জানায়, এবং দুটি সংখ্যা স্বতন্ত্রভাবে নড়ে। একটি পাঠ নিন, একটি অনুমোদিত অনুরোধ করুন, তারপর একই মিনিটের মধ্যে আরেকটি পাঠ নিন।
wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer
পাঠানো বাড়ছে অথচ গ্রহণ স্থির, এটি উত্তরহীন অনুরোধের স্বাক্ষর। এটি বলে না অনুরোধটি ফিল্টার হয়েছিল কি না, গন্তব্যটি বন্ধ ছিল কি না, বা উত্তর অন্য রুটে চলে গিয়েছিল কি না। এগুলো একই উপসর্গ ভাগ করা তিনটি তদন্ত। কোনো কনফিগারেশন বদলানোর আগে সেগুলো আলাদা করুন।
নির্দিষ্ট বাইট সংখ্যাও সফলতার সীমা নয়। কাউন্টারের মান ট্রাফিক অনুসরণ করে, আর একটি সংখ্যাকে সুস্বাস্থ্যের প্রমাণ ধরে নিলে আত্মবিশ্বাসী অর্থহীনতা তৈরি হয়।
অন্য পক্ষ নিজেই ফেরত প্যাকেট যাচাই করে
দূরবর্তী পক্ষ ভেতরের প্যাকেট গ্রহণ করে কেবল তখনই, যখন উৎসটি সেই পক্ষের allowedips-এর ভেতরে পড়ে। প্রেরকের কাছে থাকা একটি রুট যথেষ্ট নয়। গ্রাহকের কাছে উৎসের এন্ট্রি না থাকলে ফেরত ট্রাফিক নীরবে ফেলে দেওয়া হয়।
হোস্ট ফায়ারওয়াল সেই যাচাইয়ের পেছনে থাকে। এমন ফরওয়ার্ড নিয়ম যা টানেল ইন্টারফেসকে অনুমতি দেয় কিন্তু ভেতরের সাবনেটকে নয়, হ্যান্ডশেক গ্রহণ করে প্যাকেট প্রত্যাখ্যান করে। ক্লায়েন্টের দিক থেকে এটি হুবহু মৃত পক্ষের মতো দেখায়। দুটি ইন্টারফেসওয়ালা হোস্টও ভুল উৎস থেকে উত্তর দিতে পারে, আর তখন পক্ষটি এমন উত্তর ফেলে দেয় যা সে কখনও আশা করেনি।
পরীক্ষাটি সৎ রাখুন
যে হোম নেটওয়ার্কে পৌঁছানোর কথা, সেই একই নেটওয়ার্ক থেকে রিমোট-অ্যাক্সেস প্রোফাইল পরীক্ষা করলে অভীষ্ট পথের বদলে অন্য পথ অনুশীলিত হয়। বাইরের নেটওয়ার্কে যান এবং তার স্থানীয় প্রিফিক্স লিখে রাখুন, যাতে দুটি রান তুলনা করা যায়।
ছোট একটি সফল বিনিময়ও সব পথ-সমস্যা বাদ দেয় না। বড় প্যাকেট যেখানে ছোটগুলো পার হয় সেখানে ব্যর্থ হতে পারে, আর আকার বা প্রোটোকল মেলানো ফিল্টার লোডের অধীনে ভিন্ন আচরণ করতে পারে।
হ্যান্ডশেককে জানা-কাজ-করা পর্যায় হিসেবে রাখুন এবং সেখান থেকে এগিয়ে যান। পরবর্তী উপকারী প্রমাণ হলো একটি ভেতরের অনুরোধ কোথায় থামে, নতুন কী-সেট আর আরেক দফা অনুমান নয়।