-
Notifications
You must be signed in to change notification settings - Fork 10.4k
[Spectrum] Adds a new ref page to the Spectrum docs #17621
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 1 commit
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| pcx_content_type: reference | ||
| title: Why Spectrum-enabled hostnames might appear in Layer 7 Analytics | ||
| weight: 0 | ||
|
|
||
| --- | ||
|
|
||
| Even when you have Spectrum enabled to handle Layer 4 traffic (for example, TCP/UDP connections), you may still notice traffic in your Layer 7 (L7) analytics dashboard. This is due to the way Cloudflare's Layer 7 CDN and Spectrum handle customer identity differently. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## How Spectrum identifies a user (Layer 4) | ||
|
|
||
| In Spectrum, the identity of the customer hostname is based on the Cloudflare IP address that the client uses to connect to the edge. Here is the typical process: | ||
|
|
||
| 1. Spectrum sets up a DNS hostname in the customer's zone that points to its Spectrum edge IP, and links this edge IP and port to the customer's configuration. | ||
| 2. The client (eyeball) performs a DNS lookup on the Spectrum hostname, retrieves the Spectrum edge IP, and connects to that IP and port. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| 3. Spectrum uses this edge IP and port to match the connection to the customer's configuration, identifying the customer. | ||
|
|
||
| This process focuses on Layer 4 associating a hostname and customer configuration around IP addresses and ports. | ||
|
|
||
| ## How the CDN identifies a user (Layer 7) | ||
|
|
||
| 1. The customer sets up a DNS hostname in their zone that directs traffic to their origin server. | ||
| 2. The client performs a DNS lookup on the CDN hostname, and the DNS server responds with a CDN edge IP. In contrast to Spectrum, the CDN edge IP is primarily used for traffic management rather than customer identity, as multiple customers can share the same CDN edge IP. | ||
|
|
||
| For the CDN, identifying the customer relies heavily on resolving hostnames during the TLS handshake (SNI) and the HTTP request (Host header). Notably, the CDN is designed to accept any hostname that matches the customer's zone (for example, `*.example.com`), even if there is no specific Layer 7 DNS match. This means that even Spectrum or Load Balancer hostnames will be accepted as valid under `*.example.com`. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ## The overlap: Layer 7 traffic being proxied through Spectrum | ||
|
|
||
| Because the CDN is designed to accept any hostname under your zone (for example, `spectrum.example.com`), HTTP traffic that should first be proxied by Spectrum, or even HTTP traffic meant for a Layer 4 only Spectrum app, may sometimes be processed directly by the Layer 7 CDN system. Here is how this happens: | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| 1. The client (eyeball) connects to a Layer 7 CDN edge IP while using the hostname of a Spectrum application (for example, spectrum.example.com) during both the TLS handshake and the HTTP request. Essentially, this means the client is attempting to access spectrum.example.com on an incorrect IP. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| 2. The CDN accepts this hostname as part of the customer zone during both the TLS and HTTP phases because it is designed to recognize any hostname under `*.example.com`. As a result, the request passes through the CDN under the zone's identity. | ||
| 3. However, when the CDN attempts to connect to the origin server, it performs an internal DNS lookup of the HTTP hostname, which resolves to the Spectrum IP (`spectrum.example.com` → Spectrum edge IP). Consequently, the CDN establishes an origin connection to Spectrum, loading its configuration and forwarding the request to the Spectrum origin. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| This means traffic for this hostname undergoes the standard Layer 7 CDN products, including Analytics and logs. | ||
|
|
||
| ## Blocking unwanted L7 Traffic | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| If you want to prevent traffic for layer 4 only Spectrum hostnames from being proxied through Layer 7 to your origin (including unwanted scans or requests), we recommend implementing a Layer 7 WAF (Web Application Firewall) rule. This rule can block traffic directed at specific hostnames or ports, ensuring that only legitimate traffic reaches your Spectrum service. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| For instance, you can create a WAF rule to block requests to `spectrum.example.com` unless they originate from a Spectrum IP or a customer's Spectrum BYOIP. The traffic will still be logged in Layer 7 Analytics, including WAF Security events, but this prevents it from arriving at the wrong address and looping through the CDN a second time. | ||
angelampcosta marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.