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 تعیناتی ہم آہنگ نہیں ہوتے۔
اس امتزاج کی اپنی الگ جانچ ہونی چاہیے، کیونکہ وہیں صحیح لگنے والی فائل خاموشی سے وہ فائل نہیں ہوتی جو استعمال ہو رہی ہے۔ طے شدہ حالت کا موازنہ پروفائل میں درج نیت سے کریں، کیونکہ دونوں میں سے صرف ایک لاگ میں نظر آتی ہے۔
پالیسی منتخب کریں، پھر طے شدہ نتیجہ کی تصدیق کریں
جب دونوں سرے بدل سکیں تو سخت انکار، جب ابھی نہ سکیں تو غیر متناسب قبولیت، اور مکمل کمپریشن صرف اس وقت منتخب کریں جب آپ بتا سکیں کہ ایکسپوزر کیوں قابل قبول ہے۔ پھر تصدیق کریں کہ کیا طے ہوا، نہ کہ فائل کیا کہتی ہے۔ خاموش لاگ صرف اس وقت ثبوت ہے جب وہ اس پالیسی سے مطابقت رکھتا ہو جسے آپ تعینات کرنا چاہتے تھے۔
فیصلہ اس پروفائل کے ساتھ رکھیں جس پر لاگو ہوتا ہے، تاریخ اور ان ساتھیوں کے ساتھ جنہیں اب بھی استثنا حاصل ہے۔ چھ ماہ بعد وہی نوٹ جان بوجھ کر کی گئی استثنا اور ایسے حادثے کے درمیان فرق ہے جس کی تاریخ کوئی نہیں بتا سکتا۔ اسے اسی ذخیرے میں لکھیں جس میں پروفائل ہے، تاکہ اگلا ایڈیٹر ہدایت سے پہلے وجہ دیکھ لے۔