হাবে WireGuard পিয়ার গ্রুপ: সোর্সের মালিকানা ও নীতি

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

দুটি কাজ, আলাদা রাখা

টানেল স্তর একটি সংকীর্ণ প্রশ্নের উত্তর দেয়: এই পিয়ারের কী কি এই ভেতরের সোর্স ঠিকানাটি অনুমোদন করেছে। ফরওয়ার্ডিং স্তর আরও বিস্তৃত প্রশ্নের উত্তর দেয়: এই প্যাকেট কি ওই গন্তব্যের দিকে বেরোতে পারবে। কোনোটিই অন্যটির প্রশ্নের উত্তর দেয় না, এবং কোনোটিই একা সম্পূর্ণ অ্যাক্সেস নীতি নয়।

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

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

প্রতিটি পিয়ারকে কেবল তার নিজের ঠিকানা দিন

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

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

গ্রুপগুলোকে আলাদা করার ফরওয়ার্ড নীতি লিখুন

এখানে গুরুত্বপূর্ণ ট্রাফিক একই টানেল ইন্টারফেসে ঢোকে ও বেরোয়, তাই এটি হোস্টের ইনপুট পথ নয়, ফরওয়ার্ড পথ অতিক্রম করে। নিয়মগুলো হোস্টের মালিক যে ফায়ারওয়াল ম্যানেজারই হোক তার বিদ্যমান ফরওয়ার্ড চেইনে থাকে, এবং সেগুলো পূর্ণ নিয়মসমষ্টি নয়, খণ্ডাংশ।

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

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

ক্রমই ঠিক করে নীতি প্রযোজ্য হবে কি না

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

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

ফাইলের সংখ্যা নয়, ম্যাট্রিক্স পরীক্ষা করুন

প্রত্যাশিত ফলাফলের একটি ছোট ম্যাট্রিক্স তৈরি করুন এবং প্রতিটি ঘর যাচাই করুন। গ্রুপ A থেকে গ্রুপ A কাজ করা উচিত, গ্রুপ B থেকে গ্রুপ B কাজ করা উচিত, আর A থেকে B কাজ করা উচিত নয়, উভয় দিকে এবং আপনি সমর্থন করলে উভয় ঠিকানা পরিবারের জন্য।

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

প্রথম দুটি দেখায় কী কনফিগার করা আছে। ভুল গ্রুপের সদস্যের ping দেখায় আসলে কী ঘটছে। conntrack তালিকা দেখায় পুরোনো প্রবাহ এখনও গ্রহণ করা হচ্ছে কি না, আর এভাবেই বিচ্ছিন্নতার পরিবর্তন চুপচাপ কার্যকর হতে ব্যর্থ হয়।

হাবের হোস্ট সেবা এবং তার পেছনের LAN-এ প্রবেশ আলাদা নীতি সহ আলাদা পথ। ম্যাট্রিক্স কোনটি ঢেকে রাখে তা লিখে রাখুন, কারণ কেবল পিয়ার-থেকে-পিয়ার ট্রাফিক যাচাই করা পরীক্ষা ওদের কোনটি সম্পর্কেই কিছু বলে না।