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

Reply via email to