ক্লায়েন্ট আপডেটের পর VPN ভেঙে যায়? নেগোশিয়েশন তুলনা করুন

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

এই বিচ্ছিন্নতার বেশিরভাগের জন্য দুটি প্রক্রিয়া দায়ী। এদের আলাদা করাই আসল কাজ।

আপনার নিচে নেগোশিয়েশনে কী বদলেছে

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

ক্লায়েন্টের ওপর প্রভাব অপ্রতিসম। কন্ট্রোল চ্যানেল ওঠে, প্রমাণীকরণ সফল হয়, আর তারপর টানেলটি মারা যায়—এটি প্রত্যাখ্যাত প্রোফাইলের নয়, বরং নেগোশিয়েশন অমিলের স্বাক্ষর।

সার্ভার নিয়ে তত্ত্ব করার আগে ইনস্টল করা সংস্করণটি পড়ুন। ওই স্ট্রিং একটি স্থানীয় তথ্য, যা আপনি কারও কাছে অ্যাক্সেস না চেয়েই যাচাই করতে পারেন।

প্রোফাইল পার্স হতে পারে, কিন্তু অন্য কিছু বোঝাতে পারে

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

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

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

প্ল্যাটফর্মও একই সময়ে সরেছে

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

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

যে ঘটনা রিপোর্টটি শুরু করেছিল তা আবার পরীক্ষা করুন

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

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