VPN Single Daemon For LAN/WAN

[md at rpzdesign.com]

Gus:

I guess my primary point of confusion is that the non-vpn LAN ip
addresses are duplicated in each cluster.  So within a cluster, the LAN
addresses are unique.

But when you look at 2 clusters, 2 different servers share the
10.99.0.11 address.

So that is why I created a VPN for inside the cluster on the LAN
interfaces using the private 10.0.1.xx range.  THen, I created a
separate VPN on the WAN interfaces using publicly visible IP Addresses.
 This VPN solely exists to process cross cluster traffic.

So at the end of the day, every server has a Real IP on eth0, a Private
IP on eth1, and then a TINC VPN LAN IP on 10.0.1.x and a TINC VPN WAN on
10.1.x.x.

I would love to understand how to make the next jump and get a single
TINCD to keep all of this working.

I think the key is the ifconfig and ip commands issued in tinc-up that
allow for another tunx interface to be created and given a WAN VPN ip
address

The TINC VPN LAN address was assigned in tinc-up: ifconfig $INTERFACE
10.0.1.11 netmask 255.255.255.0

md





On 12/15/2014 5:12 PM, md at rpzdesign.com wrote:
> Guus:
> 
> Ok, I accept your challenge.
> 
> But I am clueless in terms of getting the routing table correct.
> 
> So each server has a dual identity, both a LAN private identity with a
> PRIVATE IP address and a WAN public identify with a PUBLIC ip address.
> 
> And how to have 2 different tun devices show up in the ifconfig -a so
> that LAN IP address can be assigned to the tun0 and a WAN IP address can
> be assigned to the tun1
> 
> When I run 2 tincd daemons, I keep both "networks" separate.
> 
> You expert judgement needed here to realize your statement about only
> needing a single tincd daemon.
> 
> 
> md
> 
> On 12/14/2014 7:14 AM, Guus Sliepen wrote:
>> On Fri, Dec 12, 2014 at 02:21:08AM -0500, md at rpzdesign.com wrote:
>>
>>> Oops, I got it to work only after putting the WAN on port 656 so it
>>> did not interfere with port 655 for the LAN.
>>
>> You should not need to have two tinc daemons just because you have a WAN
>> and a LAN interface. By default (ie, if you don't specify BindToAddress
>> and/or BindToInterface), tinc listens on all interfaces, and the
>> kernel should normally take care of selecting which outgoing interface
>> to use for tinc's packets.
>>
>>
>>
>> _______________________________________________
>> tinc-devel mailing list
>> tinc-devel at tinc-vpn.org
>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel
>>
>