pantherra commented on PR #922:
URL:
https://github.com/apache/apisix-helm-chart/pull/922#issuecomment-4600475623
@Baoyuantop Hello! I did it intentionally because:
1. Backend Support is Required
You cannot send a PPv2 header to a standard HTTP/S server unless that server
(or a reverse proxy in front of it like NGINX, HAProxy, or Envoy) is explicitly
configured to parse the PROXY protocol. If an unmodified web server receives a
binary PPv2 header, it will treat it as part of the actual HTTP request
payload, which will either break the request or cause the TLS handshake to fail.
2. Port Sharing Restrictions
If your backends need to accept both regular HTTP traffic and
PROXY-forwarded traffic, they must listen on separate ports. You cannot mix raw
client traffic and PPv2 traffic on the exact same port unless your server
utilizes a specialized listener capable of auto-detecting and demultiplexing
the PROXY protocol signature from incoming bytes.
OCI & Apache APISIX Test Case
I verified this behavior while testing within the Oracle Cloud
Infrastructure (OCI) environment using Apache APISIX tightly coupled with a
cloud load balancer (L4 or L7).
- The Setup: When you provision a Kubernetes Service via annotations, you
define the type of cloud load balancer OCI creates—either an L4 load balancer
with PPv2 support or an L7 load balancer without it.
- The Conflict: If you configure the OCI load balancer with PPv2 support via
annotations, the backend service (APISIX's NGINX) must explicitly expect a PPv2
handshake on those designated ports. If it doesn't, NGINX will reject the
connection and break all incoming traffic.
- The Outcome: Because port sharing is impossible here, you must set up
dedicated ports and a dedicated service for PPv2. To preserve plain HTTP/S
traffic, you have to spin up a completely separate L7 cloud load balancer
pointing to a different Kubernetes Service and APISIX NGINX ports. This
ultimately results in two distinct public IP addresses. Therefore, enabling
PROXY Protocol v2 essentially replaces standard HTTP/S handling on those entry
points rather than complementing it.
The East-West Traffic Problem
The biggest issue I observed with a global, ingress-wide PPv2 setup involves
East-West (inter-cluster) traffic:
If you target an Ingress that has PPv2 enabled globally, internal
cluster communication will fail. The internal Kubernetes routing mechanism
short-circuits the traffic and bypasses the cloud load balancer entirely.
Consequently, the internal service receives plain HTTP/S traffic without the
expected PPv2 initial handshake. Because APISIX's NGINX cannot parse this raw
traffic on a PPv2-designated port, the connection fails.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
