tinc - May 2017 - How to set Subnet in a node which act as both server and client role?

Hi, Etienne

In addition, is there any option or switch can turn of the automatic direct
connection? For the example below, even A has the route to C and can establish
UDP connection directly, but I need the traffic to go through B, how can I
achieve that easily? (instead of remove something from A’s routing table, or
manually block the connection between A and C)
> On 1 May 2017, at 6:28 PM, Bright Zhao <startryst at gmail.com>
wrote:
> 
> Hi, Etienne
> 
> Exactly, I just did the test, remove the Subnet = X/32 from B, so I
understood that the Subnet on host configuration is indicate local attached
network, or let’s call it when going outside of the VPN domain.
> 
> And yes, A will try to establish UDP connection direct to C (if it has the
route), so the first time, I can ping from A to X, and I found the traffic
didn’t go through B, but second time, I remove the C route from A’s routing
table, then the traffic sent to B, and B sent to C; which exactly the same as
you indicate below.
> 
> Thank you very much, this makes me much better understanding on Tinc.
> 
>> On 1 May 2017, at 6:23 PM, Etienne Dechamps <etienne at edechamps.fr
<mailto:etienne at edechamps.fr>> wrote:
>> 
>> There is no concept of "client" or "server" in
tinc. tinc is purely peer-to-peer. "ConnectTo" statements only
indicate which node will attempt to establish the initial connection, but once
the connection is established, direction does not matter.
>> 
>> It is unclear from your message which node is responsible for which
subnet. If X/32 truly belongs to C, then simply set Subnet = X/32 in C's
local host file. If you do that, then C will advertise this subnet to the rest
of the network, including B and A. There is no need to change anything in
B's configuration. tinc will take care of the routing for you, and A will be
informed (through the tinc protocol) that the subnet belongs to C, and that any
packets meant for X should therefore be sent to C.
>> 
>> These packets will then be sent directly to C using UDP (tinc is clever
and will try various NAT traversal techniques). If that's not possible for
any reason, tinc will automatically fall back to relaying packets through B.
>> 
>> On 1 May 2017 at 11:00, Bright Zhao <startryst at gmail.com
<mailto:startryst at gmail.com>> wrote:
>> Hi, Tinc experts
>> 
>> Diagram as below, A is trying to access host X behind C:
>> 
>> A >> B >> C — “host X"
>> 
>> B is the tinc server for A, but also B is the tinc client to connect to
C.
>> 
>> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
configuration for B will be tricky.
>> 
>> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B)
needs have the Subnet = X/32, which indicate the VPN serve for this host.
>> But as the tinc client to C, B’s host config shouldn’t include Subnet =
X/32, because X/32 is behind C.
>> 
>> If not direct connection available from A to C, the only way I can
figure it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>> 
>> A >> vpn1 >> B >> vpn2 >> C — “host X”
>> 
>> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.
>> 
>> Let me know if there’s any other simple way to achieve this.
>> _______________________________________________
>> tinc mailing list
>> tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
<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/20170501/1ee13c67/attachment-0001.html>

Yes. Look up the "IndirectData" configuration option.

On 1 May 2017 at 11:30, Bright Zhao <startryst at gmail.com> wrote:
> Hi, Etienne
>
> In addition, is there any option or switch can turn of the automatic
> direct connection? For the example below, even A has the route to C and can
> establish UDP connection directly, but I need the traffic to go through B,
> how can I achieve that easily? (instead of remove something from A’s
> routing table, or manually block the connection between A and C)
>
> On 1 May 2017, at 6:28 PM, Bright Zhao <startryst at gmail.com>
wrote:
>
> Hi, Etienne
>
> Exactly, I just did the test, remove the Subnet = X/32 from B, so I
> understood that the Subnet on host configuration is indicate local attached
> network, or let’s call it when going outside of the VPN domain.
>
> And yes, A will try to establish UDP connection direct to C (if it has the
> route), so the first time, I can ping from A to X, and I found the traffic
> didn’t go through B, but second time, I remove the C route from A’s routing
> table, then the traffic sent to B, and B sent to C; which exactly the same
> as you indicate below.
>
> Thank you very much, this makes me much better understanding on Tinc.
>
> On 1 May 2017, at 6:23 PM, Etienne Dechamps <etienne at edechamps.fr>
wrote:
>
> There is no concept of "client" or "server" in tinc.
tinc is purely
> peer-to-peer. "ConnectTo" statements only indicate which node
will attempt
> to establish the initial connection, but once the connection is
> established, direction does not matter.
>
> It is unclear from your message which node is responsible for which
> subnet. If X/32 truly belongs to C, then simply set Subnet = X/32 in
C's
> local host file. If you do that, then C will advertise this subnet to the
> rest of the network, including B and A. There is no need to change anything
> in B's configuration. tinc will take care of the routing for you, and A
> will be informed (through the tinc protocol) that the subnet belongs to C,
> and that any packets meant for X should therefore be sent to C.
>
> These packets will then be sent directly to C using UDP (tinc is clever
> and will try various NAT traversal techniques). If that's not possible
for
> any reason, tinc will automatically fall back to relaying packets through
B.
>
> On 1 May 2017 at 11:00, Bright Zhao <startryst at gmail.com> wrote:
>
>> Hi, Tinc experts
>>
>> Diagram as below, A is trying to access host X behind C:
>>
>> A >> B >> C — “host X"
>>
>> B is the tinc server for A, but also B is the tinc client to connect to
C.
>>
>> My question is, if I only use one VPN (/etc/tinc/myvpn), then the host
>> configuration for B will be tricky.
>>
>> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B)
needs
>> have the Subnet = X/32, which indicate the VPN serve for this host.
>> But as the tinc client to C, B’s host config shouldn’t include Subnet
>> X/32, because X/32 is behind C.
>>
>> If not direct connection available from A to C, the only way I can
figure
>> it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>>
>> A >> vpn1 >> B >> vpn2 >> C — “host X”
>>
>> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
>> /etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client
side
>> for C.
>>
>> Let me know if there’s any other simple way to achieve this.
>> _______________________________________________
>> 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/20170501/f4c68776/attachment-0001.html>

Hi, Etienne

I took a look for the below host configuration parameter (IndirectData), the
default is no. For the below example:

A ConnectTo B, B ConnectTo C:

If IndirectData = no (default), then A wouldn’t establish direct connection with
C, but will be forwarded by B.
If IndirectData = yes, then A will try to establish direct connection with C,
even though A don’t have the statement of ConnectTo = C

IndirectData = <yes|no> (no)
This option specifies whether other tinc daemons besides the one you specified
with ConnectTo can make a direct connection to you. This is especially useful if
you are behind a firewall and it is impossible to make a connection from the
outside to your tinc daemon. Otherwise, it is best to leave this option out or
set it to no.



Also in Main configuration there’s another parameter (DirectOnly), the default
is no, to continue the above example:

A ConnectTo B, B ConnectTo C:

If DirectOnly = no(default), and IndirectData = no(default): A can only sent
data to B, and B will forwarded to C.
If DirectOnly = no(default), and IndirectData = yes: A will try to send data
directly to C, but if A can’t send to C directly, then B will help to forward
If DirectOnly = yes, and IndirectData = no(default): A can’t connect with C
If DirectOnly = yes, and IndirectData = yes: A will try to send data directly to
C, but if A can’t sent to C directly, B wouldn’t help to forward.


My understanding right?

DirectOnly = <yes|no> (no) [experimental]
When this option is enabled, packets that cannot be sent directly to the
destination node, but which would have to be forwarded by an intermediate node,
are dropped instead. When combined with the IndirectData option, packets for
nodes for which we do not have a meta connection with are also dropped.



> On 1 May 2017, at 6:33 PM, Etienne Dechamps <etienne at edechamps.fr>
wrote:
> 
> Yes. Look up the "IndirectData" configuration option.
> 
> On 1 May 2017 at 11:30, Bright Zhao <startryst at gmail.com
<mailto:startryst at gmail.com>> wrote:
> Hi, Etienne
> 
> In addition, is there any option or switch can turn of the automatic direct
connection? For the example below, even A has the route to C and can establish
UDP connection directly, but I need the traffic to go through B, how can I
achieve that easily? (instead of remove something from A’s routing table, or
manually block the connection between A and C)
> 
>> On 1 May 2017, at 6:28 PM, Bright Zhao <startryst at gmail.com
<mailto:startryst at gmail.com>> wrote:
>> 
>> Hi, Etienne
>> 
>> Exactly, I just did the test, remove the Subnet = X/32 from B, so I
understood that the Subnet on host configuration is indicate local attached
network, or let’s call it when going outside of the VPN domain.
>> 
>> And yes, A will try to establish UDP connection direct to C (if it has
the route), so the first time, I can ping from A to X, and I found the traffic
didn’t go through B, but second time, I remove the C route from A’s routing
table, then the traffic sent to B, and B sent to C; which exactly the same as
you indicate below.
>> 
>> Thank you very much, this makes me much better understanding on Tinc.
>> 
>>> On 1 May 2017, at 6:23 PM, Etienne Dechamps <etienne at
edechamps.fr <mailto:etienne at edechamps.fr>> wrote:
>>> 
>>> There is no concept of "client" or "server" in
tinc. tinc is purely peer-to-peer. "ConnectTo" statements only
indicate which node will attempt to establish the initial connection, but once
the connection is established, direction does not matter.
>>> 
>>> It is unclear from your message which node is responsible for which
subnet. If X/32 truly belongs to C, then simply set Subnet = X/32 in C's
local host file. If you do that, then C will advertise this subnet to the rest
of the network, including B and A. There is no need to change anything in
B's configuration. tinc will take care of the routing for you, and A will be
informed (through the tinc protocol) that the subnet belongs to C, and that any
packets meant for X should therefore be sent to C.
>>> 
>>> These packets will then be sent directly to C using UDP (tinc is
clever and will try various NAT traversal techniques). If that's not
possible for any reason, tinc will automatically fall back to relaying packets
through B.
>>> 
>>> On 1 May 2017 at 11:00, Bright Zhao <startryst at gmail.com
<mailto:startryst at gmail.com>> wrote:
>>> Hi, Tinc experts
>>> 
>>> Diagram as below, A is trying to access host X behind C:
>>> 
>>> A >> B >> C — “host X"
>>> 
>>> B is the tinc server for A, but also B is the tinc client to
connect to C.
>>> 
>>> My question is, if I only use one VPN (/etc/tinc/myvpn), then the
host configuration for B will be tricky.
>>> 
>>> As the tinc server to A, B’s host config (/etc/tinc/myvpn/hosts/B)
needs have the Subnet = X/32, which indicate the VPN serve for this host.
>>> But as the tinc client to C, B’s host config shouldn’t include
Subnet = X/32, because X/32 is behind C.
>>> 
>>> If not direct connection available from A to C, the only way I can
figure it out is to setup two VPNs, /etc/tinc/vpn1 and /etc/tinc/vpn2:
>>> 
>>> A >> vpn1 >> B >> vpn2 >> C — “host X”
>>> 
>>> If so, the /etc/tinc/vpn1/hosts/B can have Subnet =X/32; but the
/etc/tinc/vpn2/hosts/B can exclude Subnet =X/32 since it’s the client side for
C.
>>> 
>>> Let me know if there’s any other simple way to achieve this.
>>> _______________________________________________
>>> tinc mailing list
>>> tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
>>> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
<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/20170501/65deeeb5/attachment.html>