OpenVPN プロファイルが SoftEther にインポートできない理由

どちらも VPN 設定に見える二つのファイルが同じフォルダーに置かれ、実際に動くのは片方だけです。OpenVPN プロファイルはそのクライアントが理解する命令を伴う TLS トンネルを記述し、SoftEther 接続は別の認証契約を持つ仮想ハブに対するセッションを記述します。一方を他方へ変換するのは書式の練習ではありません、二つのクライアントが同じプロトコルを実装していないからです。運用者が実際にどちらのサービスを公開したのかを特定することが、その後のすべてを決めます。

二つのファイル、二つの契約

OpenVPN プロファイルはクライアント設定であり、リモートエンドポイント、トランスポート、TLS 素材、そしてルーティングと再ネゴシエーションのための命令を含みます。SoftEther 接続は仮想ハブに対するネイティブクライアントのセッションで、仮想アダプターが接続されています。

両者は同じネットワークへのアクセスを記述できますが、交換可能ではありません。OpenVPN リスナーはサーバーが別ポートで公開できる互換機能で、ネイティブプロトコルではなく OpenVPN を話します。ネイティブクライアントはネイティブプロトコルを話し、独自のプロファイルを期待します。一つのサーバーに二つの扉があり、それぞれの扉に固有の鍵があります。

ファイル拡張子はほとんど何も教えてくれませんが、だからこそ運用者の答えがファイル名より重要です。

証明書ブロックに触れる前にサーバーを読む

運用者には、どのポートとトランスポートか、どの認証方式か、どのクライアントを使う想定かを尋ねてください。その答えで当て推量の大半が消えます。

次に、ガイドの主張ではなく実際に何が待ち受けているかを確認します。無効な互換リスナーはそのポートに何も表示せず、有効なリスナーは誰も接続したことがなくてもソケットを表示します。閉じたポートと拒否されたログインの違いが最初の有用な診断です。その後のすべては、どちらの扉を叩いたかによって決まります。

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

リスナー一覧にない UDP ポートは、ファイアウォールの問題ではなく無効化された機能です。

ネイティブクライアントが必要とし、プロファイルが与えられないもの

ネイティブクライアントは仮想ネットワークアダプターをインストールし、接続をそれに結び付けます。そのアダプターがなければルーティングするインターフェースが存在せず、ネイティブ接続が認証を通過してもまったく通信を運ばないことがあります。

ネイティブ認証は仮想ハブに対して行われ、ハブ管理者が作成したユーザーオブジェクトを使います。OpenVPN プロファイルからコピーした証明書ブロックがハブのユーザーになることはなく、ハブのユーザーがクライアント証明書になることもありません。二つのシステムは別のものを保存しており、プロファイルにはハブのユーザー記録を置く場所がありません。これは構文の問題ではなく構造の違いです。

秘密鍵はどの変換サービスにも渡さないでください、マシンの外に出た鍵は開示済みとして扱う必要があるからです。

OpenVPN 互換リスナーが受け付けるもの

互換リスナーはクライアントから見れば本物の OpenVPN サーバーであり、OpenVPN クライアントと、そのクライアントが対応する命令を期待します。インラインの証明書ブロックは OpenVPN の機能であり、フェンスのその側に属します。

しないのは、ネイティブの SoftEther プロファイルを受け入れることです、そのプロファイルは OpenVPN 設定ではないからです。リスナーはネイティブクライアントを OpenVPN クライアントに変えることもありません。運用者がネイティブサービスだけを提供するなら答えはネイティブクライアントであり、互換リスナーを提供するなら答えは OpenVPN とその独自素材です。

運用者がサポートするエクスポートを求めてください、断片から組み立てるのではなくエクスポートには手作りファイルが通常見落とす詳細が含まれるからです。

命令を編集する前に経路を証明する

クライアントを選んだら、ルートに触れる前にトンネルを試験します。ログインの成功と通信を運ぶインターフェースは別の結果です。

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

割り当てられたアドレスを運用者が説明したプールと比較し、そのうえでルートとリゾルバーを別々に見ます。ネイティブのハブ接続はきれいに認証を通過しながらルートをまったくインストールしないことがあり、クライアント側からは壊れたトンネルに見えます。この三つが一致して初めて命令を編集する価値があります。早く編集すると、どの層が誤っていたかが隠れます。