Re: A smart router for more than one default routes

[Han Changzhe <hcz@nebulat.com>]

Thanks Dave! Please see below.

Changzhe

On 2015-02-26 15:30, Dave Taht wrote:
> This is not really the best place for a routing question. If you raise
> your question on the quagga list, you might be better off.
>

I couldn't find a better place for the question and thought guys in LARTC
should be professional enough to help. And thanks for your suggestion on
the quagga list! I'll try it.

>
> On Wed, Feb 25, 2015 at 10:39 PM, Han Changzhe <hcz@nebulat.com> wrote:
>> Hello experts,
>>
>> I'm setting up a routing server on Linux with following links
>>
>> 1. An Ethernet link (eth0) to the 1st internet link (fast, but can't
>>     access some sites);
>> 2. A VPN link (tun0) to provide services to local users;
>> 3. A VPN link (tun1) to a proxy server as the 2nd internet link (slow,
>>     free).
>>
>> My target is:
>>    * for common internet access, routing the packets through eth0;
>>    * for the sites can't be accessed through eth0, routing them through tun1.
> Well, one of the things we have been working on in the homenet working group is
> source specific routing, which could possibly help here, but it is
> non-deterministic.

As for the project you mentioned, are there any public materials for me 
to follow up?


>> By now, I set the routing table manually for serveral sites and it works
>> fine. Because there are thousands of them and the sites change with time, so
>> I want a better solution.
>>
>> My idea is like this: setting up more than one default routes for internet
>> access, then dynamically change the route table (or route table cache) with
>> some software according to the internet access results.
>>
>> For example, if we get a timeout from https://www.google.com through eth0,
>> the software should try it through tun1 link and, when succeed, adding the
>> later route to current route table.
> Well you are conflating several layers of the protocol here.
>
> It is hard to recognise a timeout, for example, without sniffing for
> syns/syn_acks
> on the gateway. That sniffer could simultaneously try a syn out one of
> the vpn interfaces and if a syn/ack is not received from the main
> interface, and one IS received from the vpn, insert a route for it.
Yes, a sniffer like that should work. Is it possible to allow the kernel
to raise an exception when TCP connection time-out happens so users can
handle the exception with the hock to try the vpn interface and manipulate
the route table?

> You would still need to clean out that table periodically.
Yes. With the old Linux routing cache, it might be easier. Then we only
add routes to the cache.

> Then you would to insert and delete rules for each ip (or more likely
> network) you wish to reroute
> based on your measurements of what is working or not, and to otherwise
> fall back to the default ethernet route.
>
> Say for example you could not get dns from 8.8.8.8 locally.
>
> ip route add 8.8.8.8 dev tun0
>
> This doesnt help you on any protocols except tcp. udp apps are
> different. so is quic, etc.
>
> a bulk method would be to go through the alexa top 1 million to see
> what you could and could not access, and set up routes for each (but
> this does not handle your desire for 2 tunnels)
Actually I prepared a routing list of around 3K items which should
work by now. It's just not beautiful.


>> I don't know if any routing software on Linux work as I expected. I tried
>> quagga with zebra + ospf but not successful.
> ospf? oy, no....
>
>> FYI, it's not a common case for link based fail-over/load balance.
>>
>>
>> Please give me suggestions!
> Well, my way would probably involve a squid or polipo web proxy to
> make the failover case easier. A lot of users would not dig that...
It should work for web accessing. But we still need to support ports
for email/ftp and other applications.

>> Thanks in advance,
>>
>> Changzhe
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe lartc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>