From 448bdb17361aeb7e63fcce5e840dc6c917e2207c Mon Sep 17 00:00:00 2001 From: Sheogorath <sheogorath@shivering-isles.com> Date: Sat, 6 Jan 2024 02:02:36 +0100 Subject: [PATCH] docs: Minor rewording in ingress-termination docs --- docs/src/concepts/ingress-termination.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/src/concepts/ingress-termination.md b/docs/src/concepts/ingress-termination.md index b96c04fab..8327eff99 100644 --- a/docs/src/concepts/ingress-termination.md +++ b/docs/src/concepts/ingress-termination.md @@ -1,12 +1,12 @@ # Ingress Termination -The Shivering-Isles Infrastructure, given it's a local-first infrastructure has challenges in order to optimise traffic flow for local devices, without breaking external access. +The Shivering-Isles Infrastructure, given it's a local-first infrastructure has challenges to optimise traffic flow for local devices, without breaking external access. ## TCP Forwarding A intentional design decision was to avoid split DNS. Given that all DNS is hosted on Cloudflare with full DNSSEC integration, as well as running devices with active DoT always connecting external DNS Server, made split-DNS a bad implementation. -At the same time, a simple rerouting of all traffic to the external IP would also be problementatic, as it would require either a dedicated IP address or complex source-based routing in order to only route traffic for client networks while allowing VPN traffic to continue to flow to the VPS. +At the same time, a simple rerouting of all traffic to the external IP would also be problematic, as it would require either a dedicated IP address or complex source-based routing to only route traffic for client networks while allowing VPN traffic to continue to flow to the VPS. The solution most elegant solution found was to reroute traffic on TCP level. Allow high volume traffic on port 443 to be rerouted using a firewall rule, while keeping the remote IP identical and not touching any VPN or SSH traffic in the process. @@ -18,10 +18,10 @@ In both cases the connections are terminated on the Kubernetes Cluster. The exte Since only TCP connections are forward at any point all TLS termination takes place on the Kubernetes cluster regardless. -## Keeping IP addresses +## Preserving source IP addresses -On the VPS, the TCP connection is handled by an HAProxy instance that speaks proxy-protocol with the Kubernetes ingress service. +On the VPS, the TCP connection is handled by an HAProxy instance that speaks [proxy-protocol](https://www.haproxy.com/blog/use-the-proxy-protocol-to-preserve-a-clients-ip-address) with the Kubernetes ingress service. -On the Unifi Dream Machine it's a simple iptables rule, which redirects the traffic. In order to also use proxy-protocol with the ingress service, it's actually redirected to an HAProxy running in the Kubernetes cluster besides the ingress-nginx. This is mainly due to the limitation in ingress-nginx that doesn't allow mixed proxy-protocol and non-proxy-protocol ports without using custom config templates. +On the Unifi Dream Machine it's a simple iptables rule, which redirects the traffic. In order to also use proxy-protocol with the ingress service, it's actually redirected to an HAProxy running in the Kubernetes cluster besides the ingress-nginx. This is mainly due to the limitation in ingress-nginx that doesn't allow mixed proxy-protocol and non-proxy-protocol ports without using custom configuration templates.  \ No newline at end of file -- GitLab