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

আসলে তারে কোন IP সংস্করণগুলো আছে তা যাচাই করুন

IPv4 হেডারে 16-বিটের হেডার চেকসাম থাকে, আর IPv6 হেডারে সেরকম কিছুই থাকে না। এই একটি তথ্যই প্রতিটি টানেলের সংখ্যা বদলে দেয়, কারণ IPv6-এর ভিতরে IPv4 এবং IPv4-এর ভিতরে IPv6 মোড়ানো ভিন্ন ভিন্ন নথি তৈরি করে। একটি টানেল একসাথে দুই পরিবারই বহন করতে পারে, সেক্ষেত্রে এক দিকে এমন ফিল্ড থাকতে পারে যা অন্য দিকে নেই। কিছু গণনার আগেই সংস্করণগুলো নিশ্চিত করুন।

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

outer IPv6 | ESP | inner IPv6 | UDP | application data
outer IPv4 | ESP | inner IPv4 | TCP | application data

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

প্রতিটি চেকসাম কী ঢাকে তা যাচাই করুন

পরিধিটাই মানুষ এড়িয়ে যায়, আর এটাই সংখ্যাটিকে অর্থবহ করে। IPv4 হেডার চেকসাম কেবল হেডারটিকে রক্ষা করে, তাই এর পেছনের পেলোড সম্পর্কে এটি কিছুই বলে না। IPv6-এর উপর UDP চেকসাম একটি সিউডো-হেডার এবং UDP হেডার ও পেলোড ঢাকে, অর্থাৎ ডেটাগ্রাম টানেল করা হলে এটি বহনকৃত প্যাকেটের ভিতর পর্যন্ত পৌঁছায়। TCP-এর নিজস্ব চেকসাম আছে যার সিউডো-হেডারের উপর অনুরূপ নির্ভরতা। তিনটিকেই চেকসাম বলা হলেও এগুলো তিনটি ভিন্ন পরিধি।

RFC 791 IPv4 হেডার যাচাই ও প্রতিটি হপে তার পুনর্গণনা নির্ধারণ করে, আর RFC 8200 IPv6-এর উপর উচ্চস্তরের প্রক্রিয়াকরণ নির্ধারণ করে, সিউডো-হেডারসহ। কোনও নথিই বলে না যে VPN প্যাকেটে নির্দিষ্ট সংখ্যক চেকসাম থাকে, কারণ কোনওটিই টানেল বর্ণনা করে না।

tshark -r capture.pcap -Y "ip.proto == 50" -V | grep -i checksum

অখণ্ডতা সুরক্ষা আলাদাভাবে যাচাই করুন

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

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

tshark -r capture.pcap -Y esp -V | grep -iE "integrity|icv"

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

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

sudo tcpdump -ni eth0 -vv -c 5 esp
sudo tcpdump -ni tun0 -vv -c 5

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

বাস্তব ক্যাপচারের সঙ্গে সংখ্যাটি মিলিয়ে দেখুন

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

উত্তর দিকের জন্য পুনরাবৃত্তি করুন, কারণ দুই পরিবার বহনকারী টানেল দিক ও প্রবাহ অনুযায়ী আলাদা হতে পারে। তারপর সংখ্যাটি তার পরিধিসহ বলুন, যেমন এই পর্যবেক্ষণ বিন্দুতে এই ভিতরের প্যাকেটের জন্য তিনটি চেকসাম, সাধারণভাবে VPN প্যাকেটের বৈশিষ্ট্য হিসেবে নয়।

tshark -r capture.pcap -T fields -e ip.checksum -e udp.checksum -e tcp.checksum

সম্পর্কিত নিবন্ধ