mDNS ওয়ারগার্ডের উপর: পিয়ার উত্তর দেওয়ার আগে তিনটি গেট
Avahi-এর প্রয়োজন একটি যোগ্য ইন্টারফেস, গ্রুপের দিকে একটি রুট এবং একটি পিয়ার যা গন্তব্যের মালিক। তিনটি গেট, তিনটি আলাদা পরীক্ষা, এবং কোনো ফ্যান-আউট নেই।
WireGuard ডিভাইসে মাল্টিকাস্ট ফ্ল্যাগ সেট করলে ইন্টারফেসটি ডিসকভারি সফটওয়্যারের জন্য যোগ্য হয়, আর ফ্ল্যাগের কাজ এখানেই শেষ। এটি প্রোটোকলকে বলে না যে গ্রুপ প্যাকেট কোথায় যাবে, এবং একাধিক পিয়ারযুক্ত ডিভাইসে কোনো একটি স্পষ্ট উত্তর থাকে না। চলমান ডেমন আর আবিষ্কৃত সেবার মধ্যে তিনটি আলাদা গেট দাঁড়িয়ে থাকে।
ক্রমান্বয়ে পরীক্ষা করুন, কারণ একটি পাস করা পরেরটি সম্পর্কে কিছুই বলে না।
প্রথম গেট: ফ্ল্যাগ এবং ডেমনের নীতি
একটি লিনাক্স WireGuard ডিভাইস ARP ছাড়া পয়েন্ট-টু-পয়েন্ট লিঙ্ক হিসেবে তৈরি হয়, এবং ডিফল্টভাবে মাল্টিকাস্ট ফ্ল্যাগ বহন করে না। ফ্ল্যাগ যোগ করা একটি স্থানীয় ইন্টারফেস পরিবর্তন, যা ডিভাইস পরিচালনা করে এমন কিছু দ্বারা সম্পন্ন হয়। Avahi-এর এর উপরে নিজস্ব বিশ্বদৃষ্টি আছে, এবং এর ডিফল্ট নীতি পয়েন্ট-টু-পয়েন্ট ইন্টারফেস সম্পূর্ণভাবে এড়িয়ে যায়। তাই একটি প্যাকেটও নড়ার আগে দুটি স্বাধীন যোগ্যতা পরীক্ষা প্রযোজ্য।
তাই ডেমনের একটি স্পষ্ট সিদ্ধান্ত দরকার, শুধু চলমান প্রক্রিয়া নয়। এর নথিভুক্ত নিয়ন্ত্রণগুলির মধ্যে allow-interfaces, deny-interfaces এবং allow-point-to-point রয়েছে, এবং শেষটি মানুষ যে সেটিংটি মিস করে।
নিচের পরীক্ষাগুলি লিঙ্ক ফ্ল্যাগ, মাল্টিকাস্ট রুট এবং ডেমনের কনফিগারেশন আদৌ পার্স হয় কিনা তা জানায়:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkসফলভাবে চালু হওয়া ডেমন আপনার প্রয়োজনীয় ইন্টারফেসে সকেট খুলেছে এমন নয়। সেবার অবস্থা কভারেজের সমান ধরে নেওয়ার বদলে এর কার্যকর কনফিগারেশন পড়ুন।
দ্বিতীয় গেট: গ্রুপের দিকে রুট
দ্বিতীয় গেট সাধারণ রাউটিং। 224.0.0.251-এ পাঠানো প্যাকেট অন্য সবকিছুর মতো ফরওয়ার্ডিং টেবিল অনুসরণ করে, এবং টেবিলটি যদি এটি ফিজিক্যাল LAN ইন্টারফেস দিয়ে পাঠায় তবে কোনো WireGuard কনফিগারেশন তা বদলাবে না। আগে রুট ঠিক করুন, তাহলে তদন্তের বাকি অংশ ছোট হবে। কোনো পিয়ার কী স্পর্শ করার আগে কার্নেল গ্রুপ ঠিকানার জন্য কী রিপোর্ট করে দেখুন।
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
নির্দিষ্ট রুট না থাকলে কার্নেল লিঙ্কের নিজস্ব মাল্টিকাস্ট হ্যান্ডলিংয়ে ফিরে যায়, এজন্য ডিফল্টটি সমতল LAN-এ সঠিক দেখায় এবং একই গ্রুপ ট্র্যাফিক টানেল দিয়ে বের হওয়ার কথা হলেই ভুল দেখায়। ব্যর্থতা প্রেরকের দিক থেকে নীরব: কোয়েরি কোথাও যায়, আর উত্তর কখনো আসে না।
তৃতীয় গেট: WireGuard প্রতি প্যাকেটে একজন পিয়ার বেছে নেয়
WireGuard অনুমোদিত-ঠিকানা সেটে গন্তব্য খুঁজে আউটগোয়িং পিয়ার নির্বাচন করে, এবং লিনাক্স ট্রান্সমিট পথ প্রতি প্যাকেটে একবার সেই অনুসন্ধান করে। ফলাফল একটিই, এবং প্যাকেটটি সেই পিয়ারের জন্য এনক্রিপ্ট হয়। একই গ্রুপ প্রিফিক্স একাধিক পিয়ারের অনুমোদিত তালিকায় উপস্থিত থাকলে সদস্যতা বা প্রতিলিপি তৈরি হয় না; এটি একটি অস্পষ্ট অনুসন্ধান তৈরি করে যা তাদের একজনের কাছে নিষ্পত্তি হয়।
দুই-প্রান্তের নিবেদিত লিঙ্কে এটিই ঠিক যা চান, কারণ ইচ্ছাকৃতভাবে বহন করা গ্রুপ ট্র্যাফিকের জন্য একজনই অভীষ্ট প্রাপক। পাঁচটি পিয়ারযুক্ত ইন্টারফেসে এটি একটি সীমাবদ্ধতা, বৈশিষ্ট্য নয়, এবং সমাধান কোনো একক পিয়ারের কনফিগারেশনে নয়, ডিজাইনে থাকা উচিত।
ফ্যান-আউট ডিজাইনের জন্য স্পষ্ট রিলে, আলাদা লিঙ্ক বা সম্পূর্ণ ভিন্ন ডিসকভারি প্রক্রিয়া দরকার। প্রতিটি ক্লায়েন্ট গেটওয়ে পরীক্ষা করতে পারে বলে দুই-প্রান্তের রেসিপিকে বহু-ক্লায়েন্ট সমাধান হিসেবে প্রকাশ করা — এভাবেই এটি ভুলভাবে স্থাপন করা হয়।
ইনবাউন্ড দিক আলাদাভাবে যাচাই হয়: প্রাপ্ত প্যাকেটের উৎস প্রমাণিত পিয়ারের অনুমোদিত তালিকার মধ্যে পড়তে হবে। সেখানে মাল্টিকাস্ট গন্তব্য যোগ করা প্রেরকের প্রকৃত উৎস মালিকানা প্রতিস্থাপন করে না।
প্রতিফলন একটি সীমানা, সেতু নয়
Avahi-এর রিফ্লেক্টর তার নির্বাচিত ইন্টারফেসগুলির মধ্যে mDNS বার্তা অ্যাপ্লিকেশন স্তরে পুনরুৎপাদন করে। এটি নেটওয়ার্কের মধ্যে ডিসকভারি সীমানা, ইথারনেট ব্রিজ নয় এবং সাধারণ মাল্টিকাস্ট রাউটার নয়। একই নেটওয়ার্কে যুক্ত দুটি রিফ্লেক্টর সহজেই পুনরাবৃত্ত ঘোষণার লুপ তৈরি করবে।
রিফ্লেকশন সেবার নাম ও তাদের মেটাডেটাও অন্য নেটওয়ার্কে হস্তান্তর করে, যা রাউটিং সিদ্ধান্তের মতোই গোপনীয়তার সিদ্ধান্ত। নির্বাচিত ইন্টারফেস সীমিত করুন, এবং ইনস্টল করা সংস্করণ সমর্থন করলে সেবা ফিল্টার ব্যবহার করুন, যাতে কেবল অনুমোদিত ব্যবহারকারীর প্রয়োজনীয় ঘোষণাগুলোই সীমানা পার হয়।
আবিষ্কার ও ব্যবহার আলাদা ফলাফল থাকে। একটি ক্লায়েন্ট এমন সেবার ঘোষণা দেখতে পারে যার বিজ্ঞাপিত ঠিকানা ক্লায়েন্টের অবস্থান থেকে পৌঁছানো যায় না, বা যার পোর্ট তার অ্যাক্সেস নীতি প্রত্যাখ্যান করে। ঘোষণা দেখা দেওয়ার পরে সেবা সংযোগ নিশ্চিত করুন, এবং অ্যাপ্লিকেশন স্থিতিশীল DNS নাম বা স্পষ্ট সার্ভার ঠিকানা সমর্থন করলে লিঙ্ক-লোকাল ডিসকভারি বাড়ানোর বদলে সেটিই পছন্দ করুন। ক্রিপ্টোকী রাউটিংয়ের বর্ণনা এই সবের ভিত্তি যে গন্তব্য-ভিত্তিক পিয়ার নির্বাচন তা কভার করে।