kyler-keyword-tinc.0fe9e4 at lairds.com
2015-Apr-11 13:16 UTC
workaround to use tinc as default gateway
I have been delighted by tinc. Building a mesh like I need would have been horrible in OpenVPN. tinc makes it easy. I decided to share a workaround for a problem that's been vexing me. Either I'm being dumb (and can do this better with a hint) or this is something others might need. I've been moving a bunch of services from our university to Amazon (EC2). To do this, I bring up a VPN, start an OpenVZ server, then start virtual environments (VEs) within that. The VEs have addresses from our campus network. Some now also have Amazon (EIP) addresses so that we can reach them without traversing the VPN. Originally I used OpenVPN and configured the VPN interface (tap0) with DHCP. tinc does not appear to have a clean way of running commands after an interface is active and I don't really need a valid address for the VPN interface anyway, so I decided to just use a non-routable address. This is also cleaner because I don't have to delete the interface's route from the main routing table. I'm using source routing tables to ensure that traffic from my campus addresses routes through the VPN and other traffic routes through the Amazon interface. Also, each VE gets an entry in the main routing table so I set the priority of the rule for that to be lower so that my rules are evaluated later. The problem I encountered was that although I could establish routing to my VPN's gateway, I could not use the gateway as a default route. I struggled with this for quite awhile before realizing that it works if I put the gateway route in the main table, then set the default route in my VPN table, then remove the route from the main table. It's clumsy, but it works. Here's a brief demo, using 76.54.32.1 as the VPN's gateway which I'm trying to use in the VPN table, 201. # sh -x /tmp/route.sh + ifconfig tap0 192.168.1.100 netmask 255.255.255.0 up + ip route add 76.54.32.1 dev tap0 table 201 + ip route add default via 76.54.32.1 table 201 RTNETLINK answers: No such process + ip route add 76.54.32.1 dev tap0 table main + ip route add default via 76.54.32.1 table 201 + ip route show table 201 76.54.32.1 dev tap0 scope link default via 76.54.32.1 dev tap0 + ip route del 76.54.32.1 dev tap0 table main + ip route show table 201 76.54.32.1 dev tap0 scope link default via 76.54.32.1 dev tap0 I welcome suggestions for making this cleaner. Thanks for tinc! --kyler
Am 11.04.2015 um 15:16 schrieb kyler-keyword-tinc.0fe9e4 at lairds.com:> I have been delighted by tinc. Building a mesh like I need would have been horrible in OpenVPN. tinc makes it easy.You can add the following to tinc-up: ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` for VPN_GATEWAY in 1.2.3.4 ; do ip route add $VPN_GATEWAY $ORIGINAL_GATEWAY done ip route add 0.0.0.0/1 dev $INTERFACE ip route add 128.0.0.0/1 dev $INTERFACE 1.2.3.4 is the external ip of your tinc endpoint, may be more ips if needed. ALBI...
On 2015-04-11 21:16, kyler-keyword-tinc.0fe9e4 at lairds.com wrote:> Here's a brief demo, using 76.54.32.1 as the VPN's gateway which I'm trying > to use in the VPN table, 201. > > # sh -x /tmp/route.sh > + ifconfig tap0 192.168.1.100 netmask 255.255.255.0 up > + ip route add 76.54.32.1 dev tap0 table 201 > + ip route add default via 76.54.32.1 table 201 > RTNETLINK answers: No such process > + ip route add 76.54.32.1 dev tap0 table main > + ip route add default via 76.54.32.1 table 201 > + ip route show table 201 > 76.54.32.1 dev tap0 scope link > default via 76.54.32.1 dev tap0 > + ip route del 76.54.32.1 dev tap0 table main > + ip route show table 201 > 76.54.32.1 dev tap0 scope link > default via 76.54.32.1 dev tap0 > > I welcome suggestions for making this cleaner.Multiple tables are definitely the right way to do this if you have the option! Your example is a little unclear - I'm not sure if you are running these commands on the 'gateway' machine or on 'client' machines. The simplest choice I find is to do this in two places. One in the subnet script for your gateway, and one in the general host script. I've called your gateway machine 'gateway' here. Likewise, GATEWAY_VPN_ADDRESS is not a variable, but needs to be replaced with your gateway's internal address on the VPN (not the outward facing interface). These examples are, of course, simplified and you should do some modifications to suit, especially if I've misunderstood your example :) host-up: #!/bin/sh ip route add throw ${REMOTEADDRESS}/32 table 201 host-down: #!/bin/sh ip route del throw ${REMOTEADDRESS}/32 table 201 gateway-up: #!/bin/sh ip route add 0.0.0.0/0 via GATEWAY_VPN_ADDRESS table 201 gateway-down: #!/bin/sh ip route del 0.0.0.0/0 via GATEWAY_VPN_ADDRESS table 201 -- -shikkc