Supported way of exposing rancher Desktop to the outside

Is there a supported way of exposing Rancher Destop to the outside?

I installed Rancher desktop on Windows 11 on a 2nd hand HP Prodesk mini G4. It works like a charm but it only listens on local host.

I port forwarded the management port with netsh. Next copied the config to .kube/config on my laptop. I changed the ip address in the .kube/config to that of the Prodesk mini.
kubectl refuses to connect because the external ip address is not in the certificate provided.

How to get this working (in a supported way)? This prodesk mini is my personal experimental machine. Yes it can run Linux on bare metal but I do not want to do that.

Second question: How to do this with a laptop that can be on WiFi or fixed internet that changes?

I’m not sure if Rancher Desktop lets you pass that through or not. With RKE2 there’s a place to set up alternate hostnames or IPs to put in the cert (the option is “tls-san” list in /etc/rancher/rke2/config.yaml). There’s ?probably? something similar you can pass in for a manual K3S setup and if the documentation isn’t obvious then you might need to experiment with that by putting Linux bare metal to figure it out (and then back to whatever). If you can find that, then you might be able to find a way to pass the parameters through to the K3S setup with Rancher Desktop (if not in documentation, I’d ask in the #rancher-desktop channel on the Rancher Slack rather than here, or along with here, as that seems more active).

Then, if all that goes well, you can do your port forwarding and get the extra hostname added to the hostfiles of the clients you care about or your local DNS and it’d work.

If that doesn’t work and you have the ability to set up network tunnels on all your client machines, you could set up tunnels for all the ports you need on localhost for your clients to your tunneled external IP and then all your clients are still talking to localhost. Very ugly hack but it’d still technically be everyone talking to localhost at that point so the cert would be ok.

As another point that came to me belatedly that might already be obvious, but if you’re talking about exposing Kubernetes applications you’re running inside Rancher Desktop, you’d do that with an ingress that can specify expected hostname & have separate certificates attached to the ingress, so aside from messing with forwarding past just localhost you wouldn’t need to much around as much if you were trying to expose your app as opposed to the Kubernetes API.