search for: metaconnections

It seems like that kind of problem could be solved by making sure that tinc continues PINGing over TCP metaconnections even when an UDP tunnel is established, to keep the metaconnection alive. In fact I was under the impression that the 1.1 branch already did that or that I had submitted some code to do that at some point in the past, but it looks like I maybe be misremembering things. On 13 September 2017 at 16:1...

...s any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017 at 08:02:11PM +0100, Etienne Dechamps wrote: > > > It seems like that kind of problem could be solved by making sure that > tinc > > continues PINGing over TCP metaconnections even when an UDP tunnel is > > established, to keep the metaconnection alive. In fact I was under the > > impression that the 1.1 branch already did that or that I had submitted > > some code to do that at some point in the past, but it looks like I maybe > > be misrememberi...

We have a handful of nodes set up. Some are NAT'd but a few have direct access to the Internet. Sample confs: HostA: Name = HostA AddressFamily = any Interface = tap0 Mode = switch Connectto = HostB GraphDumpFile = /tmp/mesh HostB: Name = HostB AddressFamily = any Interface = tap0 Mode = switch Connectto = HostA GraphDumpFile = /tmp/mesh And so on. If I use HostA as the main meta sever.

William Kennington <william at wkennington.com> writes: > Agreed. > On Feb 1, 2015 4:21 AM, "Etienne Dechamps" <etienne at edechamps.fr> wrote: > >> Considering how cheap that operation seems to be, would it make sense >> to call res_init() every time tinc retries a metaconnection? It's not >> doing that very often anyway... and it would solve

Hi, we use a tinc network of about 400 nodes, all of them linux servers, partly in different datacenters (but generally low latency). Usually this is working very well (for weeks without a problem). >From time to time the whole network goes down though. This happened when we restarted a larger number of servers or when there was a connectivity issue between datacenters or some (short)

...EX message the other nodes will >> send both KEX and SIG messages at the same time. However, the node >> expects SIG to arrive after KEX. Therefore, there is an implicit >> assumption that messages won't arrive out of order. tinc makes no such >> guarantee, even over TCP metaconnections, because there is no >> guarantee the two messages will travel along the same path (consider >> the case where there is a change in the graph while the KEX and SIG >> messages are traveling). In fact, messages can even be lost if a node >> responsible for forwarding them cra...

tinc uses direct UDP communication for performance, not reliability. If you want to establish more metaconnections for increased reliability, you can use AutoConnect (though it probably won't work across NATs). A better solution is to use two central nodes (instead of one) for redundancy. On 11 June 2015 at 18:59, Daniel J. Grinkevich <danielgrinkevich at gmail.com> wrote: > If we have one meta no...

On Wed, Sep 13, 2017 at 08:02:11PM +0100, Etienne Dechamps wrote: > It seems like that kind of problem could be solved by making sure that tinc > continues PINGing over TCP metaconnections even when an UDP tunnel is > established, to keep the metaconnection alive. In fact I was under the > impression that the 1.1 branch already did that or that I had submitted > some code to do that at some point in the past, but it looks like I maybe > be misremembering things. Tinc alw...

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of metaconnections). So,...

...from key > updates) since each host can connect to every other host and all the host > config files are available everywhere locally. In that case, you might want to have a look at the tinc 1.1 prerelease, remove the ConnectTo's and enable the AutoConnect feature. This will let tinc make metaconnections automatically in a more distributed way. It will also switch metaconnections to different nodes in case the ones it is connecting to fail. > We also thought about using TunnelServer = yes, would this help? That might help, but then you lose most of the peer-to-peer connectivity. The reason is...

On Sun, Feb 1, 2015 at 11:19 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Feb 01, 2015 at 04:08:47PM +0900, crocket wrote: > >> If tincd is started before name resolution comes up, it keeps failing >> for ever to resolve domain names in Address= host configuration >> variable after name resolution becomes possible. >> >> I think tincd should

On 09/03/2016 10:56 AM, Etienne Dechamps wrote: > C will still need keys in order to establish metaconnections with A and B (as > well as a few other things). However there is no need for C to own any > "Subnets" at all. If somebody breaks into C, he could get access to the vpn network, right? Because the keys are there, it will be possible to use them to get access. Even if A-B connections...

...uus Sliepen <guus at tinc-vpn.org <mailto:guus at tinc-vpn.org>>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017 at 08:02:11PM +0100, Etienne Dechamps wrote: > > > It seems like that kind of problem could be solved by making sure that tinc > > continues PINGing over TCP metaconnections even when an UDP tunnel is > > established, to keep the metaconnection alive. In fact I was under the > > impression that the 1.1 branch already did that or that I had submitted > > some code to do that at some point in the past, but it looks like I maybe > > be misrememberi...

On Mon, Feb 09, 2015 at 10:57:05AM +0100, Florian Klink wrote: > I have some hosts which converted to systemd-networkd (which doesn't > support hooks by now), and most of the time, tinc simply won't come up > after bootup (or won't be able to reconnect when the network is > changed), which is really ugly. > > Having a local dns in front is somewhat hacky, I'd

...ince each host can connect to every other host and all the host > > config files are available everywhere locally. > > In that case, you might want to have a look at the tinc 1.1 prerelease, > remove the ConnectTo's and enable the AutoConnect feature. This will let > tinc make metaconnections automatically in a more distributed way. It > will also switch metaconnections to different nodes in case the ones it > is connecting to fail. > > > We also thought about using TunnelServer = yes, would this help? > > That might help, but then you lose most of the peer-to-peer...

...feature that allows nodes to filter ADD_SUBNET messages based on the metaconnection on which they are received, so that nodes can't impersonate each other's VPN Subnets. Similar to StrictSubnets in spirit, but way more flexible. BACKGROUND: THE ISSUE OF TRUST IN A TINC NETWORK In terms of metaconnections (I'm not discussing data tunnels here), one of the most interesting properties of tinc is that users are free to come up with any topology for the node graph; this makes tinc extremely flexible. For example, one can come up with a full mesh graph where every node is connected to every other nod...

...ieve Guus has plans to introduce more sophisticated mechanisms in the future. In any case, I should probably mention that, to the best of my knowledge (Guus might be able to confirm), right now tinc is mostly designed to protect from attacks coming from *outside* the VPN (as in, outside the web of metaconnections). Protecting against insider attacks (from inside the metagraph) doesn't get anywhere near as much attention. This means it is more likely that there are vulnerabilities lurking in the code that we're not aware of. Compared to an outside attacker, an inside attacker has a much larger attack...

Hi, Etienne I took a look for the below host configuration parameter (IndirectData), the default is no. For the below example: A ConnectTo B, B ConnectTo C: If IndirectData = no (default), then A wouldn’t establish direct connection with C, but will be forwarded by B. If IndirectData = yes, then A will try to establish direct connection with C, even though A don’t have the statement of

Am 02.02.2015 um 19:32 schrieb Nicol?s Reynolds: > William Kennington <william-5Om/gJxqp8Dx9BLsLxWUfA at public.gmane.org> writes: > >> Agreed. >> On Feb 1, 2015 4:21 AM, "Etienne Dechamps" <etienne-ypMCQUleWbRvynnTyRI/EA at public.gmane.org> wrote: >> >>> Considering how cheap that operation seems to be, would it make sense >>> to

Hi, is it possible to run two tinc hosts to make failover in case of crash of one tinc host? Or should I switch to tinc 1.1? ALBI...