What exactly is the meaning of "Subnet" parameter in tinc/$NETNAME/hosts/$SOMEHOSTNAME?

[Parke]

On Thu, Nov 16, 2017 at 3:56 AM, Philip Blagoveschensky
<philip at crabman.me> wrote:
> Hello, I am not very good at linux networking. I have read tinc documentation
> multiple times and I still don't understand what the "Subnet = ..." directive
> does in /etc/tinc/$NET_NAME/hosts/$HOST_NAME

tincd, running on $HOST_NAME, will deliver packets that match a
"Subnet = ..." directive in its own host config file (on $HOST_NAME)
to the kernel on $HOST_NAME (i.e. to the kernel on the same host).

tincd will advertise these Subnets to all remote nodes, so that those
remote nodes know which tincd can deliver those packets to a kernel.

(The kernel in turn may deliver those packets to another local
process, or forward them out some other interface.)

>From the docs:

----

Subnet = <address[/prefixlength[#weight]]>

The subnet which this tinc daemon will serve. Tinc tries to look up
which other daemon it should send a packet to by searching the
appropriate subnet. If the packet matches a subnet, it will be sent to
the daemon who has this subnet in his host configuration file.
Multiple subnet lines can be specified for each daemon.

[snip]

Source:  https://tinc-vpn.org/documentation/Host-configuration-variables.html

----

> Right now I have a simple virtual lan organized with tinc, and I use the
> following in every device's config file (replacing the last part of the
> address):
>
> # This computer will have this ip address in the vpn
> Subnet = 10.20.30.22/32
>
> This allows me to connect to $HOST_NAME using ip address 10.20.30.22.
>
> Now what I don't understand is why the guides on how to use one of tinc peer as
> the default gateway tell me to write this too:
>
> Subnet = 0.0.0.0/0
>
> I don't understand what this does.
> Why is it not enough to set routes on the client device like this?

If you want to route all traffic on a local LAN over Tinc to a remote
VPS, and then have the remote VPS do NAT and masquerading before
routing the traffic out to its final public destinations over the
public internet, you want the VPS's host config file (on the VPS) to
have Subnet = 0.0.0.0/0 so that the VPS will broadcast to all other
Tinc nodes that the VPS can deliver traffic to any address.  Only
after this happens will other nodes send matching traffic to the VPS.

> Does all this mean, that it's impossible to sometimes use $HOST_NAME_1 as the
> default gateway and sometimes another $HOST_NAME_2, because their
> `Subnet = 0.0.0.0/0` will clash

I don't know what happens when there are multiple routes.  I suspect
Tinc just picks one.  (But I don't know how randomly or how
consistently.)  If all the "clashing" routes are valid and
operational, packets might all make it to their intended destinations.

On Mon, Nov 20, 2017 at 9:51 AM, Philip Blagoveschensky
<philip at crabman.me> wrote:
> Are you saying that if I want to reach XXX.XXX.XXX.XXX/32 via $HOST2 from $HOST1, then I not
> only need to set route 'XXX.XXX.XXX.XXX/32 via ip-address-of-$HOST2 dev
> tinc-dev' on $HOST1, but also need to have tinc Subnet records for $HOST2 that at
> least include 'Subnet = XXX.XXX.XXX.XXX/32'?

Yes, I believe that is correct.

> And if I don't include that subnet in tinc configuration, but only set route on
> $HOST1 and allow packet forwarding on $HOST2, then it won't work?

I believe that the kernel routing table tells the kernel which packets
should be routed into tinc.

Once packets are inside tinc, the Subnet directives in the host files
are used to determine which tinc node (if any) wants to receive those
packets.

Note that each host only reads its own Subnet directives from the host
config files.  Each host will ignore all the Subnet directives for
remote nodes.  In other words, remote Subnets are learned from messages
broadcast over tinc (not from the local host config files).

See the StrictSubnets variable for more info:
https://tinc-vpn.org/documentation/Main-configuration-variables.html

Cheers,

Parke