search for: metaconnect

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...

...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 misremem...

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.

...nington <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 the OP's problem. +1 we were running a networkmanager dispatcher[^1] for cases like this :) [^1]: https://github.com/fauno/librevpn/blob/develop/lib/skel/50_tincd -- :> -------------- next part --------------...

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...

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 met...

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...

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)....

...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...

...> running, glibc doesn't automatically notice this. Since tinc 1.0.25 and > 1.1pre11, if you send tincd the ALRM signal, it will force glibc to > reload /etc/resolv.conf. 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 the OP's problem.

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 connect...

...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 misremem...

...st 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 really love if tinc > would simply reload /etc/resolv.conf each time a new metaconnection is made. It's fixed in git now; res_init() is explicitly called before every call to getaddrinfo(). I hope some day the glibc maintainers will see the light that /etc/resolv.conf is not a static file. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.or...

...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-p...

TL;DR: a proposal for a new tinc 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 inte...

...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 at...

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

...gt; >> 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 call res_init() every time tinc retries a metaconnection? It's not >>> doing that very often anyway... and it would solve the OP's problem. > > +1 we were running a networkmanager dispatcher[^1] for cases like this :) > > > [^1]: https://github.com/fauno/librevpn/blob/develop/lib/skel/50_tincd I have some hosts whic...

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...