This is a discussion on Can't figure out how to make convoluted route... within the Linux Networking forums, part of the Linux Forums category; I'm at a site that has a dedicated line to a remote LAN for a sister office. We would ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
I'm at a site that has a dedicated line to a remote LAN for a sister office.
We would like to test access to some local resources to make sure that office can see it, and we'd like to automate it. Ideally, I would like to pass all packets from MYHOST destined for TESTIP through REMOTEGW. My first instinct was to simply add a route like: route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW .... but you can't do that because $REMOTEGW is about 4 hops away. So, I though that I could use iptables to do it: iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW .... but that didn't work either. For good measure, I made sure to add the forwarding rule: iptables -A FORWARD -d $TESTIP -j ACCEPT .... but I still can't run a traceroute and see packets going via $REMOTEGW to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is feasible (after all, there are several switches between $MYHOST and $REMOTEGW). Any ideas? |
|
|||
|
On Fri, 20 Oct 2006 15:15:10 -0400, James McIninch wrote:
> I'm at a site that has a dedicated line to a remote LAN for a sister office. > We would like to test access to some local resources to make sure that > office can see it, and we'd like to automate it. Ideally, I would like to > pass all packets from MYHOST destined for TESTIP through REMOTEGW. > > My first instinct was to simply add a route like: > > route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW > > ... but you can't do that because $REMOTEGW is about 4 hops away. > > So, I though that I could use iptables to do it: > > iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW > > ... but that didn't work either. For good measure, I made sure to add the > forwarding rule: > > iptables -A FORWARD -d $TESTIP -j ACCEPT > > ... but I still can't run a traceroute and see packets going via $REMOTEGW > to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is > feasible (after all, there are several switches between $MYHOST and > $REMOTEGW). > > Any ideas? you say 'dedicated line' but then say '4 hops'... not very direct.... Just a shot in the dark, but you probably want to set up a VPN type tunnel between the local office and the remote office. That way, they would each have a virtual ethernet port that was directly connected to the 'other site'. jack -- D.A.M. - Mothers Against Dyslexia see http://www.jacksnodgrass.com for my contact info. jack - Grapevine/Richardson |
|
|||
|
James McIninch wrote:
> I'm at a site that has a dedicated line to a remote LAN for a sister office. > We would like to test access to some local resources to make sure that > office can see it, and we'd like to automate it. Ideally, I would like to > pass all packets from MYHOST destined for TESTIP through REMOTEGW. > > My first instinct was to simply add a route like: > > route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW > > ... but you can't do that because $REMOTEGW is about 4 hops away. It would really help if you could provide IP Addresses. Just using variables forces us to assume too much. Your origination device must have a route that points to the next-hop router, not one 4 hops away. Each router along the way must know the nest hop router to both ends. > > So, I though that I could use iptables to do it: > > iptables -t mangle -A PREROUTING -d $TESTIP -j ROUTE --gw $REMOTEGW > > ... but that didn't work either. For good measure, I made sure to add the > forwarding rule: > > iptables -A FORWARD -d $TESTIP -j ACCEPT > > ... but I still can't run a traceroute and see packets going via $REMOTEGW > to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is > feasible (after all, there are several switches between $MYHOST and > $REMOTEGW). The number of switches makes no difference. The link between switches is not a "hop", if that's what you were referring to earlier in your post. Going back to what you said about your link being direct between locations, you just need a setup like this. 192.168.0.2 "Remote Device" | | 192.168.0.1 Remote Router WAN \ / \ WAN Local Router 192.168.1.1 | | 192.168.1.2 "Local Device" Local Device IP settings: IP Address 192.168.1.2 Mask 255.255.255.0 Gateway 192.168.1.1 or static route to 192.168.0.0/24 via 192.168.1.1 Remote Device IP settings: IP Address 192.168.0.2 Mask 255.255.255.0 Gateway 192.168.0.1 or static route to 192.168.1.0/24 via 192.168.0.1 from either end, ping the near router, far router, far device. .....kurt > > Any ideas? |
|
|||
|
On Fri, 20 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <FvKdncUCM6-cvaTYnZ2dnUVZ_oednZ2d@comcast.com>, James McIninch wrote: [Just an FYI - while Comcast/giganews does carry 'comp.os.linux.questions' that group is only found on servers that claim to carry more newsgroups than anyone else - it was never a real group. That's why it's averaging less than one article a day.] >I'm at a site that has a dedicated line to a remote LAN for a sister office. >We would like to test access to some local resources to make sure that >office can see it, and we'd like to automate it. Ideally, I would like to >pass all packets from MYHOST destined for TESTIP through REMOTEGW. To get to REMOTEGW, it has to go through LOCALGW - and that's all the kernel cares about. >My first instinct was to simply add a route like: > > route add -net $TESTIP netmask 255.255.255.255 gw $REMOTEGW Syntax error - a '-net' doesn't use a 255.255.255.255 mask. That's a host route, and doesn't want that keyword. Secondly >... but you can't do that because $REMOTEGW is about 4 hops away. Amazing! Don't you think it would be more useful to hand the packets to the local end of the link - and let _that_ system worry about how stuff gets to the next hop on the way to the remote site? >So, I though that I could use iptables to do it: Nope - it's a routing problem >... but that didn't work either. For good measure, I made sure to add the >forwarding rule: Same thing >... but I still can't run a traceroute and see packets going via $REMOTEGW >to $TESTIP. Now that I am thinking of it, I'm not 100% certain this is >feasible (after all, there are several switches between $MYHOST and >$REMOTEGW). and it's their job to route packets "onward" through hosts that they are _DIRECTLY_ connected to. >Any ideas? http://tldp.org/guides.html * The Linux Network Administrator's Guide, Second Edition version: 1.1 authors: Olaf Kirch and Terry Dawson last update: March 2000 ISBN: 1-56592-400-2 available formats: 1. HTML (read online) 2. HTML (tarred and gzipped package, 690k) 3. PDF (1.5MB) Brief concept: Your kernel routes packets to hosts that are DIRECTLY attached to the LAN. The "router" or modem or what-ever hands the packet to something that is directly connected to it, and that system forwards the packet to something else - eventually it gets to the destination, but you don't CARE about the intermediate steps. That's why internetworking classes always talk about the Internet being "a cloud" where you stick the packet _in_ here, and it comes _out_ there. What happens in between is not relevant. All the kernel needs to know is the final destination, and the address of the box ON THIS LOCAL NETWORK that will do the forwarding. Old guy |