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