Cloudflare のプロキシが一つの名前で OpenVPN を運べない理由

一つのマシンがウェブサイトと OpenVPN サーバーを動かしており、一つのホスト名をそこに向けてオレンジ色の雲に通信を整理させたくなります。プロキシが整理するのは HTTP と HTTPS です。OpenVPN のセッションは、そのセッションがどのポートを使っていても整理しません。二つの名前、一つは直接、一つはプロキシ経由にすれば、費用はかからず、この種の混乱を丸ごと取り除けます。

二つの名前、二つの搬送路

ウェブサイトにはプロキシされたレコードを与え、HTTP と HTTPS の通信を Cloudflare 経由にします。VPN には DNS のみのレコードを与え、公開 VPN の入口へ直接解決させ、クライアントには設定された UDP または TCP ポートを使わせます。

両方の名前が同じオリジンマシンに到達することはあります。違いはクライアントとそのマシンの間で何が起きるかであり、その違いこそが分離の目的です。

Cloudflare のネットワークポートのリファレンスには、通常のウェブプロキシが受け付けるポートが一覧されています。その一覧はあくまでそれらのポート上の HTTP と HTTPS の話であり、たまたま番号を共有する任意のプロトコルの話ではありません。

ポートはプロトコルではない

OpenVPN を TCP 443 に移しても HTTPS にはなりません。プロキシは接続の冒頭で今も HTTP リクエストを期待し、OpenVPN クライアントは代わりにバイナリの制御メッセージを送ります。接続は、ログに有用なものが何も届かないため、ネットワーク遮断のように見える形で失敗します。

VPN のデータ経路に Cloudflare 製品を置くことが本当の要件なら、必要なプロトコルの対応を明記している製品を評価してください。オレンジ色の雲は特定の役割を持つウェブ通信のリバースプロキシなので、汎用の TCP や UDP トンネルだと考えないでください。

DNS のみのレコードが、確実に動く地味な答えであり、最初に手を伸ばすべきものです。

一台のマシンに今も二つのリスナーが必要

名前を分けても、二つのプロセスが同じアドレス、ポート、トランスポートを同時に束縛することはできません。ウェブサーバーがすでに全アドレスで TCP 443 を握っているなら、OpenVPN のインスタンスは意図的な取り決めなしに同じポートを取れません。

VPN リスナーを別のポートに、または別のアドレスに束縛するか、文書化されたマルチプレクサを前に置き、それに伴う運用コストを受け入れてください。どの選択も、誰も文書化していないリスナーこそ障害時に見落とされるものだから、ファイアウォールの規則に見えているべきです。選んだ束縛をトンネルを説明する同じランブックに書いてください。そうすれば次の人が午前二時に再発見せずに済みます。

証明書は守る接続に従う

ブラウザから Cloudflare への TLS 接続と、Cloudflare からオリジンへの接続は、二つの別々の証明書を持つ二つの別々の関係です。ブラウザが見るのはエッジ証明書です。オリジンは自分の証明書を Cloudflare に提示し、Cloudflare Origin CA 証明書はまさにその二つ目の関係のためにあります。

そのオリジン証明書は Full (strict) モードで Cloudflare に信頼され、一般に信頼されるブラウザ証明書ではありません。誰かが DNS のみのホスト名を直接訪れて警告を受けるのは、信頼の経路が変わった当然の結果であり、暗号化が止まった証拠ではありません。

そのため直接訪れられるウェブサイトには、そのブラウザが信頼する証明書チェーンが必要です。これは、オリジンをまったく訪れる想定のないプロキシされたサイトと共存できます。

OpenVPN は独自のサーバー ID とクライアント認証を、独自の認証局と独自の制御チャネル保護とともに持ちます。ウェブサイトの鍵アイコンはそのどれも提供せず、二つの用意の工程は分けたままにすべきです。

公開範囲は名前に従う

DNS のみの VPN レコードは、指し示すアドレスを公開します。そのアドレスがウェブのオリジンでもあるなら、オリジンは隠れておらず、もう一方の名前がプロキシされているから隠れていると説明するのは、誰かが走査するまで残る誤りです。

どのウェブリクエストがオリジンへ直接届いてよいかを決め、それをオリジンで強制し、そのうえで VPN リスナーを独自の条件で許可してください。管理ページ、プロファイルのダウンロード、データリスナーは、一つのパッケージが三つとも提供していても、三つの異なる公開要件を持てます。

生成されるリンクは公開ウェブ名と HTTPS スキームのままにし、クライアントプロファイルは VPN 名と実際のプロトコル、ポートのままにしてください。通常運用中に、どちらのサービスも相手のプロキシ設定を切り替えることに依存すべきではありません。

作業の順序は、サイトにプロキシされた名前、VPN に DNS のみの名前、別々のリスナー、関係ごとの証明書、そして各名前が本来のサービスだけに届くことを示す一つのテストです。