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

Guus Sliepen guus at tinc-vpn.org
Wed Mar 14 20:33:14 CET 2018


On Wed, Mar 14, 2018 at 07:48:13PM +0200, ST wrote:

> > 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?

I'm sure you can set up multiple central servers with OpenVPN with
failover if one goes down as well. However, it is probably easier with
tinc, since it will handle any topology you want without having to do
anything special.

> > 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?

Yes, as long as your central servers are not behind a NAT, the tinc
daemons in the Linux VMs will be able to connect to them without
problems, and once they are connected any traffic back to them via the
VPN will just work. Unless there are firewalls that block the outgoing
TCP connections from tinc, you don't have to do anything special.

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

Well this is kind of the trivial case, so there is nothing special in
the documentation about this use case.

> > 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?

One of two ways: 1) have a cron job in the Linux VMs that regularly
tries to download a new authorized_keys file from one of the central
servers via the VPN, or 2) have a cron job on the central servers that
rsyncs/scps the master authorized_keys files to all VPN nodes. The
second option is perhaps a bit harder to set up; the cron job should
read the tinc configuration files to find out which nodes there are. The
advantage is that you can more easily check that the update of each node
was succesful.

> 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.

On Linux that should be no problem at all, on Windows you might have to
use the netsh command to add addresses to interfaces. See:

https://tinc-vpn.org/documentation/Interface-configuration.html

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180314/2b4e6318/attachment.sig>


More information about the tinc mailing list