Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Metavpn_Integration



MetaVPN Integration (glue design doc)


  • MetaVPN is a tool that, as part of a testbed, provides management of OpenVPN-run Virtual Networks.
  • OpenVPN - Open-source software that manages Layer2 and Layer3 virtual networks. One OpenVPN server instance exists per OpenVPN virtual network. Each client has an OpenVPN instance per OpenVPN network they're on.
  • VPN Key - OpenSSL keys used by a node to authenticate with an OpenVPN instance
  • server - In this document refers to a node that is running the relevant MetaVPN and OpenVPN server process. In OpenVPN, the network is constructed by all clients in a network connecting to a server.
  • client - In this document refers to the set of nodes that will be on a particular OpenvPN-managed network
  • user - Experimenter on whose behalf the virtual network is being constructed
  • system - Combination of Component Manager(s), helper scripts, glue code, and MetaVPN working to construct the requested virtual network
  • glue code - Code that, inside or invoked by the CMs, figures out what kind of network the user has requested, chooses a system to manage the server instance, appropriately invokes MetaVPN to bring up that server instance, and ensures that the clients are brought onto the network.
  • Public nodes - Testbed nodes that have real, routable IPs
  • Private nodes - Testbed nodes that have private/nonroutable IPs (Might be behind a NAT, might be truly unable to see the internet directly and only reachable through boss/ops/other nodes)

Note that the Glue Code is primarily what this design document is about.

RSpec for OpenVPN networks

  • User will ordinarily get a Layer2 network - need to be able to specify Layer3 as an option (reserved keyword/option that we won't implement for awhile?)
  • We do not want to expose transport details so as to leave our software the greatest flexibility in constructing the desired network
  • Ideally, the RSpec interface will just indicate that a link should be present between two or more nodes and that that link be an OpenVPN-managed one. Under some circumstances, the user might not even need to know that OpenVPN is involved and generic links will be implemented with OpenVPN
  • OpenVPN links should ideally look much like other link types (assuming that those other link types are multi-system networks rather than point-to-point links).

MetaVPN Components and Accessories

  • metavpn is a perl program that is invoked multiple times to initiate, configure, bring up or down, and register nodes with any network managed by that server. It does not stay resident, nor does it act as a server itself in any means. It is designed to run on the same system where the OpenVPN server instances it manages are run.
  • metv_direct_keygen is a helper script that can directly produce configuration tarballs for clients (which the user or the system
  • metv_import_openvpn_keys and serve_openvpn_keys.cgi are tools to import needed configuration data for clients into a database and then to serve them to clients on an as-requested basis

Glue components

  • CM-MVPN-glue-request - Runs on Component Managers as an extension plus some out-of-band communication stuff
  • CM-MVPN-glue-decider - Run by whatever CM is elected to manage everything
  • MVPN-launcher-glue - Actually invokes MetaVPN on whatever MetaVPN host the decider picks
  • MVPN-client-glue - Runs on individual nodes, responsible for getting the config(s) that client needs to be on the network(s) they should be on

Details of the task of the Glue Code

  • CM-MVPN-glue-request Runs on (some, eventually all?) CMs. As the Rspec comes in, CMs that have a MetaVPN-glue extension will parse requests for an OpenVPN virtual network, and use in-band communication with all other involved CMs to:
    • Find out who has parsed the Rspec yet
    • Find out who has the extension
  • When all the CMs are up, it will use out-of-band communcation (unless facilities for this are ever provided in-band) for those CMs that have the extensions in order to:
    • Elect a leader (a CM) to take charge (which will then run the CM-MVPN-glue-decider code)

That leader will:

  • Decide, by investigating the Rspec as well as attributes of the testbeds in question (how will it get those? More OOB?), on a MetaVPN master that is mutually addressible with all nodes
  • (direct CMs to tell clients from where they can get their key data in parameterising startup tarballs? Or should the client-glue be smart enough to query their boss/CM for this?)
  • Invoke that MetaVPN master (via MVPN-launcher-glue) to make a network, bring it up, and register every node in the Rspec that needs to be on that network with it. Node configurations are prepared for distribution

At this point, the VPN is up, and the node configurations are in a database on a system with which the nodes can all communicate. The nodes have been instructed (earlier) to include MVPN-client-glue in their list of configuration tarballs, and as they unpack it, they will use it to somehow (talk to their CM? Or local boss? Or webserver running on MVPN box? Or scp?) retrieve their configuration tarball(s), unpack them, and run the OpenVPN software (that their OSImage must provide) against the configfile and SSLKey present in that configuration tarball(s), once per virtual network they need to be on

For extra credit/sometime later

How to handle two private testbeds (and a public, for good measure)?

Probably: we create multiple masters and direct one of them to only handle its private nodes and the other to handle the public and its private, and glue them together using OpenVPN or something else.

See also