OpenVPN-ը մերժո՞ւմ է առաջին տողը։ Ֆայլը, ամենայն հավանականությամբ, UTF-16 է

Սխալը մատնանշում է .ovpn ֆայլի առաջին տողը և մեջբերում է մի բան, որը նման է խառնված տառերի այնտեղ, որտեղ պետք է լինի client։ Ֆայլը ձեր խմբագրիչում բացվում է անխնդիր, առաջին տողը կարդացվում է client, իսկ հրահանգը լրիվ սովորական է։ Երկու դիտարկումներն էլ ճշմարիտ են, որովհետև խմբագրիչը վերծանում է բայթերը, իսկ հաճախորդը՝ ոչ։ Այն, ինչ տեսնում եք, գրեթե միշտ կոդավորման խնդիր է, ոչ թե շարահյուսության խնդիր։

Առասպելը՝ խմբագրիչը ձեզ ցույց է տալիս ֆայլը

Տեքստային խմբագրիչը բայթերը վերածում է նիշերի այնպիսի կոդավորմամբ, որը կա՛մ հայտնաբերում է, կա՛մ գուշակում։ Երբ գուշակում է UTF-16, ֆայլը էկրանին կատարյալ է երևում, մինչդեռ ներքևի բայթերը զույգեր են, յուրաքանչյուր լատինական տառից հետո զրոյական բայթ է գալիս։ OpenVPN-ը այդ բայթերը կարդում է որպես նիշեր, և անհամապատասխանությունը ի հայտ է գալիս առաջին այն հրահանգի մոտ, որը նա փորձում է վերլուծել։

Այսպիսով՝ տեսանելի տողը և հանձնվող տողը երկու տարբեր բաներ են։ Տեսանելի տարօրինակ նիշերը ջնջելը փոփոխություն է ցուցադրման մեջ, ոչ կոդավորման, և հաջորդ վերլուծությունը ձախողվում է նույն պատճառով՝ մի փոքր այլ հաղորդագրությամբ։ Այդ պատճառով էլ սխալի մեջ եղած նշանի հետևից ընկնելը երբեք ոչ մի տեղ չի տանում։ Բայթերը սխալ են աղբյուրում, և յուրաքանչյուր հաջորդ ընթերցող գուշակում է նույն կոտրված հաջորդականությունը։

Արժե ճանաչել ձախողման կոնկրետ ձևը, որովհետև այն յուրահատուկ ձևով ախտորոշիչ է։ Նշանը ֆայլի հենց սկզբում, այնպիսի պրոֆիլում, որը մնացածում աշխատել է այլ մեքենաներում, բայթերի կարգի հարց է, ոչ թե բառապաշարի։

Ինչ են իրականում ասում առաջին բայթերը

Կարդացեք բայթերը, ոչ թե նիշերը։ Երկու փոքր հրաման լուծում են հարցը վայրկյանների ընթացքում, և ոչ մեկը չի պահանջում ֆայլը բացել հավելվածում, որը կարող է փոխել այն:

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

Ձեր փնտրած օրինաչափությունը սկզբնական բայթերի զույգ է, որին հաջորդում է տեքստ, որտեղ ամեն երկրորդ բայթը զրո է։ FF FE-ը նշում է UTF-16 little-endian, FE FF-ը՝ big-endian, իսկ EF BB BF-ը՝ UTF-8՝ բայթերի կարգի նշանով։ Նշան չունեցող սովորական UTF-8 ֆայլը սկսվում է ուղիղ առաջին տառի բայթով։

Տառերի միջև եղած զրոյական բայթերն են ամենաբացահայտիչը։ UTF-16 little-endian-ում 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 արտածումները վատ տեղ են այնպիսի ֆայլի համար, որը կարող է գաղտնի բանալի պարունակել, որովհետև կոդավորման խնդիրը հեշտ է շտկել, իսկ արտահոսած բանալին՝ ոչ։