Multiple default gateway from tinc node
Guus Sliepen
guus at tinc-vpn.org
Wed May 3 18:15:38 CEST 2017
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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170503/531c6528/attachment.sig>
More information about the tinc
mailing list