Initial setup while on VPN

[andyneff]

Option 1

I really want to add solution that integrates the idea behind sakai135/wsl-vpnkit#11. Using that download function, we can download the required packages via powershell while on VPN, then install them.

Since we would be manually downloading and installing packages, we'd need to know the exact URLs for each package. Typically, package repos keep the "first" original version of a package around forever (from when that OS version was released), while replacing only the latest versions of the packages on the repo. So hard coding the URLs for the original versions should work.

The problem where I get "lost" is where do you think we should draw the line on OSes that we support for this? Should we just pick one or two (I'm thinking Ubuntu 20.04 and maybe Alpine if I can get that working), and say that's it for the automatic install? Or not try at all? Or just try and support as many as possible? A few debians, some fedoras, centos, ubuntus, etc... Anything not EOLed?

• I think trying to support a lot of versions will result in "at least one" breaking often. Even with CI, this is a nightmare to maintain

Option 2

I do have one "out there" alternative... If we can get alpine (or any small OS) to work

1. (We do this once) We could just preinstall what is needed for alpine
2. (We do this once) Export that WSL image (which should be tiny), and upload it like you did with wslbin.tar.gz
3. When the script detects it need dependencies but is on VPN
   1. It would download that WSL image
   2. Add that downloaded image to WSL, call it bootstrap_wsl_vpn or something.
   3. Start up the VPNkit fix from bootstrap_wsl_vpn
   4. Use VPN Kit running in bootstrap_wsl_vpn in the current WSL to apt install the packages we need
   5. Shutdown and remove bootstrap_wsl_vpn
   6. Continue setting up like normal

I think I like Option 2.

@AmmarRahman, thoughts? An option 3?

[AmmarRahman]

My developer instinct was instantly drawn to Option 2. However, this would require that the users already have docker installed on their machines. in which case, we can just have that downloaded through a docker run.
With Option 1, we can still download the wslbin.tar.gz from within this repo. I'm happy to update the version every 2-3 months.

However, taking in consideration that our audience is limited to corporate users who uses WSL2, its a relatively small user subset. The majority of those, would be using a Debian based distribution or Sues/Fedora which are provided on the Microsoft store. Me personally, I would draw the line there in terms of OS. If someone is installing a custom distribution, I would be comfortable assuming that they can adapt our script to their need.

That said, I do not intend to create too much work from this solution since it's only meant to last until Microsoft comes up with a proper fix for that.

[andyneff]

I think we are on the same page!

When I get the time, I'll attempt a go at option 2. My idea was to just "include" a recent version of the files in there (or maybe even use wslbin.tar.gz itself) that way we won't need to worry about the "docker or not" question. This is only to bootstrap the process and get the dependencies installed, and will be thrown away as soon as the setup script finishes. So I feel less concerned with the possibility of using a slightly out of date version for that one task.

I was thinking I would create a scripts directory and write something that will do everything so that you or I can run it whenever it is needed to create a release. You could probably add whatever you do for wslbin.tar.gz (I'm kind of guessing you just use your local docker install to create that tar.gz file manually, but I'm not certain)

As for Microsoft... I'm not certain why this hasn't been fix already, after all VPN Kit is not exactly new technology, so I have my reservations about waiting for them... But I also agree, nothing extravagant ;)

[AmmarRahman]

You are correct in your assumption that it's just pulling the files locally and zipping them. I was thinking of the idea of just having option 2 in place. However, considering that users might be corporate clients, they might question the security of binaries provided through a third party.

I'm hoping that @microsoft & @craigloewen-msft would eventually have the head space to pay attention to this issue.

[craigloewen-msft]

We are definitely taking a look at networking issues on WSL! Thank you for creating this repo I'll take a look and see if I can try running it on my machine as well to better understand it.

[andyneff]

@craigloewen-msft Thank you for looking at this! I'm only beginning to understand how this works myself, I'm was just happy @AmmarRahman and @sakai135 put a solution together.

My barely understanding:

1. Connects a socket file in WSL2 to a named pipe in windows, using socat and npiperelay.exe
2. Connects the Windows side of the Pipe to a ?Virtual? ethernet device, using vpnkit.exe
3. Connects the WSL side of the Socket to a virtual ethernet device, using vpnkit-tap-vsockd
4. Routes the traffic to use this new virtual ethernet device

And thus, works around the "networking" angle using ICP pipes/sockets instead.

There were some issues that the current "main" branch did not work perfectly out of the box for a new user, hopefully #4 fixes that for you.

[AmmarRahman]

@andyneff That aligns with the understanding I have. To tell the truth @sakai135 is the genius behind this workaround, I just scripted the solution to help my colleagues.