wsl-vpnkit VS gvisor

Mirrored network mode sounds quite a lot like what wsl-vpnkit does: https://github.com/sakai135/wsl-vpnkit

This came from Docker Desktop for Windows, where they needed a solution for VPNs like GlobalProtect and AnyConnect that are often configured to drop packets for networks that aren't the main one associated with the VPN.

I'm going to wait a while to see how the new VPN stuff works out. Previously WSL2 didn't work with a Windows VPN without an extra tool ( https://github.com/sakai135/wsl-vpnkit ), hopefully this might fix things, but not going to risk trying it in case it breaks everything.

https://github.com/sakai135/wsl-vpnkit fixes that problem for me, and is less annoying than other fixes I tried

So i installed warp on windows and try to run go mod init to access few packages from my org private repo, and it says the repo not found, So i search and found that WSL 2 need this for Zero Trust to run on WSL 2 : https://github.com/sakai135/wsl-vpnkit , I've download and started the service but it still can't access the repo, does anyone has this problem when developing go with zero trust ?

There's also a reference to https://github.com/sakai135/wsl-vpnkit, which looks like a much more ambitious effort to deal with this.

If it works at all like WSL, you might want to look at wsl-vpnkit.

https://github.com/sakai135/wsl-vpnkit

It's not a proxy, but would give some idea how to shim into the middle.

there's a fix for that! https://github.com/sakai135/wsl-vpnkit

Have you tried wsl-vpnkit?

Isn't gVisor kind of this as well?

"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."

https://github.com/google/gvisor

This sort of feels like seeing someone riding a bike and saying: why don’t they just get a car? The simple fact is that containers and VMs are quite different. Whether something uses VMX and friends or not is also a red herring, as gVisor also “rolls it own VMM” [1].

[1] https://github.com/google/gvisor/tree/master/pkg/sentry/plat...

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

It uses gVisor to create a TCP/IP stack in userspace, and starts a wireguard interface on it, which the HTTP server from http.Serve listens on. The library will print a URL after startup, where you can access your server. You can create multiple listeners in one binary.

The playground compiles the program with GOOS=linux, GOARCH=amd64 and runs the program with gVisor. Detailed documentation is available at the gVisor site.

You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).