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

[ST]

On Wed, 2018-03-14 at 09:47 +0100, Guus Sliepen wrote:
> On Tue, Mar 13, 2018 at 11:09:05PM +0200, ST wrote:
> 
> > > > 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)?
> 
> If you are not interested in the mesh functionality that tinc provides,
> then both are probably similar in ease of setup and maintenance.

If so - we'll choose tinc, as we might need this functionality in
future, who knows... As far as I understand it means, i.a., that tinc
provides the ability to run several central servers, while OpenVPN only
one, thus creating a danger of VPN failure if this single central server
goes down. Correct?

> > > > 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..
> 
> As I see it you want this situation:
> 
> *----------------*
> |  Windows host  |
> |                |
> |  *----------*  |
> |  | Linux VM |  |
> |  |   tinc---+--+--------------> rest of the VPN
> |  *----------*  |
> |                |
> *----------------*
> 
> If you just want to have access to the Linux VM, then you don't need
> bridging or proxy ARP at all. The Linux VM will have its own unique IP
> address on the VPN, and you will be able to access it directly via
> whatever protocol you want without needing to do anything.

Yes, that is exactly what we want. But will this go through all possible
NATs/Firewalls/etc. of the users behind home routers? The way TeamViewer
does?

Could you, please, post a link to relevant tinc documentation and
examples of how to implement this particular use case?... Thank you!

> 
> > 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...
> 
> If you are certain that the only way you can access the VM is via the
> VPN, then in principle you could use the same key/password for SSH. But
> I would personally not take that risk. I would just have all members'
> public SSH key in .ssh/authorized_keys on the VM. This file can just be
> the same on all VMs. So if a member's access is revoked, I'd remove his
> public key from the master copy of the authorized_keys file, and
> redistribute it to all VMs.

The tricky part is the redistribution - how would you do it?

> > > 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.
> 
> Yes, in that case using the same IP address for the Windows host in the
> host-guest networks is perfectly fine.
> 
> > 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.
> 
> You do have to be careful about which IP address you are going to use.
> You have no control over the IP address that the Windows hosts are
> going to get from the ISP they are connected to. They can get a public
> IP address, or they could get any IP address from the private ranges
> such as 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. If possible, the
> best way to ensure you will not have an address conflict is to use IPv6
> for the host-guest network. Then you can use link-local addresses which
> for sure will not conflict with anything, or if that is not an option,
> assign a Unique Local Address, see:
> https://en.wikipedia.org/wiki/Unique_local_address

I started to read about link-local IP6 addresses. Is it possible to
assign a network interface several such address (since one it has
already)? I'll have to figure out how to do this on Windows 10.

Again - thank you very much!

> 
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc