কেন একটি পরিকল্পনা ছাড়া মাল্টিকাস্ট VPN অতিক্রম করে না

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

গ্রুপ ও অ্যাপ্লিকেশন দিয়ে শুরু করুন

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

প্রয়োজনটি সেবা না আবিষ্কার প্রক্রিয়া, তা ঠিক করুন, কারণ এই দুই উত্তরের খরচ এক ক্রম মাত্রায় আলাদা। একটি চায় এমন ঠিকানা যা বদলায় না; অন্যটি চায় ওয়াইড-এরিয়া লিঙ্ক জুড়ে বিস্তৃত ব্রডকাস্ট ডোমেইন এবং তা থেকে যা যা আসে।

লিঙ্ক-লোকাল আবিষ্কার থামার জন্যই তৈরি

RFC 6762-এ বর্ণিত মাল্টিকাস্ট DNS একক লিঙ্কের চারপাশে নকশা করা হয়েছে: কোয়েরি একটি নির্দিষ্ট গ্রুপে যায়, উত্তর একই গ্রুপে পাঠানো হয়, এবং প্রোটোকল প্রতিটি অংশগ্রহণকারী সবার কথা শুনবে বলে নির্ভর করে। রাউটাররা ডিফল্টভাবে সেই ট্র্যাফিক ফরওয়ার্ড করে না, এবং এটি ত্রুটি নয়, নকশার সিদ্ধান্ত। সীমাটি আছে যাতে একটি ভবনের ডিভাইস সহজে অন্য ভবনে নিজেকে ঘোষণা করতে না পারে। যে টানেল গ্রুপটি সর্বত্র বহন করে আবিষ্কার ঠিক করে বলে মনে হয়, সে সমস্ত অ্যাপ্লিকেশনের জন্য সেই সীমা সরিয়ে দিয়েছে, কেবল যে অ্যাপ্লিকেশনের সাহায্য দরকার ছিল তার জন্যই নয়।

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

রাউটেড মাল্টিকাস্টের তিনটি প্রয়োজন

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

উৎসে পৌঁছানোযোগ্যতা হলো দ্বিতীয় অর্ধ। PIM-এর মতো মাল্টিকাস্ট রাউটিং প্রোটোকল বিতরণ বৃক্ষ তৈরি করে উৎসে ফেরার পথটি প্রত্যাশিত কি না যাচাই করে, তাই অন্য দিকে নির্দেশ করা ইউনিকাস্ট রুট গ্রুপ সদস্যপদ সঠিক থাকলেও বৃক্ষটি ভেঙে দেয়। প্রাপকের জন্য রুট বসানো সেই যাচাইয়ের জন্য কিছুই করে না, এবং এই ভুলটিই কাজ করা পিং ও ব্যর্থ স্ট্রিম তৈরি করে। আগে উৎসের ফেরার পথ যাচাই করুন, তারপর সদস্যপদ যোগ করুন, আর কেবল তারপর অ্যাপ্লিকেশনের দিকে তাকান।

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

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

এক উৎস ও এক প্রাপক দিয়ে প্রমাণ করুন

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

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

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

শুধু সেবা দরকার হলে সেবার ঠিকানা বেছে নিন

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

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