On 30.08.2016 17:37, Guus Sliepen wrote:> On Tue, Aug 30, 2016 at 02:38:16PM +0200, Armin Schindler wrote: > >> we use a meshed VPN with TINC to connect 7 offices. >> Some office are in other countries and use other ISPs. The connection >> between some ISPs (peering partners) are not that good. This means we >> have packet loss between those direct connections. >> >> To avoid this direct connection, I would like to tell TINC to use >> a defined other host to route the packets to. >> E.g. >> instead of doing direct office-1 to office-2, send always packets >> for office-2 to office-5 (because connection with office-5 is very stable). >> >> Is there a way to configure TINC to not use direct connection >> for one host, but use a specified, other host for that? > > You can set IndirectData = yes in hosts/office-2 on hosts/office-1, and > vice versa, to prevent it from trying a direct connection. > > Note that you also should not have ConnectTo = office-2 in office-1's > tinc.conf, and vice versa, otherwise the above will not have any effect.Understood. But this will keep tinc from doing direct only, but it may use *any* other host to transfer the data, right? I would like to set a specific host (with best connection) to be the 'man-in-the-middle'. Armin
Guus Sliepen
2016-Aug-31 12:16 UTC
Define which host to use when direct link not possible?
On Wed, Aug 31, 2016 at 10:47:01AM +0200, Armin wrote:> >You can set IndirectData = yes in hosts/office-2 on hosts/office-1, and > >vice versa, to prevent it from trying a direct connection. > > > >Note that you also should not have ConnectTo = office-2 in office-1's > >tinc.conf, and vice versa, otherwise the above will not have any effect. > > Understood. But this will keep tinc from doing direct only, but it may > use *any* other host to transfer the data, right?Correct.> I would like to set a specific host (with best connection) to be the > 'man-in-the-middle'.Then have the man-in-the-middle set "Weight = 0" in its host config file. That will cause it to get a higher priority when deciding how to route packets if there are multiple paths with the same number of hops. -- 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/20160831/7b7a6a0d/attachment.sig>
On 31.08.2016 14:16, Guus Sliepen wrote:> On Wed, Aug 31, 2016 at 10:47:01AM +0200, Armin wrote: > >>> You can set IndirectData = yes in hosts/office-2 on hosts/office-1, and >>> vice versa, to prevent it from trying a direct connection. >>> >>> Note that you also should not have ConnectTo = office-2 in office-1's >>> tinc.conf, and vice versa, otherwise the above will not have any effect. >> >> Understood. But this will keep tinc from doing direct only, but it may >> use *any* other host to transfer the data, right? > > Correct. > >> I would like to set a specific host (with best connection) to be the >> 'man-in-the-middle'. > > Then have the man-in-the-middle set "Weight = 0" in its host config > file. That will cause it to get a higher priority when deciding how to > route packets if there are multiple paths with the same number of hops.I did this in the hosts file in office-1, but it has no effect. Maybe it is overwritten when the real config from man-in-the-middle is known? Setting this Subnet and its Weight in the hosts file on the man-in-the-middle doesn't work. The routing then seems to be messed up and it would be wrong anyway to tell all nodes to route office-1, office-2 via that man-in-the-middle. This should be done for the connection between office-1 and office-2 only. Armin
Le 31/08/2016 à 10:47, Armin a écrit :> On 30.08.2016 17:37, Guus Sliepen wrote: >> On Tue, Aug 30, 2016 at 02:38:16PM +0200, Armin Schindler wrote: >> >>> we use a meshed VPN with TINC to connect 7 offices. >>> Some office are in other countries and use other ISPs. The connection >>> between some ISPs (peering partners) are not that good. This means we >>> have packet loss between those direct connections. >>> >>> To avoid this direct connection, I would like to tell TINC to use >>> a defined other host to route the packets to. >>> E.g. >>> instead of doing direct office-1 to office-2, send always packets >>> for office-2 to office-5 (because connection with office-5 is very >>> stable). >>> >>> Is there a way to configure TINC to not use direct connection >>> for one host, but use a specified, other host for that? >> >> You can set IndirectData = yes in hosts/office-2 on hosts/office-1, and >> vice versa, to prevent it from trying a direct connection. >> >> Note that you also should not have ConnectTo = office-2 in office-1's >> tinc.conf, and vice versa, otherwise the above will not have any effect. > > Understood. But this will keep tinc from doing direct only, but it may > use *any* other host to transfer the data, right? > > I would like to set a specific host (with best connection) to be the > 'man-in-the-middle'. > > ArminMaybe you should try with the route metric. Play with what Guus say (indirectdata) and using different metric for your route. Small metric for your favorite host, and bigger metric for the other. You have to play with the routing system, but maybe just add route to office 2 on office 5, and say that office 5 is the GW for office 2 on the other router. I don't know if this will work but you can try.
On 02.09.2016 08:33, Sich wrote:> > > Le 31/08/2016 à 10:47, Armin a écrit : >> On 30.08.2016 17:37, Guus Sliepen wrote: >>> On Tue, Aug 30, 2016 at 02:38:16PM +0200, Armin Schindler wrote: >>> >>>> we use a meshed VPN with TINC to connect 7 offices. >>>> Some office are in other countries and use other ISPs. The connection >>>> between some ISPs (peering partners) are not that good. This means we >>>> have packet loss between those direct connections. >>>> >>>> To avoid this direct connection, I would like to tell TINC to use >>>> a defined other host to route the packets to. >>>> E.g. >>>> instead of doing direct office-1 to office-2, send always packets >>>> for office-2 to office-5 (because connection with office-5 is very >>>> stable). >>>> >>>> Is there a way to configure TINC to not use direct connection >>>> for one host, but use a specified, other host for that? >>> >>> You can set IndirectData = yes in hosts/office-2 on hosts/office-1, and >>> vice versa, to prevent it from trying a direct connection. >>> >>> Note that you also should not have ConnectTo = office-2 in office-1's >>> tinc.conf, and vice versa, otherwise the above will not have any effect. >> >> Understood. But this will keep tinc from doing direct only, but it may >> use *any* other host to transfer the data, right? >> >> I would like to set a specific host (with best connection) to be the >> 'man-in-the-middle'. >> >> Armin > > Maybe you should try with the route metric. > Play with what Guus say (indirectdata) and using different metric for > your route. Small metric for your favorite host, and bigger metric for > the other. > You have to play with the routing system, but maybe just add route to > office 2 on office 5, and say that office 5 is the GW for office 2 on > the other router. > > I don't know if this will work but you can try.I found another solution. I use the weight as Guus wrote, but since this setting is overwritten when this host "learned" subnets from other hosts, I use "StrictSubnets = yes" in tinc.conf of that host. With this the other hosts/offices use all routing features of tinc, but the 2 special offices with StrictSubnets have specific settings where to send the packets. StrictSubnets is marked as experimental. Is it not fully tested yet? So far it seems to work pretty good here. Thank you. Armin
Maybe Matching Threads
- Define which host to use when direct link not possible?
- Define which host to use when direct link not possible?
- Define which host to use when direct link not possible?
- Define which host to use when direct link not possible?
- Route certain trafic via a tinc node that is not directly connected.