On 15.12.2010 11:14, Amos Jeffries wrote:
All the reverse proxy servers will be run by us, so I consider them
trusted. But since Amazon does not provide availability guarantees or
stable IP addresses and load may change, we might have to add or remove
instances on the fly. I'd like to have a system that can handle this in
a robust way (reconfiguring Apache doesn't count as robust, too much
room for errors).
I was thinking, if the rDNS of the dynamic EC proxies are set
correctly to produce something in your company domain. Your
follow_x_forwarded_for ACL tests could use the srcdomain or
srcdom_regex ACL type to authorize trust without knowing the actual IP
assigned.
I thought about something involving reverse DNS entries too, and, rather
surprisingly, it actually seems to be supported by EC2. But I don't
trust such a solution very much, because of all the DNS reconfiguration
and caches involved (need to set up forward entries first, wait until
they have propagated etc.; sounds slow and unreliable).
I'm using the
header_replace X-Forwarded-For
directive. If I understood it correctly, it should clear any existing
X-Forwarded-For headers, and Squid has no reason to add more than one IP
here, so I think it should be fine.
"forwarded_for truncate" replaces the entire header with only the
immediately connected client IP. The docs appear to be wrongly stating
squid uses its own IP, fixing them now.
The IP may still be "unknown", IPv4 or IPv6 clients.
Amos
Ok, I'll use that instead. Unknown or IPv6 shouldn't be a problem, since
my apache mod_rewrite stuff will just use the IP address of the proxy
server in this case, and I can look it all up in the proxy's log files -
I'll have to collect them somewhere anyway.
Thanks for your great help!
David
