WireGuard হ্যান্ডশেক কাজ করে, কিন্তু অফিসের সাবনেট উত্তর দেয় না

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

AllowedIPs একইসঙ্গে একটি অ্যাক্সেস তালিকা ও একটি রাউটিং টেবিল

ক্লায়েন্টে AllowedIPs তালিকাটি ঠিক করে ওই পিয়ারে কী পাঠানো যাবে এবং WireGuard কোন রুট ইনস্টল করবে। যে পিয়ার এন্ট্রিতে কেবল সার্ভারের টানেল ঠিকানা থাকে, সেটি একটি হোস্ট রুট ইনস্টল করে, তাই LAN গন্তব্যগুলো কখনো টানেলে ঢোকে না। LAN প্রিফিক্স যোগ করা প্রথম যে বিষয়টি যাচাই করতে হবে, এবং কপি করা কনফিগারেশনের পরে সবচেয়ে বেশি যে পরিবর্তনটি অনুপস্থিত থাকে সেটিও এটিই। ডিফল্ট রুট পর্যন্ত প্রসারিত পিয়ার আলাদা এক নকশা, এবং এটি ক্লায়েন্টের ইন্টারনেট ট্রাফিকও সরিয়ে নেবে।

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

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

ফরওয়ার্ডিং ও অনুবাদ সার্ভারেই হওয়া উচিত

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

হাতে যোগ করা নিয়ম রিবুটে হারিয়ে যায়, তাই সার্ভার কনফিগারেশনের hook কমান্ড দিয়ে সেগুলো ইন্টারফেসের সঙ্গে বেঁধে দিন। যে নিয়মের সেট তার ইন্টারফেসের চেয়ে বেশি দিন বাঁচে, সেখানেই একটি মেশিন এমন টানেলের জন্য ট্রাফিক অনুবাদ করতে শুরু করে যার আর অস্তিত্ব নেই।

যখন LAN সরে গেল, কিন্তু নিয়ম সরল না

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

iptables -t nat -n -L POSTROUTING
ip -br addr show

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

NAT-এর পেছনের দুটি সাইটের মিলিত হওয়ার জায়গা দরকার

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

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

চারটি পরীক্ষায় স্তরগুলো আলাদা করুন

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

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

যে অনুরোধ পৌঁছায় কিন্তু কোনো উত্তর টানে না, সেটি উত্তরের পথ বা LAN হোস্টের দিকে ইঙ্গিত করে। যে অনুরোধ কখনো পৌঁছায় না, সেটি AllowedIPs বা ক্লায়েন্টের রুটের দিকে ইঙ্গিত করে। এই দুই ফলাফলের জন্য আলাদা সমাধান দরকার, আর ক্যাপচারই তাদের আলাদা করে দেখায়।