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 исписи лоше су место за датотеку која може да садржи приватни кључ, јер проблем са кодирањем је лако исправити, а исцурели кључ није.