search

CCI-MOC / hil

Hardware Isolation Layer, formerly Hardware as a Service
Apache License 2.0
24 stars 54 forks source link

Openvpn spec #936

Closed zenhack closed 6 years ago

zenhack commented 6 years ago

This is rough, but I a first pass at a design for the openvpn stuff. Probably not done, but hopefully a good starting point for discussion.

zenhack commented 6 years ago

Quoting Naved Ansari (2018-01-18 21:34:11)

Really basic question about how openvpn/vpn works:

A hil user will run an open vpn client on their system which will connect to the open vpn "configuration" (over the internet, using the ip and port) on the host with access to the vlans. Is my understanding correct?

Correct. In more detail, it creates a virtual NIC on the client's system, and just wraps the Ethernet frames sent on that nice inside of UDP packets, plus some crypto.

zenhack commented 6 years ago

Quoting Naved Ansari (2018-01-22 16:19:02)

Also, do you want to mention in this spec what changes will be necessary in HIL?

Sure, I can add that.

does it create both, server side and client side, config files? if it does make the client side file, where does it keep it or just print it to stdout?

It only creates the server side; the client is responsible for configuring OpenVPN themselves. HIL will have to provide the client with necessary information (host/port number/key), and we will provide documentation on how to configure a client.

 * This page says we can only have 1 client and 1 server. For
   scalibility we would want multiple clients for a server.

Things to keep in mind:

 * What version of OpenVPN do we plan to use? From the docs [3]here it
   looks like we would require 2.0 or greater.

Requiring >=2.0 is fine with me.

zenhack commented 6 years ago

Quoting Ian Denhardt (2018-01-22 16:48:49)

Also, do you want to mention in this spec what changes will be necessary in HIL?

Sure, I can add that.

Done.

naved001 commented 6 years ago
  • In this context "server" means "openvpn process."

Oh now it all makes sense. You are spawning independent OpenVPN process because they will attach to different VLAN (bridge, interface) on the server. In that case we don't even need 2.0, because I mentioned that for having multiple clients per server, which now I understand that we don't need.

naved001 commented 6 years ago

some discussion here #559

Also, @pjd-nu emailed me saying that he'll review this over the weekend, and that would be nice.

razaaliraza commented 6 years ago

I have gone through the specs and the conversation here and have just one really basic question.

This is mainly for bootstrapping; users with sophisticated needs will likely want to install provisioning software on a HIL node.

What do we mean by sophisticated users and how do their requirements change from what can be catered through this micro-service? Can we add more functionality to this micro-service so even sophisticated users can use it or would that be redundant?

zenhack commented 6 years ago

Re: more sophisticated use cases: I can imagine wanting to have nodes distribute installation images in a p2p fasion, or wanting redundancy for your management node(s), or just wanting more horsepower than the cheapo vm you rented in the rack across the hall. For some folks, just throwing a pxe server in a vm and hooking it up via vpn may be enough, but for other use cases, you can use the vpn to provision a HIL node, and do more from there.

Can we add more functionality to this micro-service so even sophisticated users can use it or would that be redundant?

The intention is that if users need more, they can use the vpn to install other provisioning tools inside the HIL networks. It's not that they "can't use it," but will probably use it to bootstrap their own provisioning system. HIL is very much a "mechanism, not policy" design, and we're really aiming to provide the bare minimum. So it's less of a question of "can we" than "should we."

razaaliraza commented 6 years ago

That clarifies the need for the bare minimum. this ties into HIL's philosophy. Thanks!

naved001 commented 6 years ago

one quick question; are you planning to write the daemon in Go or python? I would prefer python since more people could give helpful reviews, but if Go has any advantages in this case, then I'd say go for it.

zenhack commented 6 years ago

It might make synchronization a bit easier; I haven't though through in detail what back-end operations we'd need to synchronize, but Go is nice for that kind of stuff (this is why I chose it for obmd). I'd thought Python might make some sense in this case because maybe we'd be able to lift some of the headnode related code from HIL, but I had a look and there's not really much relevant logic. Re: more reviewers, point, but I think long term if we're going to be maintaining one codebase in Go, it's probably worth some other people getting some practice.

That said, there's the disclaimer that I'm probably going to be a bit biased towards Go rather than Python in general just because I like it better.

naved001 commented 6 years ago

okay, good enough for me.

Let's wait for a couple days more if @pjd-nu reviews this, otherwise we'll go ahead with the plan. @razaaliraza does this have your approval? if so, could you approve it/give it a +1

pjd-nu commented 6 years ago

Sorry for the delay.

Each OpenVPN config needs to listen on a separate <IP,port> pair; i.e. there's no way to multiplex different connections. (unlike e.g. ssh) The current design has the following properties:

zenhack commented 6 years ago

Quoting Peter Desnoyers (2018-01-31 11:33:06)

Each OpenVPN config needs to listen on a separate <IP,port> pair; i.e. there's no way to multiplex different connections. (unlike e.g. ssh)

Correct.

The current design has the following properties:

 * The IP address is implicit - vpnd is unable to specify it, and the
   return value from vpn-privop doesn't indicate it. This seems like
   it may be a bit of an issue, because now vpnd has to know the
   external address, which will no doubt break if someone changes that
   address.

Good call; we probably want to return the ip address in the response body from vpnd.

One way to handle this would be to store the IP to listen on in a (global) config file, which then gets propagated to the generated openvpn configs and also returned by vpnd.

 * Port numbers are managed (allocated) by vpnd. That doesn't seem to
   be a problem.

Yep.

 * .ovpn files are created by vpnd. Again doesn't seem to be a
   problem. Note that the .ovpn files from the bridged ethernet config
   I had for a while have several certificates in them as well as the
   private key - someone needs to think about whether this information
   will be available to unprivileged vpnd - if it's either (1)
   protected, or (2) generated along with the config then it needs to
   be returned by vpn-privop.

The notion was to use the static key setup. This was linked from the "Openvpn details" section of the document:

https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html

This means not having to deal with PKI or even asymmetric crypto, just the one shared secret.

The top of the proposal mentions that the openvpn config and key are generated by vpn-privop. The key is printed to stdout, making it available to vpnd.

xuhang57 commented 6 years ago

looping this issue: https://github.com/CCI-MOC/hil/issues/548

naved001 commented 6 years ago

@pjd-nu does this have your approval or is there some change that you would like to see? Thanks!

naved001 commented 6 years ago

@shwsun @SahilTikale @knikolla @pjd-nu @Izhmash anyone wants to review and approve this?

naved001 commented 6 years ago

@radonm