1 | Function: |
---|
2 | Metavpn has the task of dynamically creating/configuring openvpn |
---|
3 | instances for nodes to connect to. This is useful in allowing nodes |
---|
4 | with networking oddities (e.g. NAT or no internet routing at all) |
---|
5 | to participate in experiments. One expected topology would be: |
---|
6 | |
---|
7 | Testbed A (all nodes have public IPs) |
---|
8 | nodew1 |
---|
9 | nodew2 |
---|
10 | nodew3 |
---|
11 | Testbed B (only boss/ops are public) |
---|
12 | nodew4 |
---|
13 | nodew5 |
---|
14 | Experiment has a simple eth network that everyone is on |
---|
15 | Done: |
---|
16 | B-ops dynamically allocates a L2 OpenVPN during swapin, |
---|
17 | all nodes join it as they come up, the A-nodes over |
---|
18 | the public internet, the B-nodes through their connection |
---|
19 | to B-ops. |
---|
20 | |
---|
21 | Another topology: |
---|
22 | |
---|
23 | Testbed B (only boss/ops are public) |
---|
24 | nodew1 |
---|
25 | nodew2 |
---|
26 | Testbed C (only boss/ops are public) |
---|
27 | nodew3 |
---|
28 | Experiment has a simple eth network that everyone is on |
---|
29 | Done: |
---|
30 | B-ops dynamically allocates a L2 OpenVPN during swapin, |
---|
31 | C-ops dynamically allocates a L2 OpenVPN during swapin, |
---|
32 | B-ops and C-ops are joined by an openvpn running in |
---|
33 | --server-bridge mode |
---|
34 | (we must enable packet forwarding from the vpn |
---|
35 | on each side to the bridge) |
---|
36 | |
---|
37 | |
---|
38 | metavpn does not run on boss. This is because: |
---|
39 | metavpn does the dirty work of generating configfiles, starting and |
---|
40 | stopping openvpn as needed, and configuring a SSL instance. |
---|
41 | It's easier to do this on the same machine as the openvpn servers. |
---|
42 | This does impose some challenges. |
---|
43 | |
---|
44 | For now, metavpn is assumed to run on ops. It is an explicit design factor |
---|
45 | that it should not rely on running on ops (perhaps running on a |
---|
46 | dedicated server). |
---|