この公開VPNノードは実際にどのプロトコルを提供しているのか?
サーバーソフトウェアがプロトコルに対応しているからといって、このノードがそれを有効にしているとは限りません。エンドポイント、プロファイル、そして実際に失敗する段階を確認してください。
ソフトウェアが対応しているからノードが提供している、という推論は、ルールと呼べるほど頻繁に外れる誤りです。SoftEtherの配備は互換性のある接続方式の任意の部分集合を有効にでき、公開ノードとは所有者と設定を伴う配備です。何で接続できるかはそのノード次第であり、それが動かしているプロジェクトの機能一覧次第ではありません。「プロトコルが壊れている」というチケットの多くは、この二つの隙間にこそ実際に住んでいます。
プロジェクトの一覧が実際に約束していること
プロジェクトのプロトコル機能は、サーバーが何をできるかを示しています。あるノードはそのリスナーの一部を有効にし、他は有効にせず、運営者はソフトウェアのバージョンに触れずにその集合を変えられます。したがって同じビルドの二つのノードは別の振る舞いをし、一方に対して動くプロファイルは次の対象について何も証明しません。どこに接続するかを選ぶとき、プロジェクトのページよりノード自身の一覧が優先されます。
一覧はメニューではなく、エンドポイント、ポート、トランスポート、プロトコルファミリー、認証方式という五つの項目として読んでください。次を宣伝する公開ノードは、SSTPポート上のリスナーについて教えてくれただけで、どの証明書を提示するのか、あなたのアカウントがそこで動くのかは教えてくれません。この五つの項目を自分のプロファイルと突き合わせるほうが、クライアントを何度も入れ直すより速く、後で検証できる書かれた期待が得られます。
プロファイルを、それが示すエンドポイントに合わせる
ネイティブのSoftEtherエントリは自動的にOpenVPNの設定ではなく、同じ見出しの下、同じプロバイダーのページに両方が載っていても同じです。ノードがOpenVPN用にTCPとUDPの両方のリスナーを公開しているなら、それらを二つのエンドポイントとして扱ってください。一方から他方へ書き換えたプロファイルは、誰も有効にしていないリスナーを指し、ファイル内のトランスポート表記はアドレスの一部であって、見た目だけの設定ではありません。
クライアントがインポートしたファイルを受け入れることは、そのファイルが解析できることを示すだけで、反対側で遠隔のリスナーが待っているかは何も語りません。だからこそ最初の接続試行が本当の試験になります。プロトコルを責める前に、プロファイルのremote行をノードが告知しているホストとポートと比べてください。
失敗する段階を調べる
ウェブのトラフィックに応答するホストでも、目的のVPNサービスを欠いていることがあります。また、一つのプロトコルを拒否するホストが、すべてについて停止しているとは限らず、この二つの誤りは同じ午後に人々を正反対の方向へ送ります。一方は問題のないファイアウォールを追いかけ、もう一方はそもそも問題ではなかったクライアントを入れ直します。経路ごとに別々に調べれば、答えはホスト全体ではなく一つのリスナーを語ります。
この五つの確認は、公開ノードでよく使われる方式を網羅しているので、クライアントが使うのと同じネットワークから実行してください。フィルタされたポートは、遠くから見ると存在しないリスナーとまったく同じに見えるからです。
nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example
| 結果 | 段階 | 何を排除できるか |
|---|---|---|
| 接続拒否またはタイムアウト | トランスポート | リスナー不在、フィルタ済み、またはポート違い |
| TLSハンドシェイクまたは身元のエラー | 証明書 | プロトコルの可用性。リスナーは応答した |
| AUTH_FAILEDまたはアカウント拒否 | 認証 | エンドポイント。問題は資格情報にある |
| UDP 500と4500が無応答 | IPsecの折衝 | ESPとL2TPは認証の前に遮断される |
何かを変える前に、観測したエラーをそれぞれの行に結びつけてください。TLSの身元エラーはリスナーが存在する証拠なので、プロファイルを別のプロトコルに書き換えると有効な証拠を捨てることになります。接続拒否が証明するのはこのポートが応答しなかったことだけで、「ノードはOpenVPNに対応していない」よりずっと狭い主張です。
何かを変える前にエラーを保存する
書き留めるべきは正確な結果です。タイムアウト、証明書の身元エラー、アカウント拒否、アプリケーション層の拒否という四つの異なる結末があり、最初の一つだけがプロトコルの不在について、最後の一つだけが接続成功後の許可についてです。クライアントを初期化したりプロトコルを入れ替えたりすると、次の失敗が別の履歴で比較すべき基準線もなしに訪れるため、その区別は壊れます。
互換性のないプロファイルが動いているように見せるために検証を弱めないでください。証明書チェックを切ると、明確な身元エラーが、意図していない何かへの接続に変わり、その結果の成功は、どの段階が誤っていたかを隠すため、元のエラーより悪いものです。
ノードごとに、毎回再確認する
公開ノードの一覧にあるネイティブのSSL、OpenVPN、L2TP/IPsec、SSTPという選択肢は、その時点でのそのノードの設定を表しています。同じソフトウェアでも別の場所では違う集合を提示でき、プロバイダーはあなたのブックマークと次の試行の間にリスナーを廃止できます。古いメモは古い配備を語ります。
検証済みのプロファイルをエンドポイントと方式とともに記録し、ノードが変わったときや接続が失敗し始めたときに調査を繰り返してください。SoftEtherプロトコル仕様はソフトウェアが何をできるかの参照であり、ノード自身の一覧はそれが何をするかの参照です。二つの文書を切り離しておけば、診断は短くなります。