Multi tenancy setup by Tinc?

[Bright Zhao]

Hi, Guus

Yes, I follow your reply below and draw a diagram to see other workaround for the below first diagram(shared gateway model):

Red ones: the () means the inner encapsulation, and you can see packet goes that way to the far right, and when packet returned back from 8.8.8.8 to a.a.a.a, if a.a.a.a is overlap with b.b.b.b, the far end node wouldn’t be able to know where to forward, which is exactly same you mentioned below. But if different tenant’s a.a.a.a never overlap with b.b.b.b or c.c.c.c, this is actually possible.

Blue ones: But if we do a NAT on the left side tinc nodes, and translate the source LAN address to the tun0’s address, and also we make sure the tun0 ip address is well planned through the tinc domain(no conflict, no overlap), then when the far end return the packet, it will head for the node’s tun0’s address, then it should be able to work.

Any drawbacks?



> On 4 May 2017, at 12:43 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 
> On Wed, May 03, 2017 at 02:35:08PM +0800, Bright Zhao wrote:
> 
>> The use case the shared default gateway for multi-tenant, if that the case the node who own the default gateway will have problem to route with different tenant who has overlapped address scope? Is it true when no any other tools like the namespaces?
>> 
>> (tenant1)\
>> (tenant2)——common node—— shared gw node—— Internet
>> (tenant3)/
> 
> Imagine both tenant1 and tenant2 use IP address 1.2.3.4, and both try to
> connect to 8.8.8.8. Then return packets from 8.8.8.8 have destination
> address 1.2.3.4. This is not enough information for the common node to
> determine which tennant to forward the return packets to.
> 
> Even if the traffic from the tennants goes through a NAT before going to
> the Internet, you have the same problem. Linux for example does not
> remember which interface a packet came from, it only knows the original
> address/port combinations. So it still doesn't know which tun interface
> to use for return packets.
> 
>> But if the each tenant have it’s dedicate default gateway, but the path from the tenant node to the default gateway node will be shared by some common tinc node, then the netname of tinc can handle this, right? I think the common tinc node is not handle physical to vpn, it’s only vpn relay.
>> 
>> (tenant1)\                                    /gw for tenant1——Internet
>> (tenant2)——common node—— gw for tenant2—— Internet
>> (tenant3)/                                    \gw for tenant3—— Internet
> 
> Yes, here it would work, assuming you have three tinc daemons running on
> the common node with netnames tenant1, 2 and 3, because then the layout
> is logically more like:
> 
> (tenant1)--(common node netname tennant1) \            / gw for tennant1 -- Internet
> (tenant2)--(common node netname tennant2) -- Internet -- gw for tennant2 -- Internet
> (tenant3)--(common node netname tennant3) /            \ gw for tennant3 -- Internet
> 
> Because you have three separate VPNs in effect, traffic between the
> common node and the gateways is completely separated.
> 
> -- 
> 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/20170504/7c25f8e0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 132506 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170504/7c25f8e0/attachment-0001.png>