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 дъмпове са лошо място за файл, който може да съдържа частен ключ, защото проблемът с кодирането се поправя лесно, а изтекъл ключ — не.