12:15 a.m.
Hi all,
trying to understand the tinc role I wondering if there is an
possibility to set up mesh network where all tinc tap adapters are part
of a bridge (br2) on their hosts.
The goal is to have a server cluster where vms on different host can
share one bridge which is connected through tinc.
The configuration below results in a situation where none of the hosts
have a "ConnectTo=" variable in tinc.conf.
If I use the "link_type: 'dynamic'" we have these variables - but the
tap-mesh0 interface itselfs tries to get address via dhcp - which is not
what I want.
I also wondering if it is intended that taking the example inventory
(https://docs.debops.org/en/master/ansible/roles/tinc/getting-started.html...
with one host with dns/dhcp) there is no ConnectTo neigher on the host
which provides DNS/DHCP. Doesn't this lead to an setup which is not a
real mesh network?
This example configuration (one dhcp host - other nodes where tap-mesh0
gets address through dhcp) works for me (but only with bridge on host1).
But the host entries in mesh0/hosts/hostXY have the hostname configured
with the "br2" subdomain - like host1.br2.example.org which is the
name-resolution of dnsmasq on host1. Does this makes sense? Why not
address all hosts through there fqdn on the primary interface? Then we
don't get any problems with static bridge configuration without dhcp and
working name resolution via tinc.
Additionally it seem's not so easy to find the right order for getting
up bridges and the tap interfaces:
Even if fix the problems above resulting in a setup where on host has
tap interface on br2 with dhcp server and two other host with tinc via
bridge configuraion and dhcp: after reboot I have first to restart tinc
before it's possible to get an ip address through dhclient.
One of my test configs:
Host 1:
tinc__host_networks:
'mesh0':
bridge: 'br2'
ifupdown__interface_layout: 'dynamic'
ifupdown__host_interfaces:
'br2':
type: 'bridge'
inet: 'static'
nat: True
addresses:
- '10.0.0.11/24'
Host 2:
tinc__host_networks:
'mesh0':
bridge: 'br2'
ifupdown__interface_layout: 'dynamic'
ifupdown__host_interfaces:
'br2':
type: 'bridge'
inet: 'static'
nat: True
addresses:
- '10.0.0.12/24'
Host 3:
tinc__host_networks:
'mesh0':
bridge: 'br2'
ifupdown__interface_layout: 'dynamic'
ifupdown__host_interfaces:
'br2':
type: 'bridge'
inet: 'static'
nat: True
addresses:
- '10.0.0.12/24'
Best regards
Jan
11:10 a.m.
On cze 27, Jan Kowalsky wrote:
Hi all,
Hello, sorry for a late reply.
trying to understand the tinc role I wondering if there is an
possibility to set up mesh network where all tinc tap adapters are part
of a bridge (br2) on their hosts.
The goal is to have a server cluster where vms on different host can
share one bridge which is connected through tinc.
Yes, you should be able to connect the Tinc interface to a bridge on each
host, just specify it with the 'bridge' parameter.
The configuration below results in a situation where none of the
hosts
have a "ConnectTo=" variable in tinc.conf.
You need to specify the list of hosts to connect to using the 'connect_to'
parameter, otherwise a given Tinc node will not try to connect to any other
node by itself. This is valid for example in a situation where a single Tinc
node is accessible on a public IP and other nodes are behind NAT networks,
using that single public node for communication.
If I use the "link_type: 'dynamic'" we have these
variables - but the
tap-mesh0 interface itselfs tries to get address via dhcp - which is not
what I want.
The 'link_type' parameter just changes what parameters will be added
automatically by the role, you should be able to specify them "manually" as
well if needed. The 'static' or 'dynamic' types are kind of like presets,
but
if you have different needs, it should still be possible to implement them.
I also wondering if it is intended that taking the example inventory
(https://docs.debops.org/en/master/ansible/roles/tinc/getting-started.html...
with one host with dns/dhcp) there is no ConnectTo neigher on the host
which provides DNS/DHCP. Doesn't this lead to an setup which is not a
real mesh network?
Tinc VPN is designed to implement different kinds of networks - in some cases
nodes can be behind NAT gateways, in which case other nodes cannot connect to
them directly. The 'ConnectTo' configuration option just tells Tinc to try and
connect to a node automatically, but it's not necessary for its operation. In
this setup, the Tinc nodes behind NAT will try to connect to the "bridge node"
on the public IP address. Afterwards, after the communication has been
estabilished via the bridge node, Tinc should be able to create secondary
connections between the nodes - check the process status via:
kill -USR2 $(pidof tincd)
In the logs you should see which node is connected to which one.
Of couse in those kinds of setups you probably would want to have multiple
public nodes to provide redundancy, in which case proper mesh network is
achievable. I suppose that adding more examples in the docs for different
variants wouldn't hurt.
This example configuration (one dhcp host - other nodes where
tap-mesh0
gets address through dhcp) works for me (but only with bridge on host1).
But the host entries in mesh0/hosts/hostXY have the hostname configured
with the "br2" subdomain - like host1.br2.example.org which is the
name-resolution of dnsmasq on host1. Does this makes sense? Why not
address all hosts through there fqdn on the primary interface? Then we
don't get any problems with static bridge configuration without dhcp and
working name resolution via tinc.
I realied some time ago that because I'm currently using dnsmasq in my
development environment and only a single subdomain, this creates a bias in
how I'm writing roles, I will have to work on that.
Using DNS on multiple networks is tricky. Do you expect to have hosts with the
same name in multiple networks, like 'smtp', 'cloud', 'wiki',
etc.? How do you
differentiate between different hosts in that case? You would probably use
different subdomain for each network... But then the hosts themselves assume
that they are on a single subdomain (via 'ansible_domain' and
'ansible_fqdn'
variables) which impacts multiple things - X.509 certificates, webserver SNI
configuration, Postfix $mydestination list, routing packets through a specific
network interface based on its DNS name, to name a few. I'm not sure if
there's a good solution for that in Ansible that doesn't complicate things
exponentially. It all depends on what kind of environment you want to
implement.
Additionally it seem's not so easy to find the right order for
getting
up bridges and the tap interfaces:
Even if fix the problems above resulting in a setup where on host has
tap interface on br2 with dhcp server and two other host with tinc via
bridge configuraion and dhcp: after reboot I have first to restart tinc
before it's possible to get an ip address through dhclient.
This probably can be solved by defining the dependencies in the systemd unit
configuration. There's an issue about this already on GitHub[1], you could see
if a proposed solution works for your setup.
[1]: https://github.com/debops/debops/issues/1398
Cheers,
Maciej
6:36 p.m.
Hi Maciej
Am 30.06.20 um 11:10 schrieb Maciej Delmanowski:
On cze 27, Jan Kowalsky wrote:
> Hi all,
Hello, sorry for a late reply.
Actually I don't know how you achieve it in most cases to reply
immediately ;-)
> trying to understand the tinc role I wondering if there is an
> possibility to set up mesh network where all tinc tap adapters are part
> of a bridge (br2) on their hosts.
>
> The goal is to have a server cluster where vms on different host can
> share one bridge which is connected through tinc.
Yes, you should be able to connect the Tinc interface to a bridge on each
host, just specify it with the 'bridge' parameter.
> The configuration below results in a situation where none of the hosts
> have a "ConnectTo=" variable in tinc.conf.
You need to specify the list of hosts to connect to using the 'connect_to'
parameter, otherwise a given Tinc node will not try to connect to any other
node by itself. This is valid for example in a situation where a single Tinc
node is accessible on a public IP and other nodes are behind NAT networks,
using that single public node for communication.
> If I use the "link_type: 'dynamic'" we have these variables - but
the
> tap-mesh0 interface itselfs tries to get address via dhcp - which is not
> what I want.
The 'link_type' parameter just changes what parameters will be added
automatically by the role, you should be able to specify them "manually" as
well if needed. The 'static' or 'dynamic' types are kind of like presets,
but
if you have different needs, it should still be possible to implement them.
all right. So we have to to this manually.
So I'll try to put everything in a host group for not to have to add
every host on every host variable and I'll see what happens if the node
itselfs is in connect_to list.
Tinc VPN is designed to implement different kinds of networks - in
some cases
nodes can be behind NAT gateways, in which case other nodes cannot connect to
them directly. The 'ConnectTo' configuration option just tells Tinc to try and
connect to a node automatically, but it's not necessary for its operation. In
this setup, the Tinc nodes behind NAT will try to connect to the "bridge node"
on the public IP address. Afterwards, after the communication has been
estabilished via the bridge node, Tinc should be able to create secondary
connections between the nodes - check the process status via:
kill -USR2 $(pidof tincd)
In the logs you should see which node is connected to which one.
Thanks for this hint. Great.
> Additionally it seem's not so easy to find the right order
for getting
> up bridges and the tap interfaces:
>
> Even if fix the problems above resulting in a setup where on host has
> tap interface on br2 with dhcp server and two other host with tinc via
> bridge configuraion and dhcp: after reboot I have first to restart tinc
> before it's possible to get an ip address through dhclient.
This probably can be solved by defining the dependencies in the systemd unit
configuration. There's an issue about this already on GitHub[1], you could see
if a proposed solution works for your setup.
[1]: https://github.com/debops/debops/issues/1398
yes, I opened this and think understand the problem and maybe find a
solution.
cheers
Jan
1635
days inactive
1639
days old
2 comments
2 participants
participants (2)
-
Jan Kowalsky -
Maciej Delmanowski