WireGuard হ্যান্ডশেক কাজ করে, সেবাটি নয়

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

যেটি মেলে না সেখানেই থামুন, এবং বাকিগুলোর জন্য নিয়ম যোগ করবেন না।

হ্যান্ডশেক কেবল টানেলই প্রমাণ করে

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

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

লিসেনার ও রুট পড়ুন

ক্লায়েন্টে নিশ্চিত করুন যে সার্ভারের টানেল ঠিকানা টানেলে রুট হচ্ছে। সার্ভারে নিশ্চিত করুন যে ক্লায়েন্ট যে ঠিকানা ব্যবহার করছে সেখানে একটি সকেট আছে, এবং এর পেছনের প্রক্রিয়াটি আপনার উদ্দিষ্ট প্রক্রিয়া।

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1-এ থাকা লিসেনার কখনও 10.66.0.1-এ পাঠানো অনুরোধের উত্তর দেবে না, ফায়ারওয়াল যাই অনুমতি দিক। ওয়াইল্ডকার্ড ঠিকানার লিসেনার উত্তর দেবে, যদি কোনো নিয়ম তা ব্লক না করে। তাই কোনো নিয়ম দেখার আগেই সকেট তালিকা অর্ধেক ক্ষেত্রে নিষ্পত্তি করে। পোর্ট ও ঠিকানা একসাথে নির্ধারণ করে অনুরোধটি পৌঁছাতে পারবে কিনা।

ক্লায়েন্ট যে ঠিকানা ব্যবহার করে তার সঙ্গে সার্ভার টানেল ইন্টারফেসে প্রকৃতপক্ষে যে ঠিকানা রাখে তার তুলনা করুন। যেকোনো পাশে পুরোনো কনফিগারেশন এমন অনুরোধ তৈরি করে যা সঠিকভাবে এমন পিয়ারের কাছে রুট হয় যার সেই ঠিকানা নেই।

স্থানীয় ইনপুটের জন্য নিয়ম প্রয়োগ করুন, ফরওয়ার্ডিংয়ের জন্য নয়

প্যাকেট এলে এবং সকেট থাকলে, বাকি সীমা হল ইনপুট নীতি। ফরওয়ার্ডিং অনুমোদনকারী নিয়ম স্থানীয় ডেলিভারি অনুমোদন করে না, এবং একটি ইন্টারফেসে সীমাবদ্ধ নিয়ম আপনার প্রত্যাশিত টানেল ইন্টারফেস নামের সঙ্গে নাও মিলতে পারে।

হোস্ট খোলার বদলে উদ্দিষ্ট সেবার একটি অনুমোদিত পোর্ট দিয়ে পরীক্ষা করুন। তারপর অ্যাপ্লিকেশনের নিজস্ব অনুমোদন দেখুন: একটি অনুমোদিত তালিকা, অ্যাকাউন্টের প্রয়োজন বা নির্দিষ্ট হোস্টনামে বাঁধাই নেটওয়ার্ক সফলভাবে পৌঁছানো অনুরোধ প্রত্যাখ্যান করতে পারে।

সার্টিফিকেট যাচাই চালু রাখুন। অপ্রত্যাশিত সার্টিফিকেট পরিচয় কোন হোস্ট উত্তর দিয়েছে তার তথ্য, এড়িয়ে যাওয়ার বাধা নয়। এটি ক্লিক করে পার হলে ভুল সেবা শনাক্ত করার একমাত্র সূত্রটি লুকিয়ে যায়।

নাম, আকার ও পরিচয়ের ব্যর্থতা আলাদা করুন

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

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

কোন চেকপয়েন্ট ব্যর্থ হয়েছে তা লিখে রাখুন: সকেট, ইনপুট নিয়ম বা অ্যাপ্লিকেশন নীতি। এই এক লাইন নেটওয়ার্ক ত্রুটিকে অনুমোদন সিদ্ধান্ত থেকে আলাদা করে। এটি পরবর্তী ব্যক্তিকে এমন পোর্ট খোলা থেকেও বিরত রাখে যা কখনও সমস্যা ছিল না।