<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000099">
<font face="Helvetica, Arial, sans-serif">To connect LXC containers
to remote OpenVZ containers I setup the LXC Host as a router
listening on a globally routable ipv6 address. The containers
connect to the router initially & then communicate with each
other directly over non globally routable <a
href="https://www.sixxs.net/tools/grh/ula/">ipv6 private ULA
addresses</a>.<br>
<br>
This setup avoids any overhead & problems with NAT & is
reasonably secure with services listening on non public ipv6
address. Using Tinc 1.1pre10 with <i>ExperimentalProtocol = yes</i>
& <i>AutoConnect = 3</i> gives a robust connection. You will
find Tinc 1.1 generates host files / ECDSA keys for other machines
it discovers automatically. The clients will ConnectTo any machine
they have a host file for without this needing to be set in
tinc.conf (the clients only need a single ConnectTo for the
router).<br>
<br>
With Tinc1.1 the only thing I found I couldn't do is bind the
daemons to an ip address or interface. Restricting listening to
ip4 or ip6 works just fine (<i>AddressFamily = ipv6</i>). I found
the latency to be much better with Tinc1.1<br>
<br>
Stuart.<br>
<br>
<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 09/27/2014 06:36 AM, raul wrote:<br>
</div>
<blockquote
cite="mid:CAOLRk5nFYTqQ9u_Zfg0hta9y75G4AL-k+6ofnrwmviqQrwrSNw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Ok, I just tried this, and additional
containers on the same network need a
'ConnectTo' to work, I tried the
LocalDiscovery option too, but to no go. I
guess this topography is unique without a
clear use case beyond connecting at the
container rather than host level, and and
trying to keep as much of the networking in
the containers as possible.<br>
<br>
</div>
This is the scenario, and the objective is to
keep as much of the networking state on the
containers as possible, so the host is
relatively untouched.<br>
<br>
</div>
1. Host A with public IP 1.2.3.4 has 5
containers on a NAT bridge <a
moz-do-not-send="true"
href="http://10.0.3.0/24" target="_blank">10.0.3.0/24</a>
<br>
<br>
</div>
2. Host B with public IP 2.3.4.5 has 5 containers
on a NAT bridge <a moz-do-not-send="true"
href="http://10.0.4.0/24" target="_blank">10.0.4.0/24</a><br>
<br>
</div>
3. I do a basic install of Tinc on 2 containers on
either side - Container A and Container B, and give
them 10.0.0.1 and 10.0.0.2, and set Tinc on Con B to
connect to Tinc on Con A via (port forwarded 655
udp/tcp to 1.2.3.4)<br>
<br>
</div>
4. I port forward 655 udp/tcp on Host A 1.2.3.4 so
Tinc Con B can connect to Tinc Con A<br>
<br>
</div>
5. At the end of this Con A and Con B can ping each
other. <br>
<br>
</div>
6. Now suppose on Host A, I install Tinc on one more
container - Container C, give it 10.0.0.3 and share the
host files of Con A and B.<br>
<br>
</div>
7. Con A and Con B cannot ping Con C, untill I add a
'ConnectTo' on Con C to connect to Con A at its Con A's NAT
IP 10.0.3.4.<br>
<br>
</div>
8. Its only at this point that all Con A, Con B and Con C can
connect to each other. <br>
<br>
</div>
I guess this can be a mesh overlay network, but is also complex
and there may be some tricks to make this work more seamlessly.
It may have some uses but for normal use cases perhaps best to
just install Tinc on Host A and B which will anyway enable the
containers to connect to each other seamlessly.
<div class="">
<div id=":1iy" class="" tabindex="0"><img
moz-do-not-send="true" class=""
src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 26, 2014 at 2:22 AM,
Etienne Dechamps <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:etienne@edechamps.fr"
target="_blank">etienne@edechamps.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On Thu, Sep 25, 2014 at 8:50 PM, raul <<a
moz-do-not-send="true" href="mailto:raulbe@gmail.com">raulbe@gmail.com</a>>
wrote:<br>
> On the discovery, so it can be taken for granted that
without the<br>
> 'ConnectTo' new Tinc instances on either side in this
context will<br>
> autodiscover each other on the same host? Are they
any additional settings<br>
> like 'localdiscovery' to be enabled?<br>
<br>
</span>Depends on how you setup the actual tinc graph
topology. There are<br>
situations (depending on how physical IP addresses look like
from each<br>
node's perspective) in which LocalDiscovery might be
required for<br>
nodes to directly talk to each other without having to use
more<br>
central nodes as relays.<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tinc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a>
<a class="moz-txt-link-freetext" href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a>
</pre>
</blockquote>
<br>
</body>
</html>