Greg Cox wrote:
The typical way to handle this problem is at the name space level.
Not the original poster, but...
Actually, the original poster eventually clarified his problem as:
umm... i think you got me a little lost :p
my server is at 192.168.123.456
my surfing computer is at 192.168.123.457
the router forwards to port 80 like it should.
when my dad (out in az) connects, 71.71.789.456 he doesnt have a problem in
the world
when i connect to my server71.71.789.456, i get like 6 min load times on a
300k image.
when i connect to my server internally, 192.168.123.456, i get instant
loading of the same pictures, or different ones that have not been cashed.
If he were using a split DNS setup or views, inside his local network he
would resolve the correct internal IP address for the name of his
server, and wouldn't be passing traffic through the router. This would
effectively solve his problem.
One reason I don't like handling this via DNS is that I don't have a
static IP, and I like living with one dyndns name on the outside
interface. And I don't get to manage views with them. And to me it's
kinda cool to have one name that always works, whether I'm home or away.
Using an external name service provider like dyndns actually makes this
*easier* than the way I'd prefer to do it, which is to host my own
authoritative DNS. Let's say your domain is called, oh, I don't know...
"example.dyndns.org". You setup an internal name server at
192.168.1.42, and make it authoritative for the domain
example.dyndns.org, including an A record for that very domain, which
points to the IP of the appropriate server. You also configure it with
"forwarder" entries to your local ISP's DNS server (or what ever your
clients used to use before this change). Then update your client's DNS
server entries to point to the local DNS server, and voila, you're
done. :) Resolution from the outside world will naturally recurse up
to dyndns's actual entry, and they'll get your external IP. Internal
resolvers will hit your local DNS server, and when asking for
example.dyndns.org, the server returns it's local authoritative answer.
When asking for other records in the dyndns.org domain name, the local
server isn't authoritative, so it forwards those requests along to
dyndns.org, and they resolve naturally.
that this is dramatically easier to do on an honest-to-god router.
I think it's not the Linux tools, so much as the network layout. It
becomes easier when you segment up the network to where you use the
gateway box like a router. Most of the problems I'm hearing are from
trying to do this magic routing all on one internal network, which is
going to kill you ded.
Yes, as the rest of your post pointed out, it's entirely possible to go
through and solve this problem with multiple networks for the servers vs
the clients. I briefly thought about suggesting a solution along these
lines, but redesigning the network isn't really solving the
interestingly complex problem at hand. Having said that, this complex
problem is definitely something that the iptables / iproute2 tools
should be able to do. They're capable of rewriting the source, and the
destination, and building tables to map them back on the reverse
paths... it's just that some of the trade-offs made in the interest of
avoiding loops, overly complex rules, etc make this unfortunately not
possible with the existing tools, as far as I can see. So I stand by my
original assertion that it's a short-coming in the tools, that they
can't handle this particular solution gracefully.
Aaron S. Joyner
My setup: cablemodem to liveCD linux router. Router with 4 internal VLAN
interfaces (DMZ, wired desktop network, WPA2 trusted wireless, WEP
untrusted wireless (for the NintendoDS)) to VLAN-aware switch, with a
bastion server on the DMZ VLAN.
Currently I have a rule on the router:
-A PREROUTING ! -i vlan2 -p tcp -m tcp --dport 22 -j DNAT --to
192.168.2.20
Now, actually, that rule stinks since it means I can't ssh out from my
lappy to the world, but, I never do that from not-the-DMZ anyway, so,
it's
kinda ok. I should really do something like (untested!):
-A PREROUTING ! -i vlan2 -m addrtype --dst-type LOCAL -p tcp -m tcp
--dport 22 -j DNAT --to 192.168.2.20
But the cdrouter I'm using, its iptables version is too old to use
addrtype
and I'm too lazy to roll my own CD.
VLAN'ing your home is probably more than most people want to monkey
with, but it's pretty cool once it's all set. The Dell 27(08|16|24)
PowerConnects are cheap gigabits and don't do badly for a core switch
for home/SOHO. Interface is terrible, but, you probably won't touch it
often.
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
