OneGate: expose a communication port inside the VM

Hello.

In our setup, the OpenNebula frontend is not exposed on Internet for security reason.

In such a setup, we can’t run a service like OneKE on our public network because OneGate is not publicly reachable.

I started reading libvirt documentation on channels to see if there is a way to expose a communication port inside the virtual machine and make onegate cli communicate through that port instead.

On the hypervisor side, we may need something to forward the communication :thinking:

Before digging more the subject, does someone have an idea or suggestion on that topic?

Regards.

Hi Daniel,

yes we are aware of this issue. We’re actively working on providing the “onegate-proxy” service (currently in testing phase), which will be installed on hypervisor hosts. It will be based on https://www.kernel.org/doc/Documentation/networking/tproxy.txt which will cause all the traffic targeted for 169.254.169.254:5030 (example) endpoint inside guests to be routed via hypervisor hosts. Then something like a ssl tunnel or vpn (between frontends and hosts) could be used to reach the onegate endpoint.

Regards.

1 Like

Do you have any issue I can subscribe?

Yes, OneGate proxy service · Issue #5973 · OpenNebula/one · GitHub :+1:

2 Likes

I have setup a test cluster and I think something is missing somewhere.

Our setup use Open vSwitch and the VM ask for ARP request but get no response:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on one-3-0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:30:34.619952 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:35.642198 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:36.666192 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:37.690273 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:38.714226 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28
13:30:39.738249 ARP, Request who-has 169.254.16.9 tell 10.1.0.1, length 28

I think that I’ll require some Open vSwitch trickeries :thinking:

Does someone have an idea?

I continue my tests by trying to get rid of the VLAN isolation by making /dev/ttyS0 a forward to 169.254.16.9:5030 by adding the following

<devices>
    <serial type='tcp'>
        <source mode='connect' host='169.254.16.9' service='5030'>
            <reconnect enable='yes' />
        </source>
        <protocol type='raw'/>
        <target port='0'/>
    </serial>
</devices>

After the VM start:

  • I execute on the hypervisor nc -ln -p 5030 -s 169.254.16.9
  • Then I execute inside the guest echo foo | tee /dev/ttyS0

This makes the nc command display foo.

Now, I must find a way to make onegate.rb communicate with onegate-proxy throught this /dev/ttyS0.

Regards.

Now, I need to try to modify the client to use NetX::HTTPUnix.

Hi,

It seems that the proxy is not a good solution for you after all. Our suggestion would be to modify the templates (Flow and VNF VM) and add third VNET, such that hosts deployed there would have access only to OneGate. Then this VNET would be added to VNF only and with the help of a start script you could configure NAT insde VNF to route OneGate traffic comming from RKE2 nodes. Please let us know if that is something possible to do in your infrastructure, we can provide more detailed description on how to achieve all that.

1 Like