> Then I remove the “ConnectTo = B” statement from A when you do this, means just the A will not setup a metadata connection to B on startup.
Please read this email from the archive: https://www.tinc-vpn.org/pipermail/tinc/2010-April/002288.html Yes, it was 7 years ago. But if you are using tinc 1.0.x your should find your answers on that thread. Cheers Saverio 2017-06-01 4:21 GMT+02:00 Bright Zhao <[email protected]>: > Hi, All > > Here is the case: > > A, B, C, D all configured with "IndirectData = yes”, so connection only > happens when there’s a “ConnectTo” in tinc.conf. > Arrow indicate the “ConnectTo” direction > > Everything works fine earlier as below: > > 1. A connect to C, D connect to C > 2. C is the transit node where only forward traffic between A and C > 3. D advertise 0.0.0.0/0#2 > 4. A can access internet from D through C, no problem at all > > What I did yesterday: > 5. A connect to B > 6. B advertise 0.0.0.0/0#1 > > Then I thought the traffic will go through B directly if B is reachable, > but when B is down, traffic will fallback to D(through C), but > interestingly, when the step 5 and 6 are done, I found the traffic seems > goes to B though C(not directly), which is not under my earlier expectation. > > Then I remove the “ConnectTo = B” statement from A, but interestingly, at > this time, the traffic still goes to B through C. From what I know from > tinc, if the “ConnectTo” is removed, and IndirectData = yes every where, > this shouldn’t happen. And from the tcp connection perspective on A at this > moment, it indeed only connect to C, no connection to B at all. > > Then I investigate further, I found the advertised route from B still > exist on C, where it shows something like below: > > *2017-06-01T09:00:29.558712+08:00 C tincd: 0.0.0.0/0#1 > <http://0.0.0.0/0#1> owner B (That’s the reason, why C received the packet > from A forward to B even A is not connected to B, in this case I have to > stop the tinc daemon on B in order to make traffic goes back to D)* > > After tincd -n myvpn -kWINCH on A/C/D, then all the old unreachable info > is gone. > > So questions here: > > 1. Why in the my case, the traffic will go A>C>B path even A is not > connect to B? > 2. Why the unreachable info and the related advertised subnet info still > exist in C even the A remove the ConnectTo statement to B(all IndirectData > = yes)? Should I run a crontab to WINCH all the outdated connection > regularly to avoid this? Sounds not that way…looking for advice. > > > > _______________________________________________ > tinc mailing list > [email protected] > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
