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

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

বাইন্ডিং কেবল সোর্স ঠিকানা দেয়, তার বেশি কিছু নয়

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

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

টানেলকে তার নিজের টেবিল দিন

wg-quick প্রোফাইল যেখানে বলে সেখানেই রুট ইনস্টল করে। [Interface]-এর অধীনে Table = 40 যোগ করলে সেগুলো মূল টেবিলের বদলে 40 নম্বর টেবিলে চলে যায়। ইন্টারফেসটি তুলুন এবং সেগুলো পৌঁছেছে কি না নিশ্চিত করুন: ip -4 route ls table 40 টানেলের রুট দেখানো উচিত, আর ip -4 route get 10.66.127.142 দেখায় কার্নেল এখনই তার একটি কীভাবে সমাধান করছে। রুটগুলো নিজেদের টেবিলে থাকলে মূল টেবিল বাকি সবকিছুর জন্য কাজ করতে থাকে।

IPv6-এর ক্ষেত্রেও একই কাজ করুন, প্রশস্ত প্রিফিক্স মেলানোর বদলে। ip -6 rule add from fd00::2/128 lookup 40 একটি ঠিকানা পিন করে; fc00::/8 হোস্টের অন্যান্য ইন্টারফেসের সাথে সংঘর্ষে যেতে পারে এবং উদ্দেশ্যের চেয়ে বেশি মেলে এমন নিয়ম তৈরি করতে পারে।

সোর্স নিয়ম যোগ করুন এবং কাউন্টার দেখুন

তারপর দুটি অর্ধকে যুক্ত করুন: ip -4 rule add from 10.66.127.142/32 lookup 40, সেই একই ঠিকানা WireGuard ইন্টারফেসে যুক্ত রেখে। দুটি নিয়মই PostUp-এ রাখুন যাতে পুনরায় সংযোগে সেগুলো ফিরে আসে। কোনো সেটিং নয়, বাস্তব অনুরোধ দিয়ে যাচাই করুন: ip route get 1.1.1.1 from 10.66.127.142 টানেল ডিভাইসের নাম বলা উচিত, আর curl --interface wg0 ifconfig.me হোম ঠিকানার বদলে টানেলের ঠিকানা রিপোর্ট করা উচিত।

তবুও ব্যর্থ হলে ip -s rule পড়ুন। যে নিয়ম আছে কিন্তু কখনও মেলেনি তা শূন্য কাউন্টার দেখায়, আর এটিই ভুল নিয়মকে নিয়ম না থাকা থেকে আলাদা করে। ওই একটি কমান্ড অ্যাপটি তার ইন্টারফেস সেটিং উপেক্ষা করেছে কি না তা নিয়ে অনেক অনুমান বাঁচায়।

উল্টো ক্ষেত্র: SSH-কে টানেলের বাইরে রাখুন

উল্টো সমস্যাটিও সমান সাধারণ: wg-quick ডিফল্ট রুটের মালিক এবং সার্ভারে SSH সেশন মাঝপথে মরে যায়। এর নিয়মগুলো নিম্ন অগ্রাধিকার নম্বরে থাকে, তাই ব্যতিক্রমকে তাদের আগে মূল্যায়ন করতে হয়। সাম্প্রতিক iproute2-এ ip rule add dport 22 ipproto tcp table main priority 123 তা করে; যেখানে সিলেক্টর নেই সেখানে nftables-এ ফ্লো চিহ্নিত করুন এবং বদলে মার্ক মেলান।

প্রত্যুত্তরের পথও দেখুন। যে SSH সেশন প্রতিষ্ঠিত হয়ে পরে চুপ হয়ে যায় তার সাধারণত অসমমিত রাউটিং থাকে: এক দিক টানেল দিয়ে বের হয়, অন্য দিক ফিজিক্যাল ইন্টারফেস দিয়ে। সার্ভার ঠিকানার জন্য ip route get বলে দেয় প্রত্যুত্তর কোন দিকে যাবে।

টেবিল নম্বর, সোর্স নিয়ম ও ব্যতিক্রমটি প্রোফাইলেই লিখে রাখুন। তিনটিই একই নকশার অংশ এবং একসাথে সম্পাদিত হবে।

সম্পর্কিত নিবন্ধ