OpenVPN لومړی کرښه ردوي؟ فایل به احتمال UTF-16 وي

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

افسانه: ایډیټر تاسو ته فایل ښیي

متن ایډیټر بایټونه په تورو تبدیلوي د هغه انکوډنګ سره چې یا یې پېژني یا یې اټکل کوي۔ کله چې UTF-16 اټکل کړي، فایل په سکرین کې بې‌نقص ښکاري، خو لاندې بایټونه جوړې دي، د هر لاتیني توري وروسته یو صفر بایټ راځي۔ OpenVPN هغه بایټونه د تورو په توګه لولي، او ناسم‌توب په لومړنۍ هغه لارښوونه کې ښکاري چې هڅه کوي یې تحلیل کړي۔

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

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

لومړني بایټونه واقعاً څه وایي

تورې نه، بایټونه ولولئ۔ دوه کوچنۍ کمانډې یې په ثانیو کې حل کوي، او هیڅ یې هم نه غواړي چې فایل په داسې اپلیکیشن کې خلاص کړئ چې بدل یې کړي:

file client.ovpn
head -c 24 client.ovpn | od -An -tx1

هغه نمونه چې تاسو یې لټوئ د پیل دوه بایټونه دي چې وروسته یې متن راځي چې هر دویم بایټ یې صفر دی۔ FF FE د UTF-16 لټل-اینډین ښیي، FE FF د بګ-اینډین، او EF BB BF د بایټ ترتیب نښې سره UTF-8 ښیي۔ بې نښې عادي UTF-8 فایل مستقیم د لومړي توري بایټ سره پیل کیږي۔

د تورو ترمنځ صفر بایټونه اصلي نښه ده۔ په UTF-16 لټل-اینډین کې client کلمه شپږ نه بلکې دولس بایټ نیسي، ځکه د هر ASCII توري وروسته صفر راځي۔ دا جوړښت د ایډیټر ښودنه تاسو ته نه شي ښودلای، او دوه بایټ پاکول یې نه شي لرې کولای۔

دلته یو مهم نازک ټکی شته: د OpenVPN د ترتیباتو لوستونکی په فایل پیل کې د UTF-8 د بایټ ترتیب نښه واقعاً پرېږدي، لکه څنګه چې 2.6 ترتیباتو لوستونکی ښیي۔ هغه زغم ځانګړی هماغه نښې ته دی، او د UTF-16 فایل لپاره چې توري یې صفرونو ډک دي هېڅ نه کوي۔ دواړه نښې یوه ستونزه ګڼل د افسانې دویمه نیمه ده۔

تبدیل کول یعنی بل نوم ساتل، نه پاکول

له هر څه مخکې د اپریټر د اصلي فایل نا‌لاس‌وه شوې کاپي وساتئ او په جلا فایل کار وکړئ۔ پروفایل کې کېدای شي خصوصي کیلي یا د حساب توکي وي، نو کاپي ستاسو د بېرته تګ لار او ستاسو حواله دواړه ده۔

بیا ریښتینی د انکوډنګ تبدیل ترسره کړئ، یا د ایډیټر د څرګند انکوډنګ مینو له لارې، یا د داسې کنورټر سره چې خپل انپټ او آوټ‌پټ انکوډنګ بیانوي:

iconv -f UTF-16 -t UTF-8 client.ovpn > client-utf8.ovpn
file client-utf8.ovpn

د کمانډ د وتلو حالت باور پرځای نتیجه وګورئ۔ تبدیل باید هره لارښوونه وساتي، او باید خپله هر ډوله دننه شوی سند یا کیلي بلاک په خپلو نښو کې بایټ په بایټ وساتي۔ د PEM معلومات بیا تاوول، په بلاک کې د کرښو پای بدلول یا د تبدیل پر مهال پروفایل بیا فارمټ کول زوړ ستونزه جوړولو پر مهال نوی ستونزه جوړوي۔

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

سم شوی انکوډنګ څه نه سمول کوي

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

هغه وروستي تېروتنې خپلې څېړنې ته ارزښت لري: سم املا، د دلیل نحو، او هغه نسخه چې مني یې۔ بریالی تحلیل بریالی پروفایل مه ګڼئ۔

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