Re: A smart router for more than one default routes

[Han Changzhe <hcz@nebulat.com>]

On 2015-02-28 20:53, Dennis Jacobfeuerborn wrote:
> On 27.02.2015 06:58, Han Changzhe wrote:
>> 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 could potentially use the -E option of the conntrack-tools to listen
> to these kinds of events:
> http://conntrack-tools.netfilter.org/conntrack.html
>
> Regards,
>    Dennis
>
Thanks Dennis! It seems a good tool. I'll try it!

Regards,

Changzhe