কেবল এনক্রিপশন কেন পুনরায় পাঠানো প্যাকেট থামায় না

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

প্রক্রিয়াটি ছোট, আর এর ব্যর্থতার ধরনগুলো প্যাকেট হারানোর সঙ্গে গুলিয়ে ফেলা সহজ।

বৈধ সাইফারটেক্সট সতেজ সাইফারটেক্সট নয়

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

নিয়মটি বাস্তবায়নে সস্তা ও বলতেও সস্তা: একটি নির্দিষ্ট সুরক্ষিত প্যাকেট একটি নির্দিষ্ট কী-এর অধীনে একবার গ্রহণ করুন। এই ক্ষেত্রের বাকি সবকিছু নির্ভর করে বাস্তবায়ন সেই একবারটি কীভাবে ট্র্যাক করে তার উপর।

পুনরায় পাঠানোর বাদ দেওয়াকে ডিক্রিপশন ব্যর্থতা হিসেবে পড়লে আপনি সম্পূর্ণ ভুল সাবসিস্টেমে তাকাবেন।

একটি ক্রম-সংখ্যা ও একটি উইন্ডো

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

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

ডায়াগনস্টিক কাউন্টার দেখায় আপনি কোন ক্ষেত্রে আছেন। পুনরায় পাঠানোর বাদ দেওয়া সাধারণ ত্রুটি নয়, নির্দিষ্ট কাউন্টার বাড়ায়, আর সেই কাউন্টার পড়াই প্রথম কাজের পর্যবেক্ষণ।

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

অবস্থা কী-এর, হোস্টের নয়

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

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

কিছু বন্ধ করার আগে কারণ নির্ণয় করুন

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

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

যাচাই যা প্রতিশ্রুতি দেয় না

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

সমর্থিত সেটিংসসহ রক্ষণাবেক্ষণ করা সফটওয়্যারই ব্যবহারকারীর হাতে থাকা বাস্তব নিয়ন্ত্রণ। প্যাকেট সামলায় প্রোটোকল; বাকি সব অপারেশনাল সিদ্ধান্ত।