WireGuard কনফিগ লাইন ধরে ধরে পড়ুন, Interface থেকে Peer পর্যন্ত

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

Interface কী এই মেশিনকে বর্ণনা করে

interface ব্লক এই প্রান্তের নিজের পরিচয় ধারণ করে। PrivateKey সেই পরিচয় এবং কখনও হোস্ট ছাড়ে না; মিলে যাওয়া পাবলিক কী সেটি থেকেই উদ্ভূত হয় এবং অন্য peer-রা সেটিই তালিকাভুক্ত করে। ListenPort এখানে এই পাশ হ্যান্ডশেক গ্রহণ করে, তাই এক ঠিকানার পিছনে থাকা দুটি ক্লায়েন্টের আলাদা পোর্ট দরকার।

Address হলো টানেল ঠিকানা যেখানে এই হোস্ট উত্তর দেয়, প্রিফিক্স দৈর্ঘ্যসহ লেখা কারণ এটিই তার ব্যবহারের উৎসও। এখানে প্রিফিক্স ভুল হলে হোস্ট কোন গন্তব্যগুলোকে সংযুক্ত মনে করে তা বদলে যায়, ফলে ব্যর্থতা রাউটিংয়ের মতো দেখায়, কনফিগের মতো নয়।

একটি বাস্তব ক্লায়েন্টসহ [Interface] ব্লকে বাকি সব সাধারণত যোগ করে wg-quick: DNS, MTU, Table, এবং হুক লাইনগুলো। এগুলো প্রোটোকল ক্ষেত্র নয়, এবং খালি wg সেটআপ এগুলো সম্পূর্ণ উপেক্ষা করে।

প্রতিটি peer এন্ট্রি অন্য একটি পক্ষকে বর্ণনা করে

একটি [Peer] ব্লক হলো দূরের পক্ষ। PublicKey সেই পক্ষের উদ্ভূত কী, কখনও তাদের প্রাইভেট কী নয়, এবং PresharedKey একটি ঐচ্ছিক অতিরিক্ত গোপন তথ্য যা দুই পক্ষকে একইভাবে রাখতে হবে। Endpoint হলো কোথায় পাঠাতে হবে, এবং PersistentKeepalive এই হোস্টকে বলে বিরতির পরে একটি প্যাকেট পাঠাতে যখন আর কিছু বাইরে যাচ্ছে না।

এখানকার বেশিরভাগ বিভ্রান্তির জন্য দুটি ভুল দায়ী। নিজের প্রাইভেট কী peer ব্লকে কপি করলে দুই প্রান্ত এক পরিচয় ভাগ করে, আর হ্যান্ডশেক এমনভাবে ব্যর্থ হয় যা লগে খারাপ দেখায়। Endpoint ক্লায়েন্টে বাদ দেওয়া সাধারণত ইচ্ছাকৃত, কারণ সার্ভার আগত হ্যান্ডশেক থেকে ঠিকানাটি শেখে; যে সার্ভারকে শুরু করতে হবে সেখানে এটি বাদ দেওয়া তা নয়। এটাও মনে রাখুন যে keepalive একটি NAT ম্যাপিং খোলা রাখে, এবং এটি থ্রুপুট বাড়ায় না বা লেটেন্সি কমায় না, তাই ট্রাফিক ইতিমধ্যে চললে ত্রিশ সেকেন্ডের বাড়তি প্যাকেট কিছুই কেনে না।

AllowedIPs হলো রাউটিং, অনুমতির তালিকা নয়

AllowedIPs হলো WireGuard-এর ক্রিপ্টোকি রাউটিং। বহির্গামী দিকে, এটি গন্তব্যের ভিত্তিতে ঠিক করে কোন peer প্যাকেট পাবে। অন্তর্গামী দিকে, এটি ঠিক করে সেই peer থেকে আসা প্যাকেট তার উৎসের ভিত্তিতে গ্রহণ করা হবে কি না। একই ক্ষেত্র দুটি কাজই করে, তাই এটি অ্যাক্সেস-নিয়ন্ত্রণ তালিকা নয় এবং অনুমোদিত ওয়েবসাইটের তালিকাও নয়।

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

wg-quick প্রোটোকলের চারপাশে কী যোগ করে

wg-quick একই ফাইল পড়ে এবং প্রোটোকল যে নেটওয়ার্ক ধাপগুলো অপারেটিং সিস্টেমের জন্য রেখে দেয় সেগুলো সম্পন্ন করে। এটি interface ঠিকানা নির্ধারণ করে, AllowedIPs থেকে উদ্ভূত রুট যোগ করে, রিজলভার সেটিংস লেখে এবং হুক কমান্ডগুলো ক্রমে চালায়।

এই স্তরটি চিরাচরিত অসমতা ব্যাখ্যা করে। 0.0.0.0/0 এবং একটি DNS লাইনসহ ফাইল ক্লায়েন্টকে ডিফল্ট রুট ও রিজলভার দেয়, আর সার্ভারের ফরওয়ার্ডিং বা NAT নিয়মে কিছুই করে না। সেগুলো সার্ভারের নিজের কনফিগের অন্তর্গত, কোনো ক্লায়েন্ট ফাইল তা দিতে পারে না।

ফাইলের জন্য একজন মালিক রাখুন। SaveConfig চালু থাকার সময় হাতে সম্পাদনা করা মানে পরের বার interface নামলে আপনার সম্পাদনা হারিয়ে যাবে, আর interface আপনাকে বলবে না যে এটি হয়েছে।

ফাইল নয়, প্রয়োগ করা অবস্থা যাচাই করুন

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

লাইভ অবস্থা ও ঠিকানাকরণ একসাথে পড়ুন, তারপর দুটোকেই আপনি যা লিখেছেন তার সাথে তুলনা করুন:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

peer তালিকা খালি হলে interface তার কনফিগ প্রয়োগ না করেই তৈরি হয়েছে। ঠিকানা ও রুট থাকলে কিন্তু কাউন্টার শূন্যে থাকলে, ফাইল লোড হয়েছে এবং হ্যান্ডশেক ব্যর্থ হচ্ছে, যা সেকশন-ক্রমের নয়, কী বা এন্ডপয়েন্টের সমস্যা। সম্পাদনার আগে দুটি দৃশ্য তুলনা করুন, কারণ তাদের মধ্যবর্তী ফাঁকই সাধারণত আসল ত্রুটি।