Hi, Guus I did some test regarding the points you mentioned below, and yes, you’re right, but some of points may need further adjusted: 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> 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 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. 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) 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 (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 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/>> On 3 May 2017, at 12:36 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > > On Tue, May 02, 2017 at 09:53:15PM +0800, Bright Zhao wrote: > >> When tinc daemon get up on A(together with some manual scripts for destination to 8.8.8.8), the route table looks like below: >> 10.0.0.0/24 dev tun0 >> 10.0.0.3 dev tun0 >> 8.8.8.8 via 10.0.0.3 dev tun0 > > IPv4 packets have only two addresses in their header: the source and the > destination address. If you want to send a packet to 8.8.8.8, the > destination address of the packet will always be 8.8.8.8, regardless of > how it is forwarded via the network. > > Imagine that your local node would replace the destination address with > 10.0.0.3, then the information about the final destination (8.8.8.8) > would be lost. > > The "via 10.0.0.3" only has an effect on Ethernet networks. Ethernet > doesn't know about IPv4 or IPv6, it only knows about MAC addresses. What > "via 10.0.0.3" does is that when it has to send a packet to 8.8.8.8, it > sets the IPv4 header's destination address to 8.8.8.8, but it sets the > Ethernet header's destination address to the MAC address of the host > which has the address 10.0.0.3. It figured out the last part by doing > ARP resolution. > > It's perhaps a bit confusing that there is no error message when you try > to add such a route, even though the "via 10.0.0.3" part doesn't do > anything. It's just ignored for non-Ethernet networks. Also, on some > (older) BSD platforms, you could not add a route to a "dev tun0", you > could only identify interfaces by their IP address. So there the > equivalent of "via" would have an effect, but also not the one you > intended. > > -- > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170503/90521c30/attachment.html>
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 interfaceYes, 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_hkYes.> (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 relayIt 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>
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