From mboxrd@z Thu Jan 1 00:00:00 1970 From: Han Changzhe Date: Fri, 27 Feb 2015 05:58:12 +0000 Subject: Re: A smart router for more than one default routes Message-Id: <54F00774.3010303@nebulat.com> List-Id: References: <54EEBF87.50109@nebulat.com> In-Reply-To: <54EEBF87.50109@nebulat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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 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 > >