How to set up an extensible VPN with VirtualBox VMs as nodes

[ST]

Thank you for quick and detailed response!

On Mon, 2018-03-12 at 22:41 +0100, Guus Sliepen wrote:
> On Mon, Mar 12, 2018 at 06:46:24PM +0200, ST wrote:
> 
> > We have not so tech-savvy colleagues in different locations around the
> > world who now use Windows 10 and need access to Linux (Debian 9). Linux
> > will be provided in form of VirtualBox VMs. We, the technical support
> > team, need to have access to the guest VMs (via SSH and occasionally as
> > remote desktop)  and to the host (through the guest while VM runs in
> > bridged mode; via Windows 10 built in SSH Server).
> > 
> > What is the best approach to create such an infrastructure in a
> > flexible, secure and efficient way, so that:
> > 
> > (A) adding/removing an employee requires minimal effort,  
> > (B) adding/removing a tech-support team member requires minimal effort.
> > 
> > While we don't have experience with VPNs we assume that it's better to
> > invest in setting up a VPN (with VMs as its nodes) once rather than
> > enable port forwarding on all possible router models in order to get
> > access to the VMs.
> > 
> > 1. What open-source VPN software would you recommend for such a case? We
> > are considering [Tinc](https://www.tinc-vpn.org) as it seems to be
> > rather flexible and provides an easy way to add new nodes thus helping
> > us to achieve the above mentioned goal A.
> 
> Tinc should work just fine. However, if you don't really need the mesh
> network functionality, and just need the VMs to connect back to a
> central server, then other open-source VPN software, such as OpenVPN,
> would work as well.

OK. What is easier to set up and then to maintain (especially add remove
new nodes/VMs)?

> 
> > 2. If yes, in which mode should we run Tinc -
> > [bridge](https://www.tinc-vpn.org/examples/bridging/) or [proxy
> > ARP](https://www.tinc-vpn.org/examples/proxy-arp/)?
> 
> You might not need either of those modes. Plain routing can probably
> also work in your situation, perhaps in combination with a NAT firewall
> rule in the VM.

Could you, please, elaborate on this possible setup, as my knowledge of
networks is really basic. We are indeed interested to keep everything as
simple as possible. Do we need Tinc for this plain routing? Ideally the
end result should be as simple as TeamViewer - you just drop VM on the
host and have access to it via SSH/VNC without messing with port
forwarding, dynamic DNS, etc..

> 
> > 3. How should we manage authentication of the tech support team in order
> > to achieve the goal B? Asymmetric keys? One pair for all or a pair for
> > each member? Maybe passwords?
> 
> Tinc only supports assymetric keys. You should use one pair for each
> node in the VPN (ie, each VM gets its own pair, the central
> server(s) also each get their own pair, and if each tech-support team
> member has its own VPN node they also get their own unique pairs). I
> strongly discourage using the same keypair for more than one node. In
> your case, this is also very important to allow revoking access to the
> VPN for employees and/or tech-support members; if you reuse keys then
> they can simply use a copy of their key to impersonate other nodes.

Is it a bad (or maybe good) idea to use unique pairs for each VPN node,
but the same key/password for the SSH authentication on the VM itself?
This way we can revoke access of each member by revoking access to VPN,
so his knowledge of the SSH key/password will not help him to get access
to the nodes. It will also reduce the management burden as the same
key/password will be distributed within VM image...

> > 4. In order to get an easy (to remember) access to the host from the
> > guest via built in SSH Server on all machines we probably need to give
> > all hosts the same IP in the Network bridge mode. Are there other
> > important configuration tricks for host and/or the VM appliance that you
> > can think of?
> 
> If each Windows host has the same IP address on the VPN, it will be
> impossible to directly SSH to a specific Windows host directly from
> other VPN nodes. However, since I assume the Linux VMs will get unique
> IP addresses in the VPN, you can SSH into the Linux VM, and from there
> SSH to the host. That way, you don't have to consider whether to
> route/bridge/proxy-arp at all.

Again, please, elaborate. We indeed do not need direct access to Windows
hosts, they actually should not/needn't be part of the VPN at all - only
the guest VMs. From guests VMs we want to get to the hosts. That's why I
thought to choose the same IP for the hosts in this small host-guest
networks. This way, no matter on which VM I currently am - I always can
SSH from it to a known IP and will land on its host.

I probably need to mention that those employees with Windows hosts are
people working from home in different cities, each with probably
different ISP. So giving them same local IPs should not cause any
problems, I think.

Again - thank you very much for such a quick and detailed reply!