2
2
My home server has two interfaces named eth0 and eth1. eth0 is connected directly to an incoming WAN port, so the gateway for eth0 is determined depending on the ISP's DHCP server. eth1 is connected to my router, which is connected to another WAN port.
Below is the output of netstat -rn
(111.111.111.126 is a mock public address):
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 111.111.111.126 0.0.0.0 UG 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
111.111.111.126 0.0.0.0 255.255.255.128 U 0 0 0 eth0
I want to be able to choose an interface for the outgoing connections freely, but don't know how. curl www.google.com --interface eth1
should connect to www.google.com via eth1, it fails in the current configuration. route add default gw 192.168.0.1
fixes that, but then curl www.google.com --interface eth0
breaks.
2You can't normally have two default gateways; you can split network views and do all kinds of crazy stuff, but it's generally a really bad idea. This might sound simple, but normally IP does not keep track of where a packet came from, so sending it back out that direction isn't possible. IP was specifically designed this way to make it link agnostic and resilient. – Chris S – 2012-01-04T14:35:49.767
@ChrisS: If you have two IP addresses, then there is no problem. Anything that talks to eth0's IP must come from eth0, be answered using eth0's IP and through eth0, and the same is true for eth1. That's done easily with policy routing, and the RFC clearly recognize source-based routing. You can't simply dismiss this as 'crazy stuff', especially when compared to things like NAT. – BatchyX – 2012-08-21T07:14:32.147
@BatchyX Um, no. Locally attached routes have a higher priority in routing than unknown networks accessed by default gateways. If you're going to claim "the RFC" supports you, you'd better include the RFC number at a minimum. I do consider split network views to be "crazy stuff". – Chris S – 2012-08-21T12:42:58.433
@ChrisS: I don't see the problem with locally attached routes. If you receive a packet from 192.168.x.y coming from eth0, reverse path filtering will trash them anyway. And a machine from eth0's lan cannot send you a packet to eth1's IP unless you configured it to have routes to you. And for locally generated packets, your properly configured policy routing will only select eth0's gateway for packets coming from eth0's IP or may optionnal reject packets from eth0's IP to eth1's lan. Also i should have said "the RFCs" instead of "the RFC", but see ye old 1812's "Vendor Policy" for starters. – BatchyX – 2012-08-21T18:36:27.770
@BatchyX We're talking about completely different things. – Chris S – 2012-08-21T18:53:49.677