দুটি WireGuard peer একটি রেঞ্জ ভাগ করে: প্যাকেটটি কোনটি পায়

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

WireGuard-এর ভিতরে দীর্ঘতম প্রিফিক্স জেতে

প্রতিটি peer এন্ট্রি গন্তব্য প্রিফিক্সের একটি সেট বহন করে। যখন একটি প্যাকেট ইন্টারফেসে রুট হয়, বাস্তবায়নটি সবচেয়ে নির্দিষ্ট মিলে যাওয়া প্রিফিক্সযুক্ত এন্ট্রি খোঁজে — রাউটিং টেবিল যে নিয়ম প্রয়োগ করে সেই একই নিয়ম। তাই /24 তার ভিতরে থাকা /16-কে হারায়, এবং সংকীর্ণ peer ট্রাফিক পায়।

road-warrior সেটআপ এটি ইচ্ছাকৃতভাবে ব্যবহার করে। একটি peer একটি সাইটের জন্য বিস্তৃত রেঞ্জের মালিক, আর পৃথক হোস্টগুলি অন্য peer-দের অধীন /32 এন্ট্রি দিয়ে আলাদা করা হয়। প্যাটার্নটি কাজ করে কারণ কেটে নেওয়া অংশগুলি আরও নির্দিষ্ট, ক্রমের কারণে নয়।

মালিকানা প্রিফিক্স ও peer-এর একটি টেবিল হিসেবে লিখে রাখুন। যদি দুটি এন্ট্রি একই প্রিফিক্স বর্ণনা করে, কনফিগারেশন আর কোনো অভিপ্রায় প্রকাশ করে না, এটি একটি দৌড় প্রকাশ করে।

অপারেটিং সিস্টেম আগে ইন্টারফেস বেছে নেয়

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

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

আগত প্যাকেট উৎস দিয়ে যাচাই করা হয়

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

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

সংকীর্ণ উৎস মালিকানা এটিকে সুবিধায় পরিণত করে। প্রতিটি peer-কে তার নিজের ঠিকানার জন্য /32 দিন, তাহলে নিচের ফায়ারওয়ালের মেলানোর জন্য একটি বিশ্বাসযোগ্য উৎস থাকবে, গোটা গ্রুপের এমন রেঞ্জের বদলে যা যেকোনো সদস্য দাবি করতে পারে।

ডুপ্লিকেট রেঞ্জ failover নয়

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

অসম্পর্কিত ব্যর্থতা ঠিক করতে রেঞ্জ প্রশস্ত করা আরেকটি সাধারণ ভুল। এটি ট্রাফিককে কাজ করা peer থেকে সরিয়ে নেয়, এবং পুরনোটি বোঝার আগেই নতুন উপসর্গ এসে পড়ে।

সম্পাদনার আগে নির্বাচন যাচাই করুন

তিনটি কমান্ড তিনটি প্রশ্নের উত্তর ক্রমানুসারে দেয়। প্রথমটি প্রতিটি peer যে রেঞ্জ দাবি করে তা তালিকাভুক্ত করে। দ্বিতীয়টি দেখায় হোস্ট কোনো গন্তব্যের জন্য কোন ইন্টারফেস ব্যবহার করবে। তৃতীয়টি ট্রাফিক প্রবাহিত হওয়ার পর peer-এর জীবন্ত অবস্থা দেখায়।

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

পরিবর্তনের আগে ও পরে সেগুলি চালিয়ে তুলনা করুন। যদি রুট আউটপুট বদলায় কিন্তু ট্রাফিক এখনও ভুল peer-এ পৌঁছায়, প্রিফিক্স তালিকাগুলি এমনভাবে ওভারল্যাপ করছে যা আপনি এখনও লিখে রাখেননি। যদি রুট আউটপুট না বদলায়, তাহলে peer কনফিগারেশনই কখনও দেখা হয়নি।

টিকিটে গন্তব্য, নির্বাচিত ইন্টারফেস ও নির্বাচিত peer লিখে রাখুন। এই ত্রয়ীই ওভারল্যাপটি পরে পর্যালোচনাযোগ্য করে তোলে, এবং এটি কনফিগারেশনের স্ক্রিনশটের চেয়ে অনেক বেশি কাজে লাগে।