HTTPプロキシ経由のOpenVPN：まずCONNECT応答を読む
CONNECTプロキシはバイトを中継するため、両端にTCPが必要です。証明書を疑う前に407、403、503を読み、サーバー検証は有効のままにしてください。
VPNクライアントを社内HTTPプロキシに向けると、最初に役立つ事実は、プロキシがVPNのプロトコルを話していないことです。指定したアドレスへ通常のTCP接続を開き、その後は脇に退き、クライアントとサーバーがそのストリームの中で独自のやり取りを行います。クライアントが必要とするものは、トランスポートの種類からサーバーのリスナーまで、すべてこの配置に合っていなければなりません。ほとんどの失敗は二つの不一致で説明でき、それはCONNECTプロキシに向けたUDPプロファイルと、VPNのエラーと誤解されたプロキシ応答です。
プロキシが運ぶもの、運ばないもの
プロキシは輸送の中継点にすぎません。ブラウザーのプロキシになるわけでも、トンネル経由で訪れるサイトをキャッシュするわけでもなく、誰かが意図的に検査を設定しない限り内部のトラフィックは見えません。プロキシが開くトンネルは、設計上プロキシにとって不透明です。
つまりプロキシは、対応するリスナーを持たないサーバーを直すことはできません。宛先に到達する許可と、その宛先で待ち受けるサービスは別の事実であり、プロキシ管理者に属するのは前者だけです。
搬送路は両端ともTCPでなければならない
従来のCONNECTプロキシはバイトストリームを中継するだけですそのためクライアントはストリーム型のトランスポートを使う必要があり、その場合のクライアント断片は次のとおりです。
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128サーバー側には、remote行で指定したポートで実際のTCPリスナーが必要です。プロファイルでproto udpをproto tcp-clientに変えても、ストリームを期待するクライアントができるだけで、反対側にストリームができるわけではありません。同じサーバーがそのポートでUDPにも応答する場合、それは別のリスナーであり、同じリスナーの第二のモードではありません。
別個のTCPインスタンスがある場合、そのトンネルデバイス、アドレスプール、ルーティングは独自のリソースです。動作する設定をコピーしてトランスポートの語だけを変えると、それらのリソースは元のインスタンスを指したままになり、認証は通るが何もルーティングしない接続が生まれます。
VPNの結果より先にプロキシ応答を読む
クライアントの最初のやり取りは、宛先ホストとポートを指定するリクエスト行であり、その行への応答は、バイトストリームがそもそも存在するかを教えてくれ、証明書や資格情報が確認される前に届きます。
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECTへの200番台の応答は、ストリームが存在することを意味します。ゲートウェイ証明書が信頼されるか、共有鍵が一致するか、ユーザーアカウントが有効かについては何も語りません。それらの確認は後でストリームの中で行われ、HTTPステータス行ではなくクライアント自身のメッセージで失敗します。クライアントのログでは、プロキシのハンドシェイク後の最初のOpenVPNイベントを探すべきで、ウィンドウが閉じる前の最後の行ではありません。
プロキシの資格情報とVPNの資格情報は、別のチームが持つ別の身元であることがよくあります。407はVPNアカウントの間違ったパスワードではなく、拒否された証明書はプロキシの権限問題ではありません。
CONNECTが明かさないもの
明示的なCONNECTトンネルは傍受ではありません。プロキシはバイトを転送し、VPNのTLSセッションを終端しないため、クライアントによるサーバー証明書の検証は意味を持ち続け、有効にしておくべきです。プロキシを通るために検証を切るのは、あなたの抱える問題とは別の問題を解くことになります。
組織が意図的にTLSを終端して検査する別の仕組みもあります。それらは独自の信頼設定と独自のポリシー判断を必要とし、普通のhttp-proxy行が求めるものではありません。
TCPの中のTCPのコスト
トンネルをTCPで運ぶと、外側のストリームは順序と再送が保たれ、内側のトラフィックも通常はTCPです。二つの回復機構は連携しないため、一つのセグメント損失が、再送されるまでその外側ストリームを共有するすべてを止めることがあります。これは互換性のための実際のトレードオフであり、無料のアップグレードではありません。
ネットワークに選択肢がないときはプロキシ経由の経路を使い、ポリシーが許す場所では直接UDP経路を優先してください。変更後は同じプロキシ、宛先、プロファイルが次の段階に到達することを確認し、そのアドレスでページを読み込むブラウザーは別のプロトコルを使っており、トンネルについては何も証明しません。