Spectrum は、Cloudflare のエッジノード上で動作するグローバルな TCP および UDP プロキシです。アプリケーション層の意味では接続を終端しません。ただしレイヤー 4 では、Spectrum は双方向の TCP および UDP ソケットを終端します。TCP セグメントと UDP データグラムの L4 ペイロードは、変更せずそのまま受け渡します。
つまり Spectrum は、アプリケーション層プロトコルの検査、変更、アップグレードを行いません。たとえば、HTTP 接続を HTTPS に変換したり、HTTP ヘッダーを追加したり、TCP トラフィックに WAF ルールを適用したりはできません。CDN、Workers、Bot Management などのレイヤー 7 機能を追加するには、アプリケーションタイプ を HTTP/HTTPS に設定します。
よくある問題とトラブルシューティングは Spectrum のトラブルシューティング を参照してください。
アプリケーションタイプは、エッジからオリジンへデータが送られるプロトコルを決めます。オリジンへ直接プロキシする場合は TCP/UDP を選びます。CDN、Workers、Bot Management などの製品を設定する場合は、HTTP/HTTPS を選ぶ必要があります。この場合、トラフィックはオリジンへ直接接続せず、Cloudflare のパイプラインを経由します。
Spectrum アプリケーションを作成すると、一意の IPv4 と IPv6 アドレスが割り当てられます。IPv6 のみでプロビジョニングすることもできます。アドレスは静的ではなく、時間とともに変わることがあります。現在のアドレスを調べる最善の方法は DNS です。Spectrum アプリケーションの DNS 名は、そのアプリケーションに現在割り当てられている IP を常に返します。
これらのアドレスは、中国のデータセンターを除くすべての Cloudflare データセンターから Anycast されます。
Spectrum は SMTP サーバーの手前で TCP ロードバランサーとして動作できますが、中継メールサーバーとしては動作しません。代わりに、データをオリジンへそのまま渡します。メールに表示されるクライアント IP は、Cloudflare エッジの IP です。メールサーバーが実際のクライアント IP を必要とする場合は、Proxy Protocol を使って Cloudflare から送信元 IP を取得してください。SMTP をプロキシするアプリケーションでは、Proxy Protocol を有効にすることを推奨します。
SMTP サーバーは、メッセージ送信を試みるサーバーに対して一連のチェックを行うことがあります。これらのチェックは、不正なサーバーからのリクエストを除外するためのものです。
次の場合、メッセージが拒否されることがあります。
- 接続元サーバーの IP アドレスに対する逆引き DNS が否定的な結果を返す。
- 逆引き DNS の結果が、SMTP の
HELO/EHLOメッセージで送られたホスト名と異なる。 - 逆引き DNS の結果が、SMTP サーバーのバナーで告知しているホスト名と異なる。
- 逆引き DNS の結果が、対応する正引き DNS と一致しない。
Spectrum アプリケーションには逆引き DNS エントリがありません。
さらに、SMTP サーバーはドメインの MX レコードを探すために DNS ルックアップを行うことがあります。ドメインの MX レコードが Spectrum アプリケーションに関連付けられていると、サーバーの IP アドレスが Spectrum の IP アドレスと一致しないため、自サーバーからのメッセージが拒否されることがあります。
Cloudflare はすべての TCP ポートに対応します。
Spectrum アプリケーションは、ポート範囲のトラフィックをプロキシするよう設定できます。
直接オリジンの場合:
{
"protocol": "tcp/1000-2000",
"dns": {
"type": "CNAME",
"name": "range.example.com"
},
"origin_direct": ["tcp://192.0.2.1:3000-4000"]
}DNS オリジンの場合:
{
"protocol": "tcp/1000-2000",
"dns": {
"type": "CNAME",
"name": "range.example.com"
},
"origin_dns": {
"name": "origin.example.com",
"ttl": 1200
},
"origin_port": "3000-4000"
}オリジンのポート範囲に含まれるポート数は、protocol フィールドで指定したポート数と一致する必要があります。
エッジのポート範囲内のあるポートへの接続は、オリジン範囲内の同じオフセットのポートへプロキシされます。
たとえば上記の設定では、range.example.com:1005 への接続はオリジンのポート 3005 へプロキシされます。
Spectrum アプリケーションで IP Access rules が有効な場合、Cloudflare はそのドメインに設定された IP Access rules を尊重します。Spectrum アプリケーションで尊重されるのは、特定の IP アドレス、IP ブロック、国、または ASN 向けに作成したルールだけです。また、アクションが allow または block のルールだけが対象です。
アプリケーションで Argo Smart Routing を有効にすると、トラフィックは利用可能な最も速く信頼性の高いネットワーク経路を自動で通ります。Argo Smart Routing は TCP および UDP(ベータ)アプリケーションで利用できます。
Spectrum アプリケーションは、origin_direct トラフィックを Cloudflare Tunnel の 仮想ネットワーク 経由でプライベートオリジンへルーティングできます。アプリケーションの virtual_network_id に、オリジン IP がその中で到達可能な仮想ネットワークの ID を設定します。アプリケーションへのトラフィックは、その仮想ネットワークに関連付けられたコネクタ(通常は Cloudflare Tunnel または Cloudflare WAN(旧称 Magic WAN)接続)を経由して配信されます。
仮想ネットワークを作成し、オリジン IP をカバーするルートを付与する手順は、仮想ネットワークを管理する と IP/CIDR を接続する を参照してください。
virtual_network_id を設定した場合、次の制限が適用されます。
- アプリケーションタイプは TCP または UDP である必要があります。HTTP/HTTPS アプリケーションは仮想ネットワークオリジンに対応していません。
- オリジンは
origin_directで指定する必要があります。ホスト名オリジン(origin_dns)は非対応です。 origin_directにはアドレスをちょうど 1 つ含める必要があります。複数アドレスは非対応です。- オリジンポートは単一ポートである必要があります。ポート範囲は非対応です。
- オリジン IP は、指定した仮想ネットワーク内で到達可能である必要があります。仮想ネットワークには、その IP をカバーするルートがすでに必要です。
- Proxy Protocol は非対応です。
proxy_protocolはoffに設定する必要があります。
これらの制約に違反したときに返るバリデーションエラーコードは、エラーコード を参照してください。
Spectrum の仮想ネットワークオリジンは、TCP および UDP トラフィック専用です。プライベートオリジンへの HTTP/HTTPS トラフィックには、Application Services for Private Origins を使います。WAF、CDN キャッシュ、Cloudflare プロキシスタック全体を利用できます。
Spectrum アプリケーションで Edge TLS Termination を有効にすると、Cloudflare はエッジでそのアプリケーションのトラフィックを暗号化します。Edge TLS Termination の切り替えは、TCP アプリケーションにのみ適用されます。
Spectrum の TLS 終端モードは 'Flexible'、'Full'、'Full (Strict)' の 3 つです。
'Flexible' はエッジでクライアント接続を終端しますが、Cloudflare からオリジンへの TLS は有効にしません。クライアントから Cloudflare へは暗号化されますが、Cloudflare からオリジンへは暗号化されません。
'Full' は、Cloudflare からオリジンへのトラフィックも暗号化しますが、証明書の検証は行いません。'Full (Strict)' に設定すると、Cloudflare からオリジンへのトラフィックも暗号化され、オリジン証明書を厳格に検証します。
Spectrum が対応する TLS バージョンは、TLS 1.1、TLS 1.2、TLS 1.3 です。
Cloudflare ダッシュボードの Spectrum アプリ、または Spectrum API エンドポイント で管理できます。
以下は、SSL/TLS ハンドシェイク時に Cloudflare がオリジンへ提示する暗号スイートです。エッジで対応している暗号スイート、またはブラウザなどのユーザーエージェントへ提示する暗号スイートは、暗号スイート を参照してください。
以下の暗号スイートは ClientHello に現れる順で並んでおり、オリジンへ優先順位を伝えています。Spectrum が使う暗号を、お客様が変更することはできません。
| OpenSSL 名 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|
| AEAD-AES128-GCM-SHA2561 | ❌ | ❌ | ✅ |
| AEAD-AES256-GCM-SHA3841 | ❌ | ❌ | ✅ |
| AEAD-CHACHA20-POLY1305-SHA2561 | ❌ | ❌ | ✅ |
| ECDHE-ECDSA-AES128-GCM-SHA256 | ❌ | ✅ | ❌ |
| ECDHE-RSA-AES128-GCM-SHA256 | ❌ | ✅ | ❌ |
| ECDHE-RSA-AES128-SHA | ✅ | ✅ | ❌ |
| AES128-GCM-SHA256 | ❌ | ✅ | ❌ |
| AES128-SHA | ✅ | ✅ | ❌ |
| AES256-SHA | ✅ | ✅ | ❌ |
-
TLS 1.3 は以前の TLS と同じ暗号スイート空間を使いますが、TLS 1.3 の暗号スイートは定義が異なり、対称暗号だけを指定し、TLS 1.2 では使えません。同様に、TLS 1.2 以下の暗号スイートは TLS 1.3 では使えません(RFC 8446 ↗)。BoringSSL も TLS 1.3 ではこの順で暗号の優先順位をハードコードしています。詳細は TLS 1.3 の暗号スイート を参照してください。 ↩ ↩2 ↩3