VPN-এ Ping লস: শতাংশের আগে Echo অনুরোধগুলো দলবদ্ধ করুন

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

ধাপ 1: উৎস ও গন্তব্য অনুযায়ী স্ট্রিম আলাদা করুন

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

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

দলগুলোর সংখ্যাসহ সেগুলো লিখে রাখুন, কারণ পরের ধাপ ঠিক করে কোন উত্তর কোন দলের। তিনটি অনুরোধ আর কোনো মিলে যাওয়া উত্তর না থাকলে সেটি একটি অনুসন্ধান। তিনটি অনুরোধ ও তিনটি উত্তর থাকলে সেটি ভিত্তিরেখা।

ধাপ 2: শনাক্তকারী ও ক্রম অনুযায়ী মিল করুন

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

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

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

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

ধাপ 3: একই সীমানায় টাপল তুলনা করুন

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

গোনা শুরুর আগে সীমানা ঠিক করুন, এবং প্রতিবেদনে তা উল্লেখ করুন যাতে পরের ব্যক্তি দলবদ্ধকরণ পুনরুৎপাদন করতে পারেন। ক্লায়েন্টের দিকে একটি ক্যাপচার আর সার্ভারের দিকে আরেকটি দুটি ভিন্ন সীমানা। প্রত্যেকে উত্তর কোথায় হারিয়ে গেল সে বিষয়ে ভিন্ন প্রশ্নের উত্তর দেয়।

অনূদিত প্রোবের দল অনুবাদ যন্ত্রের নিজের অবস্থাও উত্তরাধিকার করে, যা উত্তরের কখনো না আসার প্রকৃত কারণ হতে পারে। তার ওপারের পথকে দোষ দেওয়ার আগে ওই অবস্থা পরীক্ষা করুন।

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

ধাপ 4: ক্যাপচার কী প্রমাণ করতে পারে আর পারে না তা বলুন

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

গণনার পাশে ক্যাপচারের স্থান, ফিল্টার এক্সপ্রেশন ও ড্রপ কাউন্টার লিখুন, কারণ সেগুলো ছাড়া কোনো অনুপাত নিরীক্ষা করা যায় না। এই তিনটি লাইনই সংখ্যাটিকে পরে যুক্তিযুক্ত করে।

তারপর পর্যবেক্ষণ যা প্রতিষ্ঠা করে তা যা প্রস্তাব করে থেকে আলাদা করুন, এক নয় দুটি বাক্যে। প্রথম বাক্য গণনা ও সীমানা বলে। দ্বিতীয়টি প্রকল্পনা ও তা কী নিশ্চিত করবে বলে।

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

দল ও পরের সীমানা জানান

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

দলবদ্ধকরণ পুনরুৎপাদনযোগ্য করতে ক্যাপচার ফাইল ও ফিল্টার এক্সপ্রেশন সংযুক্ত করুন। ফাইল ছাড়া সারাংশ একটি দাবি, ফলাফল নয়।

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

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