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@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
