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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc> >> >
_______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
