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@tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
