LocalDiscovery flip flopping and network design tips
Guus Sliepen
guus at tinc-vpn.org
Tue Feb 14 19:46:11 CET 2017
On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote:
> Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and
> 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp
> is open to the world. The tinc_test_2 box has a ConnectTo of tinc_test_1.
> When tinc_test_2 is started, it prints out:
> UDP address of tinc_test_1 set to 104.154.59.151 port 655
> UDP address of tinc_test_1 set to 10.240.0.4 port 655
> UDP address of tinc_test_1 set to 104.154.59.151 port 655
> UDP address of tinc_test_1 set to 10.240.0.4 port 655
> repeatedly for a minute or so before finally settling on 10.240.0.4.
>
> Is there a reason it's flip flopping? Is that expected? Am I doing
> something wrong?
No, you are not doing anything wrong. Although I've not seen this kind
of flip-flopping behavior myself, it is possible this behaviour occurs,
although it should only happen in the first 10 seconds or so. When
LocalDiscovery is enabled, tinc tries to send probe packets to both the
address it learned from its TCP connections and to the local network.
When receiving a valid packet, it notes the source address of that
packet. If it is different from the source address of the previous valid
UDP packet, a log message is printed about it.
> Additionally, we have multiple Google Compute regions with their own
> subnets and external DCs with their own subnets and we'd like to install
> tinc on all servers but keep inner-Google traffic to the internal IPs and
> not over external IPs since it's an order of magnitude cheaper. My first
> thinking is a hub and spoke model. We have 2 boxes in each subnet that have
> port 655 open to the world, and all the other servers have 655 open to
> internal ips only. With LocalDiscovery (as well as IndirectData = yes on
> "non-public" servers) this works work pretty well, as far as I can tell.
> But it wouldn't solve the inner-Google traffic between subnets since Google
> Subnet0 would talk over public to Google Subnet1. What's the best way of
> doing something like this? I was thinking maybe 2 instances of tinc on the
> "public" boxes, but Google servers only have a single interface, eth0, that
> has the internal IP, so I couldn't listen on the external and internal IPs
> separately.
You can use BindToAddress to have tinc bind to a specific IP address. So
you can have two tinc daemons, one binding to the internal IP address,
and another to the external IP address, even if they are residing on the
same network interface. Would that help?
--
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: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170214/99f64ce3/attachment.sig>
More information about the tinc
mailing list