Multiple default gateway from tinc node

Thu May 4 03:34:40 CEST 2017

Thank you very much, Guus.

In addition to below, I have another further questions for you:

1. Is there any tools/command, we can show the subnet where a certain tinc nodes learnt? So that I can know the weight for certain subnet, instead of go back to the node’s (who advertise the subnet) configuration file to check.

2. So far in order to change the weight of a subnet, or something else, I have to reset the tinc daemon( tincd -k -n myvpn and then tincd -n myvpn) in order to make it updated, any other better ways to update the configuration and make if effect without big impact.

> On 4 May 2017, at 12:15 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 
> On Wed, May 03, 2017 at 02:15:36PM +0800, Bright Zhao wrote:
> 
>> 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal and final destination for the communication. But during the path, it may be encapsulated into another packet(tunnel mode), where the outside IP header is the physical address, but the inner destination remain unchanged, and I think Tinc encapsulates into UDP packet, where the outside S/D IP is the physical adapter IP address, but the whole original packet was encapsulated into the UDP content part. Conceptually, it’s the same as IPSec site-to-site VPN: http://www.unixwiz.net/images/IPSec-ESP-Tunnel-Mode.gif <http://www.unixwiz.net/images/IPSec-ESP-Tunnel-Mode.gif>
> 
> Yes. But we were talking about traffic and routing inside the tunnels,
> that the VPN packets are encapsulated in UDP packets is not relevant.
> 
>> 2. Regarding the “via 10.0.0.3”, you’re right, it’s only for Ethernet ARP resolution for the next hop. And after my test, my understanding is as below for the routing part of Tinc:
>> 	a. When tinc get up, the tun0 assigned an IP address by tinc-up, let’s say 10.0.0.100/24, this will add an direct attached route into host’s route table which appears as “10.0.0.0 255.255.255.0 tun0”, which is not deletable; this route will enable traffic head to 10.0.0.0/24 will throw into the tun0 interface
> 
> Yes, except that you can delete that route if you want. The route is
> just added as a convenience for you by ifconfig.
> 
>> 	b. Also, if there’s any other traffic need to convey by tinc VPN, you just add another route, for example: “ip route 8.8.8.8/32 dev tun0”, and actually we don’t need to specify the via, since we only need throw the traffic into tun0 interface.
> 
> Correct.
> 
>> 	c. No matter for above a or b, when the traffic send to tun0, from the tunnel’s perspective, the source IP will be 10.0.0.100(since routed through this interface), and the destination IP will be the one I pinged, which is 8.8.8.8
>> 	d. After above c, then the tinc need to figure out how to encapsulate the original packet (S/10.0.0.100 > D/8.8.8.8) into the tunnel and send to the other Tinc node. Then I guess Tinc will check “ADD_SUBNET” messages it received from the ConnectTo node(learn the whole network), and try to encapsulate the original packet into UDP packets, send to the node where its subnet of 8.8.8.8 is preferred(weight setting on Subnet)
> 
> Correct.
> 
>> 	e. If Tinc configured by default, then the local host will try to send UDP packet directly to the preferred host which advertise 8.8.8.8
>> 	f. If IndirectData = yes configured everywhere, then the local host will always encapsulate the UDP packet to the ConnectTo/aly_hk
> 
> Yes.
> 
>>         (No matter 8.8.8.8 is advertised or not), if aly_hk doesn’t advertise 8.8.8.8, it will check it’s Tinc daemon, to see who advertised 8.8.8.8, and then encapsulate UDP to him as the next step to relay
> 
> It does matter whether there is a Subnet advertised that includes
> 8.8.8.8 or not. If the only difference in configuration is whether
> IndirectData is set or not, then packets with a given destination IP
> address will always be sent to the same node.
> 
>> Interestingly, earlier I check the below post for my setup, but now I found, the configuration can be simplified into, because tinc-up will make the 172.16.1.0/24 to $INTERFACE, and for those two default routes, the via is not required as well:
>> 
>> #!/bin/sh
>> VPN_GATEWAY=172.16.1.1
>> ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5`
>> 
>> ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY
>> ip route add $VPN_GATEWAY dev $INTERFACE
>> ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
>> ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE
>> 
>> https://www.tinc-vpn.org/examples/redirect-gateway/ <https://www.tinc-vpn.org/examples/redirect-gateway/>
> 
> Correct. This is also mentioned at the end of that page.
> 
> -- 
> Met vriendelijke groet / with kind regards,
>     Guus Sliepen <guus at tinc-vpn.org>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc