Thanks, very informative!
I was able to generate this digraph and I'm pleased with it since it
appears that all my servers behind bastion are directly connected, but
nodes outside are not and are routed via bastion
http://imgur.com/zEojkMw
Here is the digraph itself, if the above link is not accessible:
digraph {
bastion [label = "bastion", color = "green"];
consulServer1 [label = "consulServer1", color = "green",
style = "filled"];
consulServer2 [label = "consulServer2", color = "green"];
consulServer3 [label = "consulServer3", color = "green"];
ntTest1 [label = "ntTest1", color = "black"];
ntTest2 [label = "ntTest2", color = "black"];
bastion -> consulServer1 [w = 65537.000000, weight = 65537.000000];
bastion -> consulServer2 [w = inf, weight = inf];
bastion -> consulServer3 [w = 65537.000000, weight = 65537.000000];
bastion -> ntTest1 [w = 800.219482, weight = 800.219482];
bastion -> ntTest2 [w = 781.190491, weight = 781.190491];
consulServer1 -> bastion [w = 65537.000000, weight = 65537.000000];
consulServer1 -> consulServer2 [w = inf, weight = inf];
consulServer1 -> consulServer3 [w = inf, weight = inf];
consulServer2 -> bastion [w = inf, weight = inf];
consulServer2 -> consulServer1 [w = inf, weight = inf];
consulServer2 -> consulServer3 [w = inf, weight = inf];
consulServer3 -> bastion [w = 65537.000000, weight = 65537.000000];
consulServer3 -> consulServer1 [w = inf, weight = inf];
consulServer3 -> consulServer2 [w = inf, weight = inf];
ntTest1 -> bastion [w = 800.219482, weight = 800.219482];
ntTest2 -> bastion [w = 781.190491, weight = 781.190491];
}
I can see how opening up ports on ntTest1 and ntTest2 can enable a direct
connection between them as well.
I have one follow up question:
- Are there any risks to be aware of, with opening and forwarding port 655?
Why would one choose to run tincd on a non-standard port?
-nirmal
On Thu, Jun 22, 2017 at 11:25 AM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Wed, Jun 21, 2017 at 04:57:23PM -0700, Nirmal Thacker wrote:
>
> > What is the significance of port 655 with regards to tinc?
>
> This port is officially reserved for tinc. It is also below number 1024,
> which means that on most operating systems, only a priviliged user can
> listen on that port, and prevents regular users from starting tinc on
> port 655.
>
> However, you don't have to use port 655, you can configure tinc to run
> on any port(s) you like.
>
> > [protected] : protected behind a private network in the cloud
> > [bastion]: also runs in the cloud, has an interface into the private
> > network but also has a public ip. accepts connections on port 655
> > [outside-1]: a laptop behind a home router
> > [outside-2]: similar to outside-1
> >
> > I found that when I ran tinc (v1.1pre14) among these 4 nodes and
dumped a
> > graph at [bastion], there were green edges from [bastion] to all other
> > nodes.
> >
> > But dumping graphs on every other node had a black edge going to all
> other
> > nodes, other than [bastion]
>
> This is because the graph dump shows information known by the local
> node. An edge shows a TCP connection between nodes. Information about
> edges is forwarded to all other nodes. If the local node has a working
> UDP connection to a peer, this will show up as green in its own graph
> dump, otherwise not.
>
> UDP connections are made on demand, so the graph dump doesn't always
> show green even if UDP connection is possible.
>
> > So it appears to be a Star topology?
>
> For the TCP connections, yes.
>
> > But obviously if I started a netcat listener on [protected], at port
> 9999,
> > both [outside-1] and [outside-2] could telnet in using [protected] VPN
> IP.
> > In this case I hope the traffic is going via [bastion].
>
> Tinc will try to make direct connections between [outside-*] and
> [protected], but if that is not possible, it will route traffic via
> [bastion].
>
> > Likewise [outside-1] and [outside-2] could also communicate via a
> > telnet-netcat session using VPN IP's
> > But does it mean this traffic is actually going over [bastion] too?
>
> Again, tinc will try to make a direct connection between, but if that is
> not possible, it will go via [bastion]. In your case, if both
> [outside-1] and [outside-2] are behind the same home router, it could be
> that they cannot communicate with each other via their public
> addresses. You can try to add "LocalDiscovery = yes" to the
tinc.conf of
> both outside nodes.
>
> If they are behind different routers, then it depends on the exact make
> and model whether they will allow UDP hole punching to work.
>
> > In both of those cases I would expect to see orange edges in the
graph,
> but
> > I see only black edges.
>
> Actually, a node will only be orange in the graph if tinc is configured
> such that it will never try to make a direct connection to that node.
> For example, if the IndirectData option is used.
>
> Note that the "tinc info <node>" command gives more clear
information.
>
> > What are the benefits of opening(forwarding) ports 655 on [outside-1]
and
> > [outside-2]? Would they connect directly by learning of each other?
>
> If they are behind different routers, then yes, port forwarding will
> definitely help.
>
> > With regard to host files, all nodes have [bastion] host file only and
> > [bastion] has host files from all nodes
>
> That's fine. Each node will learn about all other nodes via bastion
> then.
>
> --
> 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/20170623/ccde06eb/attachment.html>