OpenVPN কম্প্রেশন: প্রত্যাখ্যান, শুধু গ্রহণ নাকি পূর্ণ LZO?
comp-lzo no কোনো কঠোর প্রত্যাখ্যান নয়। কম্প্রেশন প্রত্যাখ্যান, মাইগ্রেশনের সময় একমুখী গ্রহণ এবং তা ধরে রাখা—তিনটি তুলনা করুন, তারপর দেখুন offload কী করে।
প্রোফাইলের তিনটি লাইন দেখে মনে হয় সবগুলোই কম্প্রেশন বন্ধ করে, অথচ আসলে একটিই তা করে। পার্থক্যটি গুরুত্বপূর্ণ, কারণ আপনি যে সতর্কবার্তাটি চুপ করাতে চান সেটি একটি উপসর্গ, আর নীতিই ঠিক করে প্রতিপক্ষ এখনো কম্প্রেস করতে পারে কি না। একই অক্ষে—অর্থাৎ পরিবর্তনের পর প্রতিটি অপশন কী অনুমোদন করে—তুলনা করলে বেশিরভাগ অস্পষ্টতা দূর হয়। কোনটি চাইবেন তা নির্ভর করে আপনি মাইগ্রেশন করছেন নাকি থিতু হচ্ছেন তার উপর।
কনফিগ ফাইলে একই রকম দেখতে তিনটি নীতি
প্রতিটি অপশন আলাদা প্রশ্নের উত্তর দেয়। allow-compression no কম্প্রেস করা পেলোড সরাসরি প্রত্যাখ্যান করে, allow-compression asym যা আসে তা ডিকম্প্রেস করে এবং যা যায় তা কখনো কম্প্রেস করে না, আর পুরনো comp-lzo no প্রতিপক্ষের push দিয়ে কম্প্রেশন চালু করার জায়গা রাখে। কেবল প্রথমটিই এমন নীতি যা কোনো সার্ভার উপেক্ষা করতে পারে না।
বেছে নেওয়ার আগে তিনটিকে একটি টেবিলে লিখুন, কারণ নামগুলো পর্যালোচককে বিভ্রান্ত করার মতোই কাছাকাছি। এদের দুটি এখনো গৃহীত প্যাকেটে ডিকম্প্রেশন কোড চালায়, আর নিরাপত্তার যুক্তিটি ঠিক সে বিষয়েই। তৃতীয়টি দিক সীমিত করার বদলে সামর্থ্যটিই সরিয়ে দেয়। পরিবর্তনের রেকর্ড যদি বলে কম্প্রেশন নিষ্ক্রিয় করা হয়েছে, তবে ঠিক একটি সারিই সেই বাক্যটি পূরণ করে।
তদন্ত শুরু করা সতর্কবার্তাটি লক্ষ্য নয়। একটি অনুমোদনশীল নীতি রেখে সেটি চুপ করালে পরিচ্ছন্ন লগ পাওয়া যায় আর এক্সপোজার অপরিবর্তিত থাকে।
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
পুরনো LZO অপশনে no মানে কী
অবচিত LZO অপশনে no স্থানীয় পক্ষের জন্য কম্প্রেশন বন্ধ করে, কিন্তু যেখানে নীতি অনুমোদন দেয় সেখানে প্রতিপক্ষকে তা চালু করা থেকে নিষেধ করে না। এই অসামঞ্জস্যই কারণ প্রোফাইলকে কঠোর প্রত্যাখ্যানে সরালে আচরণ এমনভাবে বদলায় যা এক-সার্ভার ল্যাব টেস্ট কখনো ধরতে নাও পারে।
নিরাপত্তার উদ্বেগ শর্তসাপেক্ষ, চূড়ান্ত নয়। যখন কোনো আক্রমণকারী একটি গোপন তথ্যের পাশে নিজের বেছে নেওয়া প্লেইনটেক্সট রাখতে পারে এবং দেখতে পারে কম্প্রেশন কীভাবে এনক্রিপ্টেড ট্রাফিকের আকার বদলায়, তখন একটি তথ্য-চ্যানেল থাকে। LZO থেকে LZ4-এ যাওয়া অ্যালগরিদম ও ফ্রেমিং বদলায়, সেই কৌশলটি নয়।
তাই সৎ প্রশ্নটি হলো আপনি কী অনুমোদন করতে রাজি, কোন অ্যালগরিদম এখন সুপারিশ করা হয় তা নয়। কঠোর প্রত্যাখ্যানই একমাত্র অপশন যা অপর প্রান্তের সহযোগিতার উপর নির্ভর করে না।
শুধু গ্রহণ একটি মাইগ্রেশন অবস্থা, গন্তব্য নয়
অসামঞ্জস্যপূর্ণ গ্রহণ আছে যাতে এক প্রান্ত কম্প্রেস করা বন্ধ করতে পারে, অথচ অন্য প্রান্ত এখনো তা আশা করে। এটি একটি সেতু, আর সেতুর শেষ তারিখ ও মালিক লাগে। কোন পিয়ারগুলো এখনো কম্প্রেসড ট্রাফিক পাঠাচ্ছে তা লিখে রাখুন, কারণ নীতি ঠিক সেই ট্রাফিকই অনুমোদন করে। সেই তালিকা ছাড়া মাইগ্রেশন অবস্থাটি জড়তার কারণে স্থায়ী কনফিগারেশন হয়ে ওঠে।
ক্লায়েন্ট নিজের ফাইল সম্পাদনা করে অসামঞ্জস্যপূর্ণ সার্ভারকে পুরনো ফ্রেমিং ছাড়তে বাধ্য করতে পারে না। push-এর দিক সার্ভারেই ঠিক হয়, তাই সার্ভার কনফিগারেশন ও প্রতি-ক্লায়েন্ট ফাইলগুলোই সেই জায়গা যেখানে মাইগ্রেশন সত্যিই শেষ হয়।
Stub মোড ফ্রেমিং ধরে রাখে কিন্তু কম্প্রেশনের কাজটি এড়িয়ে যায়, আর এগুলো পুরনো অপশনের সরাসরি সমতুল্য নয়। কোনো একটিতে স্থির হওয়ার আগে যে সবচেয়ে পুরনো পিয়ারকে এখনো সমর্থন করতে হয় তার বিরুদ্ধে পরীক্ষা করুন।
কোথায় ডেটা-চ্যানেল offload উত্তরটি বদলায়
ডেটা-চ্যানেল offload প্যাকেট হ্যান্ডলিং কার্নেলে নিয়ে যায়, আর যে প্রোফাইল এখনো কম্প্রেশন ফ্রেমিংয়ের উপর নির্ভর করে তা offload করা পথে নাও খাপ খেতে পারে। ব্যর্থতা সবসময় জোরালো নয়: ক্লায়েন্ট সংযোগ করে, তারপর আপনি যে টানেল পরীক্ষা করেছেন তার থেকে আলাদা আচরণ করে।
পরিবর্তনের আগে ও পরে কোন বাস্তবায়ন সক্রিয় তা যাচাই করুন, কেবল সংযোগ সফল হলো কি না তা নয়। যখন offload পথ কম্প্রেশন ফ্রেমিং প্রত্যাখ্যান করে, তখন কঠোর প্রত্যাখ্যান নীতি ও offload ডিপ্লয়মেন্ট মিলে যায়, কিন্তু অনুমোদনশীল নীতি ও offload ডিপ্লয়মেন্ট মেলে না।
এই সমন্বয়টি আলাদা পরীক্ষার দাবি রাখে, কারণ ঠিক সেখানেই সঠিক দেখতে একটি ফাইল নীরবে ব্যবহারে থাকা ফাইল নয় হয়ে যায়। প্রোফাইলে লিখিত অভিপ্রায়ের সঙ্গে সমঝোতাকৃত অবস্থা তুলনা করুন, কারণ দুটির মধ্যে কেবল একটি লগে দেখা যায়।
একটি নীতি বাছুন, তারপর সমঝোতাকৃত ফলাফল যাচাই করুন
দুই প্রান্তই বদলাতে পারলে কঠোর প্রত্যাখ্যান বাছুন, এখনো না পারলে অসামঞ্জস্যপূর্ণ গ্রহণ, আর পূর্ণ কম্প্রেশন কেবল তখনই যখন বলতে পারেন কেন এক্সপোজারটি গ্রহণযোগ্য। তারপর ফাইল কী বলে তা নয়, কী সমঝোতা হয়েছে তা যাচাই করুন। শান্ত লগ তখনই প্রমাণ যখন তা আপনি যে নীতি ডিপ্লয় করতে চেয়েছিলেন তার সঙ্গে মেলে।
সিদ্ধান্তটি যে প্রোফাইলে প্রযোজ্য তার পাশে রাখুন, তারিখ ও এখনো অব্যাহতিপ্রাপ্ত পিয়ারগুলোসহ। ছয় মাস পর সেই টীকাটিই ইচ্ছাকৃত ব্যতিক্রম আর কেউ তারিখ বলতে না পারা দুর্ঘটনার মধ্যে পার্থক্য। প্রোফাইলের একই রিপোজিটরিতে এটি লিখুন, যাতে পরের সম্পাদক নির্দেশের আগেই কারণটি দেখেন।