Allow direct connection between some (but not all) nodes on the network (Guus Sliepen)
Cristian Lozano
criscalovis at gmail.com
Thu Dec 29 21:20:41 CET 2016
Guus Sliepen,
I am working in a zeroconf setup for tinc called tzk, that could allow you
to make this easily
https://github.com/NebTex/tzk/
it will make better readme this weekend but you need a public machine with
a public domain - subdomain pointed to it, the script will install tinc,
consul (that is used for coordinate the vpn), and caddy a small reverse
proxy for expose consul to the public internet with TLS support. after the
installation ends it will print another command that you can run over your
nodes to connect to the vpn
this is the command that you should run in your master
master=true ConsulHost=consul.example.com bash -c "$(curl -fsSL
https://git.io/v1b4Q)"
where consul.example.com is your public domain or subdomain
it is only tested in ubuntu 16.04, but you can run in any os with docker
1.12 support
this is what the script really does
if [ "${master:-false}" == "true" ];then
hostnamectl set-hostname master1
export ACLToken=$(uuidgen)
mkdir -p /consul
mkdit -p /caddy
chmod 755 -R /consul
chmod 755 -R /caddy
docker run -d --env ACLToken=${ACLToken:?} --env
ConsulHost=${ConsulHost:?} \
--env master=true --net=host --device=/dev/net/tun --cap-add NET_ADMIN \
--volume /consul:/consul --volume /caddy:/root/.caddy \
--volume /etc/hosts:/etc/hosts --name tzk nebtex/tzk
else
docker run -d --env ACLToken=${ACLToken:?} --env
ConsulHost=${ConsulHost:?} \
--net=host --device=/dev/net/tun --volume /etc/hosts:/etc/hosts
--cap-add NET_ADMIN \
--name tzk nebtex/tzk
fi
the first part is in the master the second part is in the nodes.
after this is done you can login in the consul interface using the acl
token generated here
export ACLToken=$(uuidgen)
this acl token has root acces to consul you can see docs about consul and
the acl system there
https://www.consul.io/docs/internals/acl.html
the estate of the vpn is all store in consul under the tzk folder in the kv
store, even the tinc dump graph result are stored and udated every minute
or so
the host are store in tzk/Hosts
how could you archive easily conectivity only between some nodes?
you can use the consul acl system, and create acl token with only
permission to certain host, the default acl token has write an read access
to all the host, if you understand the acl consul system in theory you
could archive what you want , the only issue for the moment is that you
need to know in advance the name of all the hosts that will be insolated
there is a plan to support multiples subnet in the future and you could
wite acl tokens with permissions by subnet instead of hosts
plese dont doubt to ask me any question, this weeken I plan to write a long
documentation
El jue., 29 de dic. de 2016 a la(s) 11:02, <tinc-request at tinc-vpn.org>
escribió:
> Send tinc mailing list submissions to
> tinc at tinc-vpn.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> or, via email, send a message with subject or body 'help' to
> tinc-request at tinc-vpn.org
>
> You can reach the person managing the list at
> tinc-owner at tinc-vpn.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tinc digest..."
> Today's Topics:
>
> 1. Re: Allow direct connection between some (but not all) nodes
> on the network (Guus Sliepen)
> 2. Compression not working between 1.1pre11 and 1.1pre14
> (Peter Schulze)
> 3. Re: Accessing ip camera through a vpn client (Guus Sliepen)
> 4. Re: tinc using docker containers (Guus Sliepen)
> 5. Re: Compression not working between 1.1pre11 and 1.1pre14
> (Guus Sliepen)
> 6. Re: tinc using docker containers (Guillermo Bisheimer)
>
>
>
> ---------- Forwarded message ----------
> From: Guus Sliepen <guus at tinc-vpn.org>
> To: tinc at tinc-vpn.org
> Cc:
> Date: Thu, 29 Dec 2016 13:45:32 +0100
> Subject: Re: Allow direct connection between some (but not all) nodes on
> the network
> On Sat, Dec 24, 2016 at 03:12:15AM +0000, Guillermo Bisheimer wrote:
>
> > I'm using tinc 1.1pre14 to establish a VPN between 10 servers and a few
> > administration clients. I have a central server that runs Tinc and all
> > other servers and clients connect to it. I need the to be able to
> establish
> > a direct connection between the administration clients and the servers,
> but
> > block the server between each other.
>
> This is not supported by tinc. I would normally recommend that you use
> one VPN per administrative domain, but if you are have 10 or more
> domains, I can see that this is becoming a hassle to set up. Still, it's
> only one tinc setup per server, only on the administrative clients you
> need to configure multiple tinc networks.
>
> > I couldn't find a way to do this with tinc, but meantime I'm using the
> > options Forwarding=kernel and tunnel_server=yes and a bunch of firewall
> > rules in order to accomplish the network topology I need. I don't have
> > direct connection between admin clients and the servers, but it works.
>
> That's the best alternative solution if you can live without direct
> connections.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus at tinc-vpn.org>
>
>
>
> ---------- Forwarded message ----------
> From: Peter Schulze <ps at mailsnake.com>
> To: <tinc at tinc-vpn.org>
> Cc:
> Date: Thu, 29 Dec 2016 12:47:15 -0000
> Subject: Compression not working between 1.1pre11 and 1.1pre14
> Hello
>
> I have currently a larger network deployed using 1.1pre11.
> I have now tried to use 1.1pre14 on a remote system, but I have problems to
> make it work with compression enabled.
>
> It appears that a 1pre14 client cannot talk to a 1.1pre11 server with
> compression enabled, even though the tunnel is being established with no
> errors.
>
> I have tried both lzo and zlib with various levels, none works.
>
> It is however possible to ping through the tunnel, presumably because ICMP
> packets are not being compressed.
>
> The connection does work correctly when I disable compression (Compression
> =
> 0) at both ends.
>
> A test also shows that 1pre14 to 1pre14 connections work with compression
> enabled.
>
> Thanks
>
> Peter
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Guus Sliepen <guus at tinc-vpn.org>
> To: tinc at tinc-vpn.org
> Cc:
> Date: Thu, 29 Dec 2016 13:36:55 +0100
> Subject: Re: Accessing ip camera through a vpn client
> On Thu, Dec 15, 2016 at 04:45:14PM +0200, sampsa wrote:
>
> > client name [ip in eth0] [ip in tun0]
> >
> > gl752 (A) 192.168.1.33 10.0.0.1
> > xps13 (B) 192.168.1.55 10.0.0.2
> >
> > I also have an ip camera connected to the local network at 192.168.1.21.
> [...]
> > I'd like to have the camera to have the ip address 10.0.0.21 in the tun0
> > interface.
>
> The main issue is then to get gl752 to translate the address of packets
> for 10.0.0.21 to 192.168.1.21, and vice versa. Let's look at a packet
> being sent from xps13 to the camera:
>
> src: 10.0.0.2 dst: 10.0.0.21
>
> First, you have to ensure that tinc knows that packets to 10.0.0.21 have
> to go to gl752. So add "Subnet = 10.0.0.21" to hosts/gl752 on gl752
> itself. Now that the packet arrives at gl752, both the source and
> destination address have to be changed! The reason is that the camera is
> on a LAN that does not use the 10.0.0.0/24 address range. What you want
> is to have the addresses translated so it looks like this:
>
> src: 192.168.1.33 dst: 192.168.1.21
>
> Or in other words, that it looks like the packet came from gl752 and is
> being sent to the camera. Now, if the camera sends a packet back, it
> will look like this:
>
> src: 192.168.1.21 dst: 192.168.1.33
>
> And now gl752 has to know that this packet is not actually sent to
> itself, but that it has to be forwarded back to xps13, so the forwarded
> packet has to look like:
>
> src: 10.0.0.21 dst: 10.0.0.2
>
> To do this, two firewall rules have to be added on gl752. The first is a
> rule that will translate the destination address 10.0.0.21 to
> 192.168.1.21:
>
> iptables -A PREROUTING -i tun0 -d 10.0.0.21 -j DNAT --to 192.168.1.21
>
> The second is to masquerade connections to the camera as coming from
> gl752 itself:
>
> iptabels -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d 192.168.1.21 -j
> MASQUERADE
>
> > The camera should be able to stream multicast as well.
>
> That will be even harder. While tinc handles multicast packets, it
> treats them as broadcast packets. Also, you need to ensure multicast
> packets from the LAN are forwarded to the VPN, and vice versa. I've
> never tried to set that up, so I can't help you with that.
>
> > 1) Is there any way to make tinc aware of a device that is accessible
> > through the client "xps13", i.e. some sort of "auto-mapping"
> 192.168.1.21 =>
> > 10.0.0.21 (I remember openvpn had something like this..?).
>
> Tinc does not do any mapping itself, so you have to rely on your
> kernel's abilities, like described above.
>
> > 2) .. Or should I define "xps13" as being the gateway for "gl752", along
> the
> > lines of:
> >
> > https://www.tinc-vpn.org/examples/redirect-gateway/
>
> No, that does not make sense.
>
> > 3) Or is the thing that I am trying to achieve here, better described as
> > "bridging", and I should do something along these lines .. ?
> >
> > https://www.tinc-vpn.org/examples/bridging/
>
> Bridging could also be a solution, if you can have everything use the
> same address range (192.168.1.0/24) without conflicts.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus at tinc-vpn.org>
>
>
>
> ---------- Forwarded message ----------
> From: Guus Sliepen <guus at tinc-vpn.org>
> To: tinc at tinc-vpn.org
> Cc:
> Date: Thu, 29 Dec 2016 13:54:04 +0100
> Subject: Re: tinc using docker containers
> On Tue, Dec 27, 2016 at 12:16:04AM +0000, Guillermo Bisheimer wrote:
>
> > I've recently built a docker container to easily install and configure
> tinc
> > 1.1pre14 in any machine using docker containers. I've created a Github
> repo
> > in https://github.com/bys-control/docker-tinc
>
> Great! One comment: ifconfig is considered deprecated on Linux. I'm sure
> the command will stay around, but it is better to use the "ip" command
> in new projects. The recommended way to write a tinc-up script is:
>
> #!/bin/sh
> ip addr add $TINC_IP dev $INTERFACE
> ip link set dev $INTERFACE up
>
> You don't need a separate netmask, you can use CIDR notation (for
> example: TINC_IP=192.168.1.1/24).
>
> > I'm working in a WEB based admin interface for managing tinc daemons.
> Right
> > now it's just a JSON API for tinc, but I'm working in developing the
> front
> > end.
>
> Interesting. I'd like to see the JSON API when it's finished, maybe this
> is something to be supported by tinc itself in the future.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus at tinc-vpn.org>
>
>
>
> ---------- Forwarded message ----------
> From: Guus Sliepen <guus at tinc-vpn.org>
> To: tinc at tinc-vpn.org
> Cc:
> Date: Thu, 29 Dec 2016 14:15:21 +0100
> Subject: Re: Compression not working between 1.1pre11 and 1.1pre14
> On Thu, Dec 29, 2016 at 12:47:15PM -0000, Peter Schulze wrote:
>
> > It appears that a 1pre14 client cannot talk to a 1.1pre11 server with
> > compression enabled, even though the tunnel is being established with no
> > errors.
>
> Hm, nothing really changed wrt. compression between pre11 and pre14.
> I'll have to investigate to see what the problem is.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus at tinc-vpn.org>
>
>
>
> ---------- Forwarded message ----------
> From: Guillermo Bisheimer <gbisheimer at bys-control.com.ar>
> To: tinc at tinc-vpn.org, Guus Sliepen <guus at tinc-vpn.org>
> Cc:
> Date: Thu, 29 Dec 2016 16:02:04 +0000
> Subject: Re: tinc using docker containers
> Thanks for the ifconfig command replacement suggestion. I've already
> updated the github and docker repo with the changes.
>
> El jue., 29 dic. 2016 a las 9:54, Guus Sliepen (<guus at tinc-vpn.org>)
> escribió:
>
> On Tue, Dec 27, 2016 at 12:16:04AM +0000, Guillermo Bisheimer wrote:
>
> > I've recently built a docker container to easily install and configure
> tinc
> > 1.1pre14 in any machine using docker containers. I've created a Github
> repo
> > in https://github.com/bys-control/docker-tinc
>
> Great! One comment: ifconfig is considered deprecated on Linux. I'm sure
> the command will stay around, but it is better to use the "ip" command
> in new projects. The recommended way to write a tinc-up script is:
>
> #!/bin/sh
> ip addr add $TINC_IP dev $INTERFACE
> ip link set dev $INTERFACE up
>
> You don't need a separate netmask, you can use CIDR notation (for
> example: TINC_IP=192.168.1.1/24).
>
> > I'm working in a WEB based admin interface for managing tinc daemons.
> Right
> > now it's just a JSON API for tinc, but I'm working in developing the
> front
> > end.
>
> Interesting. I'd like to see the JSON API when it's finished, maybe this
> is something to be supported by tinc itself in the future.
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus at tinc-vpn.org>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
> --
>
> *Ing. Guillermo Bisheimer*
>
> *B&S Sistemas de Control y Equipamientos*
>
> Av. de los Constituyentes 1172
>
> (E3116CIX) Crespo, Entre Ríos
>
> Tel/Fax: (0343) 407-8990 (Nuevo número)
>
> Cel: (0343) 154679052
>
> WEB: www.bys-control.com.ar
>
> e-mail: gbisheimer at bys-control.com.ar
>
> skype: guillermo.bisheimer
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20161229/3dd20da9/attachment-0001.html>
More information about the tinc
mailing list