OpenVPNクライアントをCloudflare経由でルーティングする？まず役割を確認する
デバイスクライアントはルーターではありません。Cloudflareの役割が他のホストのパケットを転送することを確認し、サーバー自身のトンネルは元の経路に保ちます。
動作している OpenVPN サーバーと、Cloudflare のデバイスソフトウェアも実行するホストがあり、次の明白な手順はクライアントのトラフィックをそちらへ向けることのように見えます。一台のマシン上の二つの動作する接続は、トランジットゲートウェイにはなりません。欠けているのは、他人に属するパケットを転送するために文書化された役割と、それらのパケットが到着したときに分類するポリシーです。
どのルールよりも先に四つの問いがあります：どのトラフィックが入り、次にどこへ行き、応答がどう戻り、その第二の経路が失敗したときに設計がどう振る舞うかです。最初の二つは能力の問いです。
一つのホスト上の二つのサービスはトランジット経路ではない
デバイスクライアントは、それが動作するマシンで発生するトラフィックを扱うために作られています。名前解決、または選択されたアプリケーションのトラフィックを傍受し、自身のトンネルを通して送り、そのポリシーはそのデバイスのユーザーとプロセスのために書かれています。OpenVPN クライアントから転送されたパケットはローカルの出力ではないため、同じルールでは分類されません。これはより広いルールで覆い隠せる設定の細部ではなく、ソフトウェアがそのパケットをそもそも見るかどうかを決めるものです。
だからこそ設計の問いは能力の問いです。インストールされた製品に他のネットワーク向けのトラフィックを転送する文書化された役割があるか、トランジット機能がまったく別の場所に属するかのどちらかです。
どの Cloudflare の役割が転送を許されるか
Cloudflare のデバイスクライアントは範囲の異なるモードを提供します：名前解決のみ、デバイスからのトラフィック、そして場合によっては両方です。これらのモードのいずれも、別のトンネル経由で到着するプライベート範囲に対してホストをルーターに変えることはありません。専用のルーティング役割は、独自のコネクター、登録、ネットワークモデルを持つ別製品です。
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
その周りにルートを設計する前に、インストールされた役割を確認してください。コネクターがどのインターフェースを作成するか、特定のプレフィックスを広告するのかデフォルトルートを広告するのか、ローカルポリシーがローカルのパケットだけでなく転送されたパケットにも適用されるかを読み取ってください。ローカルのトラフィックだけが処理されるなら、翻訳ルールがどう書かれていても、OpenVPN サーバーはトランジットポイントになれません。
ここでパブリックな出口の要件を正確に述べる必要もあります。転送されたクライアントトラフィックのために Cloudflare が提供する出口は特定のユースケースであり、実際に持っているサービスに対して確認する必要があります。
外側のトンネルを新しいルートから独立させる
新しいインターフェースへのデフォルトルートを追加した瞬間、サーバー自身の外向きトラフィックがそれを取り合い始めます、これには OpenVPN クライアントへの応答と、マシンへの SSH セッションも含まれます。よくある症状は、確立した後に死ぬトンネル、または変更が成功したように見える間に締め出される管理者です。エンドポイントに対して ip route get を変更前と変更後で比較し、ポリシールーティングまたはホストルートを使ってサーバー自身の通信を元の場所に留めてください。その比較はマシン自体から実行してください、サーバー自身のルートに対する見方が重要なのです。
サーバーのパブリックアドレスに対する例外だけでは不十分です、各リモート管理者の戻り経路は別のフローだからです。それらのフローのどれが変更を生き延びなければならないかを決め、最初のものが残りをカバーすると仮定するのではなく、それぞれを検証してください。
転送と翻訳を一つのフローに限定する
受信したパケットはローカルの出力経路ではなく転送経路をたどるため、重要なルールは forward フックにあります。次のインターフェースが翻訳を必要とする場合、送信元をクライアントプールに、宛先を許可されたものに、出口をその単一のインターフェースに限定してください。インターフェースだけに紐づいた masquerade ルールは、それ自体ではルートを選ばず、他のどのフィルターも越えて転送を許可しません。
失敗時に閉じる挙動をあらかじめ決め、それからテストしてください。次の経路を止め、クライアントが通常のアップリンクへ静かに戻るのではなく、意図した出口を失うことを確認してください、トラフィックが間違った扉から出るまで誰も気づかないのは、まさにその結果です。名前解決と IPv6 についても確認を繰り返してください、v4 だけのルールセットでは v6 の経路が開いたままになるからです。
落ち着いた四つの答えと、それぞれを裏付ける観察を書き留めてください。説明できるトランジット経路は、次のインシデントレビューで弁護できる経路です。