also sprach dman <[EMAIL PROTECTED]> [2002.01.06.2028 +0100]: > | i'll assume your LAN to be 192.168.1.0/24, and i assume A to be at > | 192.168.1.1. furthermore, should A be accessible from the outside? if > | yes, then you have a problem if you have a dynamic IP. > > Yes I do want you to be able to get to my webserver. I supposedly > have a dynamic IP (I get it via dhcp) but it hasn't changed ever > (yet). I understand why that might be a problem, but it may be > workaroundable using devices or names.
actually, my previous solution only proxied for machines within 192.168.1.0/24 and only if the request is not to the webserver/gateway itself. so it should work no matter what. you should make sure to have rp_filter enabled! > | you can't easily proxy the requests from A. first of all, they are > | already at A, so essentially you can't pass them through squid. it's > | surely possible (with IP aliases for instance), but it's not really > | necessary... > > Since they're already at A they need to be grabbed at a different > point in the chain. I'm not sure which point would be correct though. > Perhaps if the request comes from 127.0.0.1 it can be proxied? (I > hope that's where the request goes through :-)) you will *not* be able to make use of a transparent proxy from the machine running the proxy. think about it. however, noone will keep you from having this one machine use the proxy explicitly. > | A shouldn't be used for anything anyway... > > It's my desktop machine. I don't want to buy another ISA NIC for the > 486 clunker I have, so my desktop must serve the masquerading. yeah well. no comment from the security side ;) > | if you want apache at A to be proxied, you simply request the page from > | one of the other IPs of A. > > I'd have to, right? If all requests coming from the LAN are > redirected to squid, the only way they can get to apache is through > squid. i should correct myself again. let's think. you request http://192.168.1.1 from the LAN. let's ignore the -d 192.168.1.1/32 filter that RETURNs. then this request gets redirected to squid like any other in PREROUTING. squid will see the request and make it for you, but it'll go through loopback this time. so you can effectively just make the line iptables -t nat -A PREROUTING -p tcp --dport 80 -s 192.168.1.0/24 \ -j transproxy be iptables -t nat -A PREROUTING -p tcp --dport 80 -s 192.168.1.0/24 \ -i ! lo -j transproxy now squid can talk to the webserver without having to worry about iptables. a request from the outside won't get redirected (since it's not from 192.168.1.0/24 *and* you configured rp_filter), so there's no trouble. by the way, if you are interested, i solved this problem for me by simply not making apache locally listen to port 80. i *don't* provide HTTP, the only way to access my home server is through HTTPS, and that solved the problem since i am *not* proxying HTTPS (why would i, even though squid "can"???). -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] friends help you move. real friends help you move bodies.
pgp4N1hzaR1tE.pgp
Description: PGP signature
