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