Add a proxy for wsl integration #15

Nino-K · 2024-01-23T21:29:54Z

This commit introduces a proxy server that actively listens in the default network, capturing all incoming requests destined for the Kubernetes API server within the network namespace.

Related to: rancher-sandbox/rancher-desktop#6245
Fixes: rancher-sandbox/rancher-desktop#6359

mook-as

It's unclear why this is scoped as it is (and it's not clearly documented).

mook-as · 2024-01-23T21:36:43Z

README.md

+```
+## wsl-proxy
+Its primary function comes into play when WSL integration is activated alongside the network tunnel. The purpose is to actively listen on `127.0.0.1:6443` and reroute all incoming requests to the upstream Kubernetes API server residing within the network namespace. The proxy achieves this by directing the incoming traffic through a Virtual Ethernet pair. Specifically, `veth-rd0` serves as the originating end listening in the default network, while `veth-rd1` acts as the terminating end within the network namespace.


and reroute all incoming requests to the upstream Kubernetes API server residing within the network namespace

It also routes non-Kubernetes things, right? (Think random containers)

It routes anything that is destined for K8s API server at 127.0.0.1:6443.

mook-as · 2024-01-23T21:38:33Z

README.md

+```
+## wsl-proxy
+Its primary function comes into play when WSL integration is activated alongside the network tunnel. The purpose is to actively listen on `127.0.0.1:6443` and reroute all incoming requests to the upstream Kubernetes API server residing within the network namespace. The proxy achieves this by directing the incoming traffic through a Virtual Ethernet pair. Specifically, `veth-rd0` serves as the originating end listening in the default network, while `veth-rd1` acts as the terminating end within the network namespace.


This needs to somehow document what is doing work on veth-rd1, since wsl-proxy sounds like it runs within the default namespace (and needs something on the other end to help it).

cmd/proxy/wsl_integration_linux.go

mook-as

Slight doc changes.

mook-as · 2024-01-26T17:30:01Z

README.md

@@ -47,7 +47,7 @@ portForwarding["Port Forwarding"]
 `host-switch` runs on the Windows host and acts as a receiver for all traffic originating from the network namespace within the WSL VM. It performs a handshake to find the right VM to talk to over `AF_VSOCK`. Once a correct VM is found, it then listens for the incoming traffic from that VM. In additon to this, it can provide a DNS resolver that runs in the user space network along with an API that allows for dynamic port forwarding.

 ## network-setup
-Its main responsibility is to respond to the handshake request from the `host-switch.exe`, create a network namespace and start the `vm-switch` subprocess in the newly created network namespace. In addition, it also calls unshare with provided arguments through `--unshare-args`. Below is a sequence diagram demonstrating the process.
+Its main responsibility is to respond to the handshake request from the `host-switch.exe`, create a network namespace and start the `vm-switch` subprocess in the newly created network namespace. In addition, it also calls unshare with provided arguments through `--unshare-args`. Below is a sequence diagram demonstrating the process. The process also establishes a Virtual Ethernet pair consisting of two endpoints: veth-rd0 and `veth-rd1`. `veth-rd0` resides within the default namespace and is configured to listen on the IP address `192.168.1.1`. Conversely, `veth-rd1` is located within a network namespace and is assigned the IP address `192.168.1.2`.


Suggested change

Its main responsibility is to respond to the handshake request from the `host-switch.exe`, create a network namespace and start the `vm-switch` subprocess in the newly created network namespace. In addition, it also calls unshare with provided arguments through `--unshare-args`. Below is a sequence diagram demonstrating the process. The process also establishes a Virtual Ethernet pair consisting of two endpoints: veth-rd0 and `veth-rd1`. `veth-rd0` resides within the default namespace and is configured to listen on the IP address `192.168.1.1`. Conversely, `veth-rd1` is located within a network namespace and is assigned the IP address `192.168.1.2`.

Its main responsibility is to respond to the handshake request from the `host-switch.exe`, create a network namespace and start the `vm-switch` subprocess in the newly created network namespace. In addition, it also calls unshare with provided arguments through `--unshare-args`. Below is a sequence diagram demonstrating the process. The process also establishes a Virtual Ethernet pair consisting of two endpoints: `veth-rd0` and `veth-rd1`. `veth-rd0` resides within the default namespace and is configured to listen on the IP address `192.168.1.1`. Conversely, `veth-rd1` is located within a network namespace and is assigned the IP address `192.168.1.2`.

mook-as · 2024-01-26T17:32:28Z

README.md

+```
+## wsl-proxy
+Its primary function comes into play when WSL integration is activated alongside the network tunnel. The purpose is to actively listen on `127.0.0.1:6443` and reroute all incoming requests to the upstream Kubernetes API server residing within the network namespace. Although, in the future this coponent will expand to proxy non k8s API traffic (e.g container traffic into the namespace) The proxy achieves this by directing the incoming traffic through a Virtual Ethernet pair. Specifically, `veth-rd0` serves as the originating end listening in the default network, while `veth-rd1` acts as the terminating end within the network namespace.


I think the last bit is better phrased as

The proxy uses 192.168.1.2:6443 as its upstream, which is the veth-rd1 interface created by network-setup.

Nothing in the wsl-proxy process actually deals with veth.

cmd/proxy/wsl_integration_linux.go

mook-as · 2024-01-29T21:23:44Z

Makefile

+bin/wsl-proxy:
+	GOOS=linux go build $(LDFLAGS) -o $@ ./cmd/proxy


Hmm, it's kind of odd that the directory named proxy produces a binary named wsl-proxy (instead of proxy). But that's an issue we also have with all the other commands…

mook-as · 2024-01-29T21:29:01Z

cmd/proxy/wsl_integration_linux.go

+	TargetURL *url.URL
+}
+
+// handleRequestAndRedirect Copies the original request headers to the new request,


Suggested change

// handleRequestAndRedirect Copies the original request headers to the new request,

// handleRequestAndRedirect copies the original request headers to the new request,

mook-as · 2024-01-29T21:29:15Z

cmd/proxy/wsl_integration_linux.go

+}
+
+// handleRequestAndRedirect Copies the original request headers to the new request,
+// and updates the request URL to the target URL. It then Performs the request to


Suggested change

// and updates the request URL to the target URL. It then Performs the request to

// and updates the request URL to the target URL. It then performs the request to

mook-as · 2024-01-29T21:31:36Z

cmd/proxy/wsl_integration_linux.go

+	}
+}
+
+type requestHandler struct {


Is there a reason we're not using httputil.ReverseProxy? I'm mostly thinking about annoying bits like websocket / upgrade support (which ends up being used for logs and things, I think).

Is there a reason we're not using httputil.ReverseProxy? I'm mostly thinking about annoying bits like websocket / upgrade support (which ends up being used for logs and things, I think).

Is there going to be websocket? this proxy is meant to only talk to k8s API endpoint and I think that is mostly https. However, it wouldn't hurt to use httputil.ReverseProxy.

mook-as · 2024-01-31T17:51:47Z

cmd/proxy/wsl_integration_linux.go

+	http.HandleFunc("/", func(writer http.ResponseWriter, request *http.Request) {
+		proxy.ServeHTTP(writer, request)
+	})


Is there a reason this isn't just

http.ListenAndServe(listenAddr, proxy)

This commit introduces a proxy server that actively listens in the default network, capturing all incoming requests destined for the Kubernetes API server within the network namespace. Signed-off-by: Nino Kodabande <[email protected]>

Signed-off-by: Nino Kodabande <[email protected]>

mook-as · 2024-01-31T18:09:12Z

cmd/proxy/wsl_integration_linux.go

+	if err != nil {
+		logrus.Error("Error starting server:", err)
+	}


FWIW, the docs says:

ListenAndServe always returns a non-nil error.

But I don't think that's an issue here.

Nino-K requested a review from mook-as January 23, 2024 21:30

mook-as suggested changes Jan 23, 2024

View reviewed changes

Nino-K mentioned this pull request Jan 23, 2024

Epic: Kubeconfig in WSL should be a symlink to the host file rancher-sandbox/rancher-desktop#6245

Closed

6 tasks

Nino-K force-pushed the add-wsl-integration-proxy branch 2 times, most recently from 21eeac6 to 9340943 Compare January 25, 2024 17:26

Nino-K requested a review from mook-as January 25, 2024 17:26

mook-as suggested changes Jan 26, 2024

View reviewed changes

Nino-K requested a review from mook-as January 29, 2024 17:52

This was referenced Jan 29, 2024

Add wsl-proxy to RD Networking rancher-sandbox/rancher-desktop-wsl-distro#84

Merged

[Do not merge] Runs wsl-proxy in the default namespace rancher-sandbox/rancher-desktop#6388

Merged

mook-as suggested changes Jan 29, 2024

View reviewed changes

Nino-K force-pushed the add-wsl-integration-proxy branch from 78dc380 to ce59765 Compare January 31, 2024 17:30

Nino-K requested a review from mook-as January 31, 2024 17:31

mook-as suggested changes Jan 31, 2024

View reviewed changes

Nino-K added 3 commits January 31, 2024 10:06

Add a proxy for wsl integration

3922a5d

This commit introduces a proxy server that actively listens in the default network, capturing all incoming requests destined for the Kubernetes API server within the network namespace. Signed-off-by: Nino Kodabande <[email protected]>

Update README

4e254d5

Signed-off-by: Nino Kodabande <[email protected]>

Update README

3e7b8b6

Signed-off-by: Nino Kodabande <[email protected]>

Nino-K force-pushed the add-wsl-integration-proxy branch from ce59765 to 3e7b8b6 Compare January 31, 2024 18:06

mook-as approved these changes Jan 31, 2024

View reviewed changes

Nino-K merged commit 7853cfc into main Jan 31, 2024
2 checks passed

Nino-K deleted the add-wsl-integration-proxy branch January 31, 2024 18:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a proxy for wsl integration #15

Add a proxy for wsl integration #15

Nino-K commented Jan 23, 2024 •

edited

Loading

mook-as left a comment

mook-as Jan 23, 2024

Nino-K Jan 24, 2024

mook-as Jan 23, 2024

mook-as left a comment

mook-as Jan 26, 2024

mook-as Jan 26, 2024

mook-as Jan 29, 2024

mook-as Jan 29, 2024

mook-as Jan 29, 2024

mook-as Jan 29, 2024

Nino-K Jan 31, 2024

mook-as Jan 31, 2024

mook-as Jan 31, 2024

		bin/wsl-proxy:
		GOOS=linux go build $(LDFLAGS) -o $@ ./cmd/proxy

	// handleRequestAndRedirect Copies the original request headers to the new request,
	// handleRequestAndRedirect copies the original request headers to the new request,

	// and updates the request URL to the target URL. It then Performs the request to
	// and updates the request URL to the target URL. It then performs the request to

Add a proxy for wsl integration #15

Add a proxy for wsl integration #15

Conversation

Nino-K commented Jan 23, 2024 • edited Loading

mook-as left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mook-as left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nino-K commented Jan 23, 2024 •

edited

Loading