د OpenVPN کلي د OpenSSL 3 وروسته غوښتنه: عرضه کوونکی وګورئ

چا پر پروفایل لاس نه دی اچولی، خو هماغه کلاینټ اوس هربار چې پیل شي د شخصي کلي لپاره د تیریدو عبارت غواړي۔ کله چې دا بدلون د ویشلو د پرمختګ څخه په څو ورځو کې راشي، پرمختګ ښایي لامل وي: OpenSSL 3 خپل د الګوریتم ملاتړ بیا تنظیم کړ، او هغه کلي چې زړې کتابتون په اسانه لوستله کېدای شي پرته له دې چې یو بایټ بدل شي نالوستونکې شي۔ پلټنې په ترتیب سره وکړئ، ځکه چې یوازې غوښتنې ته په کتلو سره دوه له هغو یو شان ښکاري۔

لومړی پوښتنه دا ده چې ایا کلي کوډ شوې ده، او دویمه دا چې ایا دا جوړښت کولای شي هغه خلاصه کړي۔ د ترتیباتو بدلونونه یوازې هغه وخت مانا لري چې دواړه ځوابونه معلوم وي۔

وګورئ چې ایا کلي کوډ شوې ده

د فایل لومړې کرښه ولولئ او بیا پرېږدئ کتابتون هغه تحلیل کړي، ځکه چې د فایل نوم هیڅ شي ثابتولای نه شي۔ د PEM بلاک چې لیبل ولري ENCRYPTED PRIVATE KEY کوډ شوی PKCS#8 دی، او زوړ RSA PRIVATE KEY بلاک چې Proc-Type: 4,ENCRYPTED لري دودیز بڼه ده، او دواړه د تیریدو عبارت تمه کوي۔ نه کوډ شوی PRIVATE KEY بلاک باید هېڅکله هغه ونه غواړي۔ تحلیل د هغه حساب په توګه چل کړئ چې د فایل مالک دی، ځکه چې د اجازې ستونزه بله او ډېره کمه زړه راښکونکې تېروتنه ورکوي۔

که کلي واقعاً نه وي کوډ شوې او کلاینټ لا هم پوښتنه کوي، له کریپټوګرافي کتلو څخه ودروئ او وګورئ چې ایا پروفایل د askpass فایل نوم اخلي چې خدمت لا هم لوستلای شي۔

وګورئ چې ایا دا جوړښت کولای شي هغه خلاصه کړي

OpenSSL 3 خپل د الګوریتم ملاتړ پر عرضه کوونکو ووېشه، او یوه ټولګه زړو شفرونو اوس د ډیفالټ عرضه کوونکي پر ځای په legacy عرضه کوونکي کې ده۔ هغه کلي چې په یو له دغو شفرونو کوډ شوې ده معتبره پاتې کیږي، خو هغه کتابتون چې د legacy عرضه کوونکي پرته بار شوی وي هغه نشي خلاصولای۔ په ځینو کلاینټونو کې دا د تکراریدونکې غوښتنې په توګه ښکاري، په نورو کې د تیریدو عبارت وروسته سخت ناکامي۔

هماغه کلي دوه ځله په هماغه باینري تحلیل کړئ: لومړی یوازې د ډیفالټ عرضه کوونکي سره، بیا د قوماندې کرښه کې legacy او ډیفالټ دواړه وغواړئ۔ که دویمه هڅه هغه ځای بریالۍ شي چې لومړۍ پکې ناکامه شوه، تشخیص پر شاهدو ولاړ دی نه پر د پرمختګ وخت۔ که دواړه یو شان ناکام شي، د تیریدو عبارت غلطه ده یا فایل خراب دی، او هېڅ د عرضه کوونکي ترتیب دواړه نه جوړوي۔

تر ټولو تنګه شته حل لار وګورئ

د ټول سیستم بدلون پر ځای کلاینټ ته محدود بدلون غوره کړئ۔ ځینې 2.6 جوړښتونه د پروفایل هغه انتخاب مني چې د هغه ډیمون پروسې لپاره دواړه عرضه کوونکي باروي، نو د هغې پر باور کولو دمخه د خپلې دقیقې نسخې په لارښود کې لارښوونه تایید کړئ؛ د سیستم openssl.cnf د سمولو پر ځای په کوربه کې هر OpenSSL پروګرام اغیزمنوي۔ تنګ ترتیب هم وروسته له دې چې کلي بیا کوډ شي بیرته راګرځول ډېر اسانه دي۔

د غوښتنې د له منځه تلو لپاره د تیریدو عبارت مه ړنګوئ۔ دا ساتل شوي اعتبارنامې په ساده متن فایل بدلوي او په خاموشۍ سره د هغو بیک اپ، کاپي او ملاتړ بنډل خطر بدلوي چې پکې ښکاري۔ مهم توپیر د هغه کلي ترمنځ دی چې خپله د تیریدو عبارت ته اړتیا لري او هغه کلي چې دا کتابتون یې خلاصولای نه شي۔

د خدمت زمینه وګورئ، بیا بیا کوډ یې کړئ

کله چې کلي خلاصېدلای شي، هغه د یوه اوسني الګوریتم سره بیا کوډ کړئ ترڅو تړاو ورک شي۔ نوی فایل د نوي شفر سره ولیکئ، وګورئ چې تحلیل کیږي، پروفایل تازه کړئ، او زړه کاپي یوازې تر هغه وساتئ چې یو اتصال بریالی شي۔ د تیریدو عبارت هېڅکله په قوماندې کرښه کې مه ږدئ، چیرې چې هر ځایي کارن یې د پروسو له لیسته لوستلای شي۔ زوړ فایل یوازې هغه وخت لرې کړئ چې نوی د خدمت له حسابه وتړل شي، نه یوازې ستاسو له شیل څخه۔

بیا هغه واحد وګورئ چې واقعاً کلاینټ چلوي۔ هغه کلي چې ستاسو په شیل کې لوستل کیږي ممکن بل حساب لاندې یا د کورونې سخت شوي ترتیب سره چلیدونکي خدمت لپاره نالوستونکې وي۔

د پروفایل ترڅنګ د عرضه کوونکي ترتیب ولیکئ او د دوه قوماندو ازموینه ورسره وساتئ۔ کله چې وروسته پرمختګ legacy عرضه کوونکی لرې کړ، هغه ازموینه بیا چل کړئ ترڅو وګورئ چې کلي لا هم ورته اړتیا لري که نه یا پروفایل کولای شي له دې موقت حل لارې وویستل شي۔

غوښتنه یو نښه ده چې لږ تر لږه درې لاملونه لري، او یوازې یو له هغو د تیریدو ورکه عبارت ده۔