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