https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
e
I see this PR.. But I was under the assumption that the network tunnel would fix proxy issues vs having to configure them in the WSL instance https://github.com/rancher-sandbox/rancher-desktop/pull/4300
Oh sweet, I see someone triggered the package step on that PR, can test it out shortly in that case
r
Thanks @echoing-carpenter-38694, Please let us know how your testing goes.
n
@echoing-carpenter-38694 let me know if that work for you (don't hesitate to ping me). I just want to point that right now you should provide the proxy address as an IP address and not a domain name. A fix is waiting to be merged https://github.com/sorz/moproxy/pull/22
👍 1
e
thanks!, I'm just waiting for the windows build to finish here
w
yup proxy is very much on the RD teams radar as I know its a big impediment for me as well. Not just for registry stuff, but even for the installs that depend on an external resource where it isn’t a true airgap.
yeah the issue w setting a proxy is doing the no_proxy as well and the use of IP based cluster flows in place. WSL does dynamic election so the cluster IP is a moving target.
e
yeah that's what i was seeing
I'm hoping this PR fixes things, looks like the build is about done
w
from comments with the RD folks the 1.9.1 may take a bit longer to release, but the proxy thing is front of mind. but as you see it gets complicated as its a complicated orchestration of forwarding from the rd-distro for certain flows while some stay internal. And all that config management in pref panes and config files.
👍 1
e
Installed the build from that PR.. Initial results is k3s doesn't start. I receive a fatal message "no default routes found in /proc/net/route or /proc/net/ipv6_route" .. This is with the network tunnel enabled but no proxy configured yet
w
yeah I think the PR is very much a WIP. the core is solid, but the pattern and integration I am sure is where a heavy amount of work is to be done.
e
yeah the error seems unrelated to the PR for proxy as I haven't even enabled it yet, but could be some other unrelated change still a WIP
looks like the host side of the tunnel is erroring trying to bind to port 80 because it's excluded on my machine. were any changes made there?
or at least host-switch log contains an error about trying to bind to 0.0.0.0:80
n
@wide-mechanic-33041 Did you have the opportunity to test the proxy PR ? About 
NOPROXY
I planned to add the code to support it once this PR get merged.
e
Ok, found out what was locking port 80 after a break had some netsh interface portproxy bindings probably from a prior instance of rancher-desktop. seems it didn't clean up after itself. had to clear those and do a fresh install and all was good. tested out the proxy: getting 403s now on a docker pull due to a certificate name mismatch getting closer!
n
@echoing-carpenter-38694 Which http proxy are you using ?
e
It's a corporate proxy I don't have a lot of details on. I also don't believe it supports TLS
w
yeah commonly the proxy CONNECT statements won’t be tunneled, but the traffic passing through will be. so your proxy will listen for http but has no problem forwarding https
n
Yes exactly
I've seen a similar issue with "McAfee Web Gateway" typically used in a corporate environment.
e
ah good call, I threw the raw html of the 403 into a file and it does look like it came from a mcafee web gateway
did you find a workaround for that @nice-toddler-37804 ?
n
Not yet. I don't have access to such proxy myself which make the debugging more complicated of course. I will let you know, any inputs are welcome 😅
w
well the cert mismatch probably means you are doing interception so the proxy is a MITM and you will need to hash your internal CA cert with the one in alpine or disable registry trust
if you do an openssl s_client call to www.docker.com as example likely you will see it was signed not by the actual public CA, but by a company.mcafee.com CA (or something like that). And given RD won’t trust that CA you are getting a TLS breakdown.
👍 1
e
will test that out shortly
w
you might need to install some apks in the alpine dist. honestly can’t remember, but you can also test this from your host as the PR solution is just forwarding onto the configured upstream proxy. Just look for certificate trust and it will stand out that there is a possible MITM at play
e
from what I can tell it seems rancher desktop already copies local ca certificates over from my host and calls update-ca-certificates from within alpine, so not convinced its a trust issue, i'd assume that would present a different error
Ok forgot to update this thread. What ended up working getting docker pull etc working. I just reverted back to 1.8.1 with the network tunnel enabled in combination with the directions here: https://github.com/rancher-sandbox/rancher-desktop/issues/4289
n
Do you also use kubernetes ? I think in the past people using this solution had issue running kubernetes but maybe the networkingTunnel fixed this ?
e
yeah it seems to be fine
I previously was getting errors about my non-ssl proxy in k3s, when i was trying to wslenv my HTTPS_PROXY config since it's non tls.. but for whatever reason that is no longer happening with setting them in that file instead
r
I have been working to also have firewall ports opened up to support Rancher Desktop in a similar environment (the proxy feature will be helpful to us for sure!). I did have a question when I was working with our firewall team as it seems Rancher Desktop is constantly pinging example.com every few seconds. If it cannot, it raises the error saying that general Internet access is not available, so it will not pull/update the k3s list available to it, even though it can get to k3s as we had opened it. Any thoughts on why this check is running every few seconds?
c
@rough-balloon-94624 I think it’s a simple check to make sure that RD is still connected to the internet or not here: https://github.com/rancher-sandbox/rancher-desktop/blob/f018523a0662743ca2d9f386cb[…]595/pkg/rancher-desktop/main/diagnostics/connectedToInternet.ts
also, looking at this issue: https://github.com/rancher-sandbox/rancher-desktop/issues/4639 it looks like that approach might change since it is a bit spammy.
r
Thank you for sharing. Yes, it's quite spammy 🙂. Hopefully they will identify a better approach.
w
maybe https://learn.microsoft.com/en-us/windows/win32/api/netlistmgr/nf-netlistmgr-inetworklistmanager-getconnectivity is an option? would be platform specific, but may be worth the conditional logic.
645 Views
Open in Slack
PreviousNext
Powered by