Henrik,
First off thanks for the great work you've done on squid! :-)
On Sat, 28 Apr 2001 22:28:09 +0200, you wrote:
>masquerade is just one form of NAT (many to one NAT).
>
>The masquerade router may well run any services it likes. Therestricton
>is that machines behind the masquerade router cannor run services
>intended to be contacted by machines on the other (public) site.
>
>NAT comes in many forms. Static 1-1 NAT is only one.
>
I'm not familiar with Linux "Masquerade" but with "IP Filter/IP NAT"
on OpenBSD you can run services behind the NATing router box on
machines with private IP addresses. The limitation you need to address
is just what listening port you want to use.
Dual Homed
|-------NAT ROUTER---------|
(public) (private)
111.111.0.1 192.168.0.254
Create mapping such as:
(NAT Router Public) (Private IP Proxies)
111.111.0.1:8080 -------> 192.168.0.1:8080
111.111.0.1:8081 -------> 192.168.0.2:8080
111.111.0.1:8082 -------> 192.168.0.3:8080
111.111.0.1:8083 -------> 192.168.0.4:8080
If you clients from (non-Lab) public IP's to the router on the correct
ports, you can reach the services running on the machines behind the
router on private IPs. As far as the clients are concerned, they are
just talking to your router box and don't know about the private
machines behind it.
>Transparent proxying of SSL in Squid does not make sense as there are
>other much better mechanisms doing essentially the same functionality on
>all platforms supporting transparent proxying. Also, SSL proxying has
>very little in common with HTTP proxying due to the encryption of all
>data.
I agree with you on this one. I'm not sure why someone would want
squid to handle transparent SSL connections when NAT already does it
for you and the results of SSL connections can't be cached anyhow
since the contents are encrypted.
In my very limited understanding of SSL, it's basically an HTTP
session tunneled/encrypted over an SSL connection. When a browser is
configured to use a proxy for SSL connections, it tunnels the SSL
connection over HTTP using the CONNECT method, so the result is HTTP
tunneled over SSL which is then tunneled over HTTP through a proxy.
For squid to _transparently_ proxy SSL, it would have to capture the
SSL connection and then tunnel it over HTTP using the CONNECT method
on behalf of the (uninformed) client and then somehow manage untunnel
the HTTP CONNECT results returned from the server and pass them back
to the client without anything having a security problem. It seems
possible but kind of messy and for the most part unnecessary.
Do I have the right idea here or am I misinformed?
Best Regards,
J.C. Roberts
Received on Sun Apr 29 2001 - 01:49:13 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:59:39 MST