How can I avoid exposing the UDP port from my cluster

Bengreen commented 11 months ago

What is the new feature about?

in the environments I work in exposing the UDP port is not an option. So I was working out how to achieve the VPN connection without adding that interface. The direction I was looking was port-forwarding. Obviously UDP port-forwarding natively in K8s is not viable. So I looked at using https://github.com/knight42/krelay which provides UDP port forwarding.

I started out setting up the port forward to my localhost so it is now available on localhost:64881 and then ran gefyra config --host and --port to define the connection.

All seems good so far.

But I think I am running into issues with the Gefyra connection to the VPN being based in the container inside docker (Im not sure on this part).

When I run

gefyra connections connect -f  gefyra-client.json

I now get a failure:

Creating the cluster connection 'default' |████████████████████| 0 in 2:16.4 
Error: Gefyra could not successfully confirm the connection working.

I assume this is because the container insider docker cannot reference localhost:64881

Would appreciate feedback if this route/thinking sounds viable.? Any ideas/suggestions on how to move this forward greatly appreciated as Gefyra looks like a very useful tool to aid developer flow.

Why would such a feature be important to you?

Inside some environments exposing a VPN is not allowed/viable.

Anything else we need to know?

No response

Bengreen commented 11 months ago

I tried setting the host to be host.docker.internal so that it could be referenced from inside the docker pod.

gefyra clients config ben00 --host host.docker.internal --port 61355 -o gefyra-client.json

I still get

Creating the cluster connection 'default' |████████████████████| 0 in 1:00.9 
Error: Cannot resolve host 'host.docker.internal'.

Any ideas if this direction of thinking is viable or fundamentally flawed?

Bengreen commented 11 months ago

I have turned up the logging for kubectl relay to allow me to see packets being sent to the UDP port.

Once I do this I can confirm that I can send packets to the host UDP port (forwarded from Wireshark) from a docker container.

docker run -it alpine
ask add netcat-openbsd
echo hello | nc -u host.docker.internal 56196

The relay logs show the UDP packets are observed and being forwarded.

This makes me feel this issue is with the cargo ... Anything I can do to check ?

Bengreen commented 11 months ago

So my estimation is that the DNS resolution is being performed on the host which will not result in a resolution of host.docker.internal. So I ran an alpine container and then did a check on the IP address of the host host.docker.internal which turned out to be 192.168.65.254

So with a little DODGY cajoling this seems to be progress

I then ran the client config

gefyra clients config ben00 --host 192.168.65.254  -o gefyra-client.json --port 50533

and then checked the connection

gefyra connections connect -f gefyra-client.json
Creating the cluster connection 'default' |████████████████████| 0 in 1.9s 
Connection established with connection name 'default'. Run 'gefyra connections list' to see all connections.

which shows a connection:

gefyra connections list                         
NAME     VERSION    CREATED                        STATUS
default  2.0.2      2023-11-28T21:01:01.85143251Z  running

Bengreen commented 11 months ago

I then followed through the rest of the getting started guide: https://gefyra.dev/docs/getting-started-with-gefyra

And it works VERY nicely.

I don't know about the performance of this pattern. But it does at least provide the functionality in an environment where no direct wirelink port can be exposed.

Bengreen commented 11 months ago

The only part that did not work smoothly was the host to IP address conversion for targeting the hotspot. Are there any suggestions on how to clean this up?

Schille commented 11 months ago

Hi @Bengreen Thank you for the fantastic investigation. I'm glad you've found a way to make it work for you. I am busy at the moment, but I'd really like to pick this up in the next weeks and understand what you did there. =) Just one remark: we intentionally decided against turning the whole developer traffic over the K8s API server, as it can become very busy with it. Depending on what you expect, this could be a problem. However, if it works, then you are right. 👍

gefyrahq / gefyra