サーバーロック型プロファイルがTLSプロキシの背後で失敗する：どちらの世代か

同じ日に、同じポータル経由で、一方のユーザーは接続でき、もう一方は接続できない。両方ともサーバーロック型プロファイルを持ち、両方とも同じ Access Server ビルド上にあり、唯一の違いはプロファイルが生成された時期です。これは認識する価値のあるパターンです、なぜなら「サーバーロック型」は接続手順ではなくポリシーを指すからです。Access Server はこの成果物を二世代出荷しており、TLS リバースプロキシはそのうち一方の経路の前にしか存在しません。どちらの分岐にいるかは三つの条件で決まります。

二つの世代、二つの接続手順

2.8 までの旧設計では、インポートされるファイルは疑似プロファイルです。OpenVPN Connect はこれを使って HTTPS 経由で Access Server の Web API に認証し、一時的なユーザーロック型プロファイルとセッショントークンを受け取り、その後に初めて VPN を確立します。二つのトランスポートが順に動き、最初のものは通常の Web リクエストです。

2.9 で導入された形式は、その接続ごとのブートストラップを行いません。これは互換性のある OpenVPN クライアントが使えるネイティブプロファイルであり、OpenVPN Connect 専用ではありません。ダウンロードや URL からのインポートに HTTPS が関わることはありますが、それは公開の段階であり、接続ごとに一時プロファイルを取得するものではありません。

アップグレードは既に発行済みのプロファイルを必ずしも書き換えないため、現行のサーバーバージョンでも古い成果物を配布していることがあります。サーバービルドが示すのは何が可能かであり、このユーザーが何をインポートしたかではありません。

分岐を決める三つの条件

一つ目の条件は成果物の世代です。ファイルを入手し、どのように生成されたかを見て、それをインポートしたクライアントのバージョンを記録します。ファイルから世代を特定できない場合は、テストアカウント用に新しく発行したプロファイルがサーバーが今日何を生成するかを示し、これは失敗しているユーザーが持っている情報とは別のものです。

二つ目は、フロントエンドが実際に何を終端しているかです。TLS をオフロードする第七層の HTTP リバースプロキシは、第四層の TCP フォワーダーと同じものではなく、UDP フォワーダーも同様です。ポート 443 における Access Server の通常の構成では、OpenVPN TCP デーモンがブラウザーのトラフィックを認識して Web サービスに渡すため、無関係な HTTPS ターミネーターを前に置いても、そのデーモンのプロトコル処理は保たれません。443 という番号を共有しても、二つの設計が等価になるわけではありません。

三つ目は、失敗がどこで起きるかです。VPN 前の失敗と制御チャネルの失敗は、「接続中」としか表示しないクライアントでは似て見えますが、証拠を残す場所が異なります。古い形式が関与しているならブートストラップが候補です。新しい形式が関与しているなら、Web アクセスログが空であることは想定内であり、どちらの方向にも何も証明しません。

成果物が古い場合：まずブートストラップが失敗する

クライアントの最終状態ではなく、実際のエラーを読み取ります。注目すべきフィールドは HTTPS エラー、クライアントが期待したサーバー ID、リクエストの宛先、そして証明書の検証が完了したかどうかです。次にそれらをサーバー側の Web サービスとプロキシのログと突き合わせます。

ブラウザーがログインページに到達することは、このクライアントの API 認証が成功した証拠ではありません。別のリクエストであり、証明書の期待も異なり、多くの場合ホスト名も異なります。ポータルが正しく提供されていてクライアントがまだ失敗するなら、不一致はブートストラップ経路にあり、ユーザーのパスワードにあるのではありません。

TLS 検証を無効にしたり認証ポリシーを緩めたりして、比較を通してはいけません。それは診断可能な構成の不一致を、動作するが検証されていない経路に変えてしまい、まさにその変更が一時的なテストを恒久的な穴に変えます。Access Server の接続プロファイルのドキュメント は両方の世代と一時プロファイルの流れを説明しており、プロキシのせいだと決めつける前に確認すべき参照資料です。

成果物が新しい場合：代わりに制御チャネルを読む

2.9 形式のプロファイルでは、クライアントはネイティブの VPN エンドポイントへ直接向かいます。プロファイル内のエンドポイント、使用中のトランスポート、制御チャネルのエラーを調べます。クライアントが HTTP リクエストを一度も発行しないなら、それは設計どおりであり症状ではありません。

ここでもプロキシの問いは形を変えます。HTTPS オフロードは、決して見ない TCP 専用のストリームを壊せませんが、プロファイルを公開するダウンロードは壊し得ますし、TCP 専用のフォワーダーは UDP をまったく運びません。フロントエンドが無関係だと結論づける前に、プロファイルがどのトランスポートを要求しているかを確認してください。

単一ストリームの TLS パススルーは狭い構成です。UDP 転送を提供せず、443 におけるデーモン自身のサービス転送動作を再現しません。フロントエンドがそのどちらかを行うなら、対処法が異なるため、どちらかを明示してください。

狭いままの対処

最も侵襲の少ない確認は、テストアカウント用に新しいサポート対象プロファイルを生成し、同じ認証要件で意図したネイティブエンドポイント経由で接続することです。それが機能し、保持している古いプロファイルが機能しないなら、一段階で成果物をサーバーからもプロキシからも切り離せたことになります。

ユーザーロック型プロファイルの配布ユーザーロック型プロファイルの配布はレガシーなブートストラップ依存を完全に取り除きます、なぜなら失敗し得る一時プロファイルの交換が存在しないからです。意図したユーザーに対して発行する必要があり、管理者からコピーしてはならず、クライアントに許可される内容を変えるため、回避策ではなくポリシーの決定として扱ってください。

次に公開構成を修正し、ダウンロードとポータル利用のための Web 経路、そしてプロファイルが期待するトランスポート上のネイティブ VPN 経路という、必要な経路をすべて存在させます。プロキシの仕事は一つの層にとどめます。動作するユーザーロック型トンネルはその経路が機能することを証明しますが、すべてのプロキシ構成がすべての世代を支えることを証明するものではなく、古いブートストラップの失敗が新しい形式を否定するものでもありません。

• プロキシに触れる前に成果物の世代を特定してください。
• 失敗がトンネルの前で起きるのか、その中で起きるのかを確定してください。
• フロントエンドが何を終端するのか（HTTP、TCP ストリーム、UDP のいずれか）確認してください。
• ポリシーを変えずに、新しく発行したプロファイルをネイティブエンドポイントに対して試してください。