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