Spectrum 是在 Cloudflare 边缘节点上运行的全球 TCP 和 UDP 代理。它不会在应用层意义上终止连接。然而,在第 4 层,Spectrum 确实会在两个方向终止 TCP 和 UDP 套接字。TCP 段和 UDP 数据报的 L4 有效负载会在未做修改的情况下按原样来回传递。
这意味着 Spectrum 不会检查、修改或升级应用层协议。例如,Spectrum 无法将 HTTP 连接转换为 HTTPS、添加 HTTP 标头或将 WAF 规则应用于 TCP 流量。要添加 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 负载均衡器,但不会充当中间邮件服务器。相反,Spectrum 将数据传递到您的源站。邮件上显示的客户端 IP 将是 Cloudflare 边缘 IP。如果邮件服务器需要知道真实的客户端 IP,它应该使用代理协议 (Proxy Protocol) 从 Cloudflare 获取源 IP。Cloudflare 建议在配置为代理 SMTP 的应用程序上启用代理协议。
SMTP 服务器可能会对试图通过其发送消息的服务器执行一系列检查。这些检查旨在过滤来自非法服务器的请求。
如果出现以下情况,消息可能会被拒绝:
- 对连接服务器 IP 地址的反向 DNS 查找返回否定响应。
- 反向 DNS 查找产生的主机名与 SMTP
HELO/EHLO消息中发送的主机名不同。 - 反向 DNS 查找产生的主机名与您的 SMTP 服务器横幅中通告的主机名不同。
- 反向 DNS 查找的结果与相应的正向 DNS 查找不匹配。
Spectrum 应用程序没有反向 DNS 条目。
此外,SMTP 服务器可能会执行 DNS 查找来找到域名的 MX 记录。如果您的域名的 MX 记录与 Spectrum 应用程序关联,则来自您的服务器的消息可能会被拒绝,因为服务器的 IP 地址与 Spectrum IP 地址不匹配。
Cloudflare 支持所有 TCP 端口。
Spectrum 应用程序可以配置为代理一系列端口上的流量。
对于直接源站 (direct origins):
{
"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 访问规则,Cloudflare 将遵守为该域名配置的 IP 访问规则。Cloudflare 仅遵守为特定 IP 地址、IP 块、国家或 ASN 创建的用于 Spectrum 应用程序的规则。Spectrum 也仅遵守使用 allow(允许)或 block(阻止)操作创建的规则。
为您的应用程序启用 Argo Smart Routing 后,流量将自动通过可用且最快、最可靠的网络路径进行路由。Argo Smart Routing 适用于 TCP 和 UDP(测试版)应用程序。
Spectrum 应用程序可以通过 Cloudflare Tunnel 虚拟网络将 origin_direct 流量路由到专用源站。在应用程序上将 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必须恰好包含一个地址。不支持多个地址。- 源端口必须是单个端口。不支持端口范围。
- 源 IP 必须在指定的虚拟网络内可路由。虚拟网络必须已经有一个覆盖该 IP 的路由。
- 不支持 Proxy Protocol。
proxy_protocol必须设置为off。
有关违反这些限制时返回的验证错误代码,请参考错误代码。
Spectrum 虚拟网络源站仅适用于 TCP 和 UDP 流量。对于到专用源站的 HTTP/HTTPS 流量,请使用私有源站应用程序服务,它提供 WAF、CDN 缓存和完整的 Cloudflare 代理堆栈。
如果您为 Spectrum 应用程序启用 Edge TLS Termination(边缘 TLS 终止),Cloudflare 将在边缘加密应用程序的流量。Edge TLS Termination(边缘 TLS 终止) 切换开关仅适用于 TCP 应用程序。
Spectrum 提供三种 TLS 终止模式:Flexible(灵活)、Full(完全) 和 Full (Strict)(完全严格)。
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 端点。
以下是 Cloudflare 在 SSL/TLS 握手期间提供给源站的密码套件。有关我们的边缘支持的密码套件或提供给浏览器和其他用户代理的密码套件,请参考 密码套件。
以下密码套件根据它们在 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