[squid-dev] What should we do about these *wrong* wiki articles?

Eliezer Croitoru eliezer at ngtech.co.il
Sun Jul 23 07:58:13 UTC 2017


Well, I need to re-read these pages...

And I do understand when there are times it's needed and the examples are giving good reasons to why and when to use.

After I will re-read these wiki sections I will try to think about it again and reply.
Then if we will think that it's needed to write a wiki page or to rewrite the wiki page order or structure I will try to offer a better version.

Thanks,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il



-----Original Message-----
From: Amos Jeffries [mailto:squid3 at treenet.co.nz] 
Sent: Sunday, July 23, 2017 02:21
To: Eliezer Croitoru <eliezer at ngtech.co.il>; squid-dev at lists.squid-cache.org
Subject: Re: [squid-dev] What should we do about these *wrong* wiki articles?

On 23/07/17 09:22, Eliezer Croitoru wrote:
> As I understood the article the DNAT is from another box ie "the router" to the squid box.
> If I understood it wrong and didn't read properly I will re-read them and see in what I am wrong.

see the Details section notes.


You are right about the cross-machine DNAT use-case no longer existing. 
We keep them both in the wiki because they still meet other use-cases:


* REDIRECT copes best for machines and black-box situations where one 
never knows in advance what network it will be plugged into. Such as 
products that will be sold as plug-and-play proxy caches, or to minimize 
config delays on VM images that get run up by the dozen and 
automatically assigned IPs.

However it always NAT's the dst-IP to the machines primary-IP. So is 
limited to the ~64K receiving socket numbers that IP can privide. It 
also spends some CPU cycles looking that IP up on each new TCP connection.


* DNAT copes best for high performance and security installations where 
explicit speed or control of the packets outweighs the amount of effort 
needed to configure it properly.

It is not doing any primary-IP stuff so is slightly faster than 
REDIRECT, and multiple DNAT rules can be added for each IP the machine 
has - avoiding the ~64K limit. BUT requires the admin to know in advance 
exactly what the IPs of the proxy will be. And the IP assignment, 
iptables rules and squid.conf settings are locked together - if any 
change they all need to. Lots of work to reconfigure any of it, even if 
automated. But, also lots of certainty about what the packets are doing 
for the security paranoid.


Those properties are generic, not just in relation to Squid.

Amos



More information about the squid-dev mailing list