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 -- 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
