SoftEther 接続プロファイル: インポート前に六項目を確認する

プロファイルのインポートは成功したのに認証で失敗するのは、ファイルがアカウントの未加入の Virtual Hub を指しているからです。ファイル自体に破損はなく、資格情報が発行されていない構成を記述しているだけです。六つの項目がインポートの成否を決めます。ホスト名、ポート、プロトコル、Virtual Hub、ユーザー ID、そして管理者資格情報が誤って渡されていないかです。最初の三つのチェックがこれらの項目を順に扱い、最後の二つがファイルそのものと実際に参加した先を扱います。

チェック1: ホスト名とポート

何かをインポートする前に、ホスト名、ポート、宣言された接続方式を読みます。ネイティブの SoftEther リスナーは通常 TCP 443 で応答し、992 と 5555 は制限の厳しいネットワークの背後にいるクライアント向けに事業者が開放する代替です。ウェブサイトや別のサービスを提供するポートを指すプロファイルは、認証の前に失敗し、その失敗を資格情報の問題として報告します。この組を、事業者がこのエンドポイントについて公開している情報と比べます。昨年誰かが集めたディレクトリ一覧と比べてはいけません。ホスト名が事業者の一度も挙げていないアドレスに解決されるなら、そこで止めてください。次の手順で資格情報がそのアドレスへ送られるからです。

443 番ポートは共有地なので、ポートだけではその背後のサービスを何も証明しません。SoftEther クライアントはプロトコルのハンドシェイクで両者を区別するため、プロファイルが正しいポートを指していてもウェブサーバーに行き着くことがあります。その失敗はクライアントのログではパスワード誤りに見えますが、パスワードは一度も検証されていません。

エンドポイントをホスト名、ポート、方式の順に書き留めます。この三つ組は、接続せずに検証できる部分であり、リスナーがまだ動いているかを事業者に尋ねるときに引用する部分でもあります。公開された情報源から補えないものは、推定せず未検証のままにします。

チェック2: プロトコルがクライアントを決める

複数の接続方式を提供するサーバーが、書き出した一つのファイルを、どのクライアントでも開けるプロファイルに変えるわけではありません。 Each method has its own format, its own client and its own failure mode、両者を混ぜると資格情報の問題に見えるエラーが生じます。どのクライアントで開くかを決める前に、ファイルが宣言している方式を確定してください。

下の表は一般的なポートと、各方式が実際に必要とするものを示します。ポートは事業者の選択なので、既定値として扱い、特定のサーバーについての事実とは考えないでください。ネイティブの SoftEther プロファイルは SoftEther クライアントがインポートし、ovpn バンドルは OpenVPN に属し、SSTP や L2TP のプロファイルは OS 自身が処理します。最初のクライアントが拒否したファイルを開くために二つ目のクライアントを入れると、明快なエラーが分かりにくいエラーに変わるのが通常です。

拡張子ではなくファイル内の宣言を読みます。OpenVPN の名を持つファイルは定義上 OpenVPN プロファイルであり、SoftEther プロファイルは SoftEther クライアントがインポートする小さな設定で、両者は互換ではありません。宣言された方式が自分では提供できないものであれば、それがインポートの問いへの答えです。

チェック3: ハブ、ユーザー、管理者の役割

ネイティブ接続では、プロファイルは Virtual Hub とその中のユーザーを指定します。 A hub is a logical VPN server instance with its own users and its own settings、ユーザーはそのハブのメンバーで、独自の認証を持ちます。どちらもサーバー管理ではなく、サーバー管理はリスナー、ハブ、配置の全ユーザーを制御します。クライアント用プロファイルにその管理権限が付いてくることは決してあるべきではありません。クライアントを動かすために管理者資格情報が送られてきたら、接続できるかどうかにかかわらず構成が誤っています。

接続を記録するときはこの三つを分けてください。失効の仕方が違うからです。ハブのユーザーを削除するとその一人のアクセスが終わり、配置の残りは影響を受けません。一方、管理者資格情報のローテーションはすべてに及びます。この違いは、チームに一つのハブユーザーを共有させることに反対する理由でもあります。単一の資格情報は全員にとって一回の失効事象を意味するからです。

チェック4: ファイルは中身と同じだけ機密である

形式によっては、保存されたパスワード、証明書、事前共有鍵をプロファイルが含むことがあります。書き出したものが存在する間は機密として扱ってください。チケットに添付した複製は、他の誰かがインポートできる複製だからです。共有の前に資格情報を外すか、新しい鍵で作り直したプロファイルを共有します。ファイルの機密性は拡張子や大きさではなく中身から来ます。

事業者が公開している経路でエンドポイントを確認し、ディレクトリのラベルは未検証として扱います。公開ノード一覧の国旗とホスト名は項目を投稿した人が選ぶものなので、どちらも誰がサーバーを運用しているかを確定しません。プロファイルが公開ディレクトリ由来なら、それは確認を増やす理由であり、減らす理由ではありません。

ファイルがどこから来て、いつ受け取ったかを記録します。後で接続の挙動が変わったとき、まず照合するのは出所と検証済みエンドポイントです。出所のないプロファイルは、監査できないプロファイルです。

検証した方の複製を保存し、後から見つけた方は保存しません。同じ名前で別のエンドポイントを持つ二つのファイルは、動いていたインポートがサポート案件になる道筋です。検証済みの複製は、出所についてのメモの隣に置きます。

チェック5: アプリケーションを試す、状態ランプではない

インポート後は、接続インジケーターではなく実際に必要なアプリケーションを試します。認証の成功は資格情報が機能することを示すだけで、期待したルートや DNS がセッションに付いてきたことは示しません。接続してから、プロファイルが到達すべきサービスを使ってください。

割り当てられたルートと DNS サーバーを確認し、設計に分割がある場合はどの宛先がトンネルを迂回するかを記録します。次に、除外されるべき宛先を一つ使って繰り返します。すべてをトンネルに流す分割トンネルでも、単一宛先のテストは通ってしまうからです。プライベートなリソースが失敗する場合、疑うべきは資格情報より先にルートです。四つの結果を書き留めます。認証済み、サービス到達可能、ルートは想定どおり、除外先は除外されている。

四つの結果すべてを、事業者がこのハブについて約束した内容と比べます。除外されるはずの宛先にも到達できるのに認証が通るセッションは、分割が効いておらず、プロファイルは問題ではないことを意味します。期待かハブのポリシーを直し、同じ順序で四つのチェックを再実行してください。