OpenVPNが1行目を拒否する？ファイルはおそらく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ファイルは、先頭文字のバイトから直接始まります。

文字の間にゼロバイトがあることが手がかりです。各ASCII文字のあとにゼロが続くため、UTF-16のリトルエンディアンでは、clientという単語は六バイトではなく十二バイトを占めます。この構造はエディタの画面では見えませんし、二バイトを削除しても消せません。

ここに重要なニュアンスがあり、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ダンプは、文字コードの問題は直せても漏れた鍵は直せないのですから、秘密鍵を含みうるファイルの置き場所としては不適切です。