SoftEther ネイティブクライアントか OpenVPN プロファイルか：適切なポートを選ぶ

SoftEther サーバーはネイティブの SSL ポートと OpenVPN 互換ポートで同時に応答できるため、両者は二つの扉を持つ一つのサービスのように見えます。実際にはクライアントも設定形式も機能も異なる二つのサービスです。ネイティブのプロファイルを OpenVPN クライアントに入れると解析の段階で失敗し、そのエラーは理由をほとんど語りません。

まずリスナーを選び、次にクライアントを選びます。

二つのリスナー、二つの設定形式

ネイティブプロトコルは SoftEther クライアントと、サーバー、ポート、仮想ハブ、ユーザーを指定する接続定義を使います。OpenVPN 互換リスナーは remote ディレクティブ、TLS 素材、そして単独の OpenVPN サーバーが提供するよりずっと小さな対応集合から取ったオプションを備えた OpenVPN プロファイルを期待します。SoftEther はこれを OpenVPN クローン機能と呼び、クローンという言葉は忠実度についての有益な手がかりです。

互換性はバージョンの問題です。現在の OpenVPN マニュアルが何を記しているかではなく、配備されたビルドが何を受け入れるかを確認します。

ステップ 1：運用者がどのリスナーを有効にしたか調べる

ポート番号から推測するのではなく、リスナーの一覧を求めます。443 で TLS に応答するサーバーが、ネイティブプロトコルも同じポートを使えるため、必ずしも OpenVPN の端点とは限りません。マニュアルの互換サーバー機能の節に、どのクローンがあり、どう有効にするかが書かれています。

ホストに到達できるなら、チュートリアルのポートではなく渡されたポートを試します：openssl s_client -connect vpn.example.com:443 -brief少なくとも TLS があるかどうかは分かります。

ステップ 2：対応するクライアントとプロファイルを使う

ネイティブ接続では、SoftEther クライアントを導入し、運用者の情報で接続を作り、仮想アダプターを接続します。互換リスナーでは、そのリスナーが期待する CA とクライアント素材が入っている、運用者がサーバーから書き出した OpenVPN プロファイルを読み込みます。汎用の例から手作業でプロファイルを組んだり、ネイティブの接続定義を OpenVPN の設定に貼り付けたりしないでください。

読み込み時の解析エラーは形式の問題であり、ネットワークの問題ではないので、ファイアウォールへ向かわせるべきではありません。

ステップ 3：比較を公正に保つ

運用者が両方を公開しているなら、端末、接続ネットワーク、作業を一定に保ったまま比べます。二つの経路は認証、接続するサブネット、そしてその後サーバーがあなたの通信をどう扱うかで異なり得ます。ホストが共通でもポリシーが共通とは限りません。ファイルコピーとビデオ通話では同じ経路の違う部分に負荷がかかるため、作業も一定に保ってください。

読み込みが失敗するたびに現れる対処法に抗ってください。証明書の確認を切ったり、古い暗号を有効にしてプロファイルを通したりするのは後退であって、互換機能ではありません。

ステップ 4：接続後に経路を確認する

接続したら、受け取ったアドレス、それに伴うルート、DNS、そして内部リソースを一つ確認します。ネイティブ側で調べるのは仮想アダプター、OpenVPN 側ではクライアントが作った tun か tap のデバイスです。どちらにせよ問いは、選んだリスナーが必要なアクセスを与えるかどうかであり、トンネルが上がったかどうかとは別の事実です。前後のアドレスを書き留めて比べてください。

どのリスナーとどのクライアントのバージョンが動作する結果を出したかを記録します。そうしなければ次の人がポート番号から同じ発見をやり直すことになります。