How can I avoid exposing the UDP port from my cluster

[Bengreen]

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]

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]

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]

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]

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]

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]

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. 👍