手元に wg0.conf があり、クライアントが .ovpn しか受け付けないとします。そこで誰かがファイルを変換しようと提案します。名前を変えても OpenVPN が解釈できないプロファイルになるだけで、項目ごとに丁寧に訳しても、解釈はできてもハンドシェイクで失敗します。原因はファイル形式ではありません。WireGuard と OpenVPN は別のプロトコルで、ハンドシェイクも認証モデルも、peer という考え方も異なります。変換が成り立つのは、相手側を運用している人から OpenVPN プロファイルをもらうという意味だけです。

手元のファイルは接続プロファイルではなく peer を記述している

WireGuard の設定が短いのはプロトコルがそうだからです。秘密鍵とアドレスを持つインターフェースがあり、次に公開鍵、endpoint、AllowedIPs の一覧を持つ peer が一つ以上あります。設定すべきネゴシエーション層も、選ぶべき暗号スイートもありません。

OpenVPN のプロファイルは TLS ベースの制御チャネルのクライアントであり、だからこそ証明書や資格情報への参照と、認証方法を記述した指示を含みます。

訳したファイルがハンドシェイクで失敗する理由

WireGuard は peer の静的鍵で鍵付けされた Noise ベースのハンドシェイクから始まり、peer の公開鍵が既知でなければ沈黙したままです。OpenVPN は TLS セッションを開き、サーバー証明書か静的鍵を検証し、そのうえで証明書、ユーザー名とパスワード、あるいはその両方で利用者を認証します。WireGuard のファイルにはそのどれも書かれていません。訳したファイルは正しい endpoint と、それ以外のすべてを誤って運ぶことになります。

アドレスとポートを流用しても助けになりません。相手側は別のパケットを待っているからです。

プロバイダーに何を尋ねるか

WireGuard のファイルをプロバイダーが提供したなら、同じアカウントに OpenVPN のアクセスがあるかを尋ね、そのプロファイルを要求してください。用意している例は多く、最初の写しを書き換えたものではなく、独自の資格情報とともに届きます。

答えがいいえなら、制約はファイルではなく契約にあり、変換ツールでは変わりません。

ルーターやクライアントが OpenVPN しか話せない場合

接続する機器が OpenVPN しか対応していないなら、別の拡張子を探す前に、相手側の文書化されたプロトコル対応を確認してください。OpenVPN を終端するルーターは、ファイルを取り込んでも WireGuard を受け入れるようにはなりません。現実的な選択肢は、サーバー側に OpenVPN の endpoint を用意するか、WireGuard を話す別の機器を使うことです。

どちらのファイルを持っているかではなく、相手側を誰が管理しているかで選んでください。

サーバーを自分で運用するなら、プロトコルを追加する

二つ目のプロトコルを支えることは、二つ目のサービスを動かすことです。Linux サーバーなら、独自の CA、サーバー証明書、クライアント証明書、そして server と push の指示を持つ OpenVPN のインスタンスに、そのポート用のファイアウォール規則を加えたものになります。既存の WireGuard の peer 項目は、そのどれも記述していません。アドレスプールと push される経路は、WireGuard の AllowedIPs とは別に設計してください。同じ仕組みの別名ではないからです。

そのうえでクライアントから確認します。プロファイルが読み込まれ、TLS セッションが完了し、push された経路が現れ、トンネル経由でしか届かないホストに通信が到達することを確かめます。

変換ツールという発想が安全な場面

値を手作業でメモに写すのは問題なく、しばしば有用です。endpoint、アドレス、peer の公開鍵は配置についての事実にすぎないからです。変換をうたうウェブサイトに秘密鍵をアップロードするのは問題です。その鍵が資格情報であり、サービス側には変換先のプロトコルが存在しないからです。OpenVPN クライアントから同じアクセスが必要なら、代わりに OpenVPN の資格情報を求めてください。

二つの設定を並べて置き、別々のアクセス経路として扱ってください。実際にそうだからです。

関連記事