OpenVPN রিপ্লে ব্যাকট্র্যাক লগে: লাইনটি কী প্রমাণ করে না

লাইনটি বলে PID_ERR replay-window backtrack occurred, আর সব সার্চ ফলাফল এটিকে হারানো প্যাকেট ও ভাঙা টানেল হিসেবে ব্যাখ্যা করে। Community OpenVPN 2.6 UDP পথে ওই বার্তাটি লেখা হয় যখন রিসিভ ফাংশনটি এখনও ঠিক করছে প্যাকেটটির কী করবে। এটি একটি নতুন সর্বোচ্চ ব্যাকট্র্যাক নথিভুক্ত করে, তারপর একই ফাংশন গ্রহণ বা প্রত্যাখ্যানের আগে দূরত্বকে উইন্ডো ও নথিভুক্ত অবস্থার সঙ্গে মেলায়। লগ লেবেলকে রায় হিসেবে পড়া সেই ভুল যা প্রতিরোধ করতে এই চেকলিস্টটি আছে।

ধাপ এক: লাইনটি কী তা চিহ্নিত করুন

এটি ক্রম-দূরত্ব সম্পর্কে একটি ডায়াগনস্টিক, সংযোগ সম্পর্কে সিদ্ধান্ত নয়। এটি প্যাকেট-ID বাস্তবায়নে সেই বিন্দুতে দেখা যায় যেখানে নতুনভাবে পর্যবেক্ষিত সর্বোচ্চ ব্যাকট্র্যাক নথিভুক্ত হয়। সেই বিন্দুটি গ্রহণ-বা-প্রত্যাখ্যান শাখার আগে অবস্থিত, তাই এটি ঘটানো প্যাকেটও তখনও বিতরণ হতে পারে।

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

ধাপ দুই: ওই প্যাকেটের ফলাফল খুঁজুন

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

ধাপ তিন: পুনঃক্রম বাস্তব কি না তা ঠিক করুন

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

পুনঃসংযোগের সময় কয়েকটি বার্তা অস্বাভাবিক নয়। প্রকৃত অ্যাপ টাইমআউটের সঙ্গে একটানা ধারা তদন্তযোগ্য, আর সেই সমন্বয়টি একটি লেবেল নয়, প্রমাণ।

ধাপ চার: উইন্ডো প্যারামিটার, এবং সেগুলি যা নয়

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

পুরোনো প্রমাণীকৃত প্যাকেট এখনও অবাঞ্ছিত পুনরাবৃত্তি হতে পারে, তাই রিসিভার এই পরীক্ষাগুলি রাখে। বেশি পুনঃক্রম গ্রহণ মানে সেই ঝুঁকির বেশি অংশ গ্রহণ।

mute দিয়ে সতর্কবার্তা নীরব করা আপনি যা দেখেন তা বদলায়, ডেমন যা করে তা নয়। লক্ষ্য যদি পরিচিত ঘটনার সময় আরও শান্ত লগ হয়, তবে এটি বৈধ পরিচালনগত পছন্দ; লক্ষ্য যদি টানেল ঠিক করা হয়, তবে নীরব করা প্রমাণ লুকায়।

mute 20
replay-window 64 15

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

ধাপ পাঁচ: ব্যবহারকারীর কাছে গুরুত্বপূর্ণ পথটি পরীক্ষা করুন

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

প্রতিটি ধাপে আপনি কী মাপলেন তা লিখে রাখুন। এই নথিই পরের রিপোর্টকে আবার ভয়ংকর লাইন থেকে শুরু করে সেখান থেকে বাইরের দিকে কাজ করতে বাধা দেয়।

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