OpenVPN-এ SSM: একটি উৎস ও একটি গ্রুপকে শুরু থেকে শেষ পর্যন্ত অনুসরণ

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

প্রথমে উৎস, গ্রুপ ও প্রাপক নির্ধারণ করুন

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

232/8 পরিসর উৎস-নির্দিষ্ট মাল্টিকাস্টের জন্য সংরক্ষিত, এবং মডেলটি RFC 4607-এ বর্ণিত হয়েছে। আপনি যদি মনে করেন SSM চালাচ্ছেন অথচ আপনার গ্রুপ ওই পরিসরের বাইরে, তাহলে থামুন এবং ডিপ্লয়মেন্ট আসলে কী চায় তা নিশ্চিত করুন, কারণ প্রাপকের যোগদান ও রাউটারের ফরওয়ার্ডিং সিদ্ধান্ত দুটোই মডেলের সামঞ্জস্যের উপর নির্ভর করে।

যাচাই করুন যে প্রাপক উৎসে যোগ দিয়েছে

শুধু গ্রুপের জন্য সদস্যপদ রিপোর্ট উৎস-নির্দিষ্ট যোগদান নয়। প্রাপককে জিজ্ঞেস করুন কোন উৎস চেয়েছিল, এবং প্রথম হপের রাউটারে গ্রুপের অবস্থা দেখে জানুন উৎসের তালিকা দেখা যায় কি না। যদি রিপোর্টে কোনো উৎস না থাকে, রাউটার এটিকে যেকোনো উৎস থেকে যোগদান হিসেবে ধরবে এবং পুরো নকশা নিঃশব্দে এমন কিছুতে ক্ষয়ে যাবে যা আপনি পরিকল্পনা করেননি।

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

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

প্রত্যাশিত উৎসসহ যোগদান থাকলে রাউটারগুলোর দিকে যান। না থাকলে কোনো টানেল কনফিগারেশনই সাহায্য করবে না, কারণ ফরওয়ার্ড করার মতো কিছু নেই।

টানেল দেখার আগে ফেরার পথ যাচাই করুন

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

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

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

কনফিগারেশনের বদলে কার্নেলের মাল্টিকাস্ট অবস্থা পড়ুন

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

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

টানেল আসলে কীভাবে প্রতিলিপি করে তা ঠিক করুন

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

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

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