<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:arial,sans-serif;font-size:12.8px">Re: Squid Transparent/intercept Issues</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 8:05 AM,  <span dir="ltr"><<a href="mailto:squid-users-request@lists.squid-cache.org" target="_blank">squid-users-request@lists.squid-cache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send squid-users mailing list submissions to<br>
        <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:squid-users-request@lists.squid-cache.org">squid-users-request@lists.<wbr>squid-cache.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:squid-users-owner@lists.squid-cache.org">squid-users-owner@lists.squid-<wbr>cache.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of squid-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Squid Transparent/intercept Issues (Antony Stone)<br>
   2. Re: SMP and AUFS (Matus UHLAR - fantomas)<br>
   3. Re: SMP and AUFS (Alex Rousskov)<br>
   4. Re: squid workers question (Alex Rousskov)<br>
   5. Re: squid workers question (Matus UHLAR - fantomas)<br>
   6. Re: SSL Bump issues (Alex Rousskov)<br>
   7. blocking or allowing specific youtube videos (Sohan Wijetunga)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Mon, 20 Mar 2017 16:56:17 +0100<br>
From: Antony Stone <<a href="mailto:Antony.Stone@squid.open.source.it">Antony.Stone@squid.open.<wbr>source.it</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] Squid Transparent/intercept Issues<br>
Message-ID: <<a href="mailto:201703201656.18291.Antony.Stone@squid.open.source.it">201703201656.18291.Antony.<wbr>Stone@squid.open.source.it</a>><br>
Content-Type: Text/Plain;  charset="iso-8859-15"<br>
<br>
On Monday 20 March 2017 at 16:26:40, christian brendan wrote:<br>
<br>
> Hello Everyone,<br>
><br>
> Squid Cache: Version 3.5.20<br>
> OS: CentOS 7<br>
><br>
> I have used squid for quite some times non transparently and it works,<br>
> problem kicks in when: http_port 3128 transparent is enabled.<br>
> Access denied error page shows up when transparent is enabled<br>
> ERRORThe requested URL could not be retrieved<br>
<br>
How are you getting the packets to the Squid server for interception?<br>
<br>
Is the Squid server in the default route between your clients and the<br>
Internet, or are you redirecting the packets to the Squid server somehow?<br>
<br>
Please give *details* of how you are intercepting and sending the packets to<br>
Squid (eg: iptables rules, and which machine/s the rules are running on).<br>
<br>
<br>
Antony.<br>
<br>
--<br>
Anything that improbable is effectively impossible.<br>
<br>
 - Murray Gell-Mann, Nobel Prizewinner in Physics<br>
<br>
                                                   Please reply to the list;<br>
                                                         please *don't* CC me.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 20 Mar 2017 17:15:16 +0100<br>
From: Matus UHLAR - fantomas <<a href="mailto:uhlar@fantomas.sk">uhlar@fantomas.sk</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] SMP and AUFS<br>
Message-ID: <<a href="mailto:20170320161516.GB26154@fantomas.sk">20170320161516.GB26154@<wbr>fantomas.sk</a>><br>
Content-Type: text/plain; charset=us-ascii; format=flowed<br>
<br>
On 19.03.17 11:08, Alex Rousskov wrote:<br>
>On 03/18/2017 11:11 PM, senor wrote:<br>
><br>
>> There are many references in the squid wiki, FAQ and Knowlegebase about<br>
>> SMP but I don't see any of them reflecting the concerns you have brought<br>
>> up.<br>
><br>
>There is a paragraph about these problems at [1] (search for "ufs") but<br>
>I agree that better documentation, including wiki and<br>
>squid.conf.documented changes/additions would be nice.<br>
><br>
>  [1] <a href="http://wiki.squid-cache.org/Features/SmpScale" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/<wbr>Features/SmpScale</a><br>
><br>
><br>
>> My point in mentioning that there are a lot of installations using<br>
>> SMP and AUFS is that something widely used but buggy tends to be brought<br>
>> up on this email list and I haven't seen it.<br>
><br>
>IIRC, it has been brought up several times on the mailing lists and in<br>
>Bugzilla. Once you dedicate each ufs-based store to each individual<br>
>worker, most of the problems become subtle, often "invisible" to an<br>
>admin because they "break" transactions, not Squid, especially if you do<br>
>not use a mixture of ufs-based and rock stores. Using mailing list as an<br>
>indicator that as subtle problem does _not_ exist is a risky strategy IMO.<br>
<br>
Well, I personally will still be curious how much does SMP affect the case of<br>
one worker and one or more diskers...<br>
<br>
do diskers only provide I/O to the requestor?<br>
<br>
--<br>
Matus UHLAR - fantomas, <a href="mailto:uhlar@fantomas.sk">uhlar@fantomas.sk</a> ; <a href="http://www.fantomas.sk/" rel="noreferrer" target="_blank">http://www.fantomas.sk/</a><br>
Warning: I wish NOT to receive e-mail advertising to this address.<br>
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br>
Depression is merely anger without enthusiasm.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 20 Mar 2017 12:19:58 -0600<br>
From: Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.<wbr>com</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] SMP and AUFS<br>
Message-ID:<br>
        <<a href="mailto:cd47a96b-357d-8cfd-41e4-d4d376da10c1@measurement-factory.com">cd47a96b-357d-8cfd-41e4-<wbr>d4d376da10c1@measurement-<wbr>factory.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 03/20/2017 10:15 AM, Matus UHLAR - fantomas wrote:<br>
<br>
> Well, I personally will still be curious how much does SMP affect the<br>
> case of one worker and one or more diskers...<br>
<br>
I do not understand why you are asking this question in AUFS context.<br>
AUFS does not use diskers! Today, only Rock store uses diskers (in SMP<br>
mode). Some other [ufs-based] cache stores use various helper threads<br>
and processes for I/O as well, but those helper processes are not<br>
diskers or even kids in SMP terminology.<br>
<br>
<br>
> do diskers only provide I/O to the requestor?<br>
<br>
Diskers primary function is low-level disk cache I/O. Like all kids,<br>
diskers respond to cache manager requests and Squid management events<br>
(e.g. shutdown and reconfiguration). IIRC, diskers also build in-RAM<br>
cache_dir index.<br>
<br>
    <a href="http://wiki.squid-cache.org/Features/SmpScale#Terminology" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/<wbr>Features/SmpScale#Terminology</a><br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 20 Mar 2017 12:32:44 -0600<br>
From: Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.<wbr>com</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] squid workers question<br>
Message-ID:<br>
        <<a href="mailto:5c14decf-fd76-b6cb-a497-85b4e226b34c@measurement-factory.com">5c14decf-fd76-b6cb-a497-<wbr>85b4e226b34c@measurement-<wbr>factory.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 03/20/2017 09:20 AM, Matus UHLAR - fantomas wrote:<br>
> On 10.03.17 08:52, Alex Rousskov wrote:<br>
>> Sorry, but that 2010 documentation is outdated. It was written before<br>
>> Rock store, a 2011 feature that changed what "SMP mode" means. This is<br>
>> my fault. Here is a replacement draft that I was working on until wiki<br>
>> went down:<br>
>><br>
>>> NAME: workers<br>
>>> DEFAULT: 1<br>
>>>     Number of main Squid processes or "workers" to fork and maintain.<br>
>>><br>
>>>     In a typical setup, each worker listens on all http_port(s) and<br>
>>>     proxies requests without talking to other workers. Depending on<br>
>>>     configuration, other Squid processes (e.g., rock store "diskers")<br>
>>>     may also participate in request processing. All such Squid processes<br>
>>>     are collectively called "kids".<br>
>>><br>
>>>     Setting workers to 0 disables kids creation and is similar to<br>
>>>     running "squid -N ...". A positive value starts that many workers.<br>
<br>
> The default of 1 (only) creates kids for each rock store configured.<br>
<br>
What makes you think that? I believe "workers 1" in the presence of rock<br>
cache_dirs should create one kid to handle HTTP transaction _plus_ one<br>
kid for each rock cache_dir.<br>
<br>
<br>
>>>     When multiple concurrent kids are in use, Squid is said to work in<br>
>>>     "SMP mode". Some Squid features (e.g., ufs-based cache_dirs) are not<br>
>>>     SMP-aware and should not or cannot be used in SMP mode.<br>
>>><br>
>>>     See <a href="http://wiki.squid-cache.org/Features/SmpScale" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/<wbr>Features/SmpScale</a> for details.<br>
<br>
> very nice, thanks. However this is not meant for the wiki, but for:<br>
> <a href="http://www.squid-cache.org/Doc/config/workers/" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Doc/config/workers/</a><br>
<br>
To be more precise, the text is meant for src/cf.data.pre, from which<br>
squid.conf.documented (and Doc/Config pages) are generated from. Not<br>
sure why you say "However" though.<br>
<br>
<br>
> maybe that pages could be updated (all but 3.2 versions are the same).<br>
<br>
Once the above worker documentation changes are polished and committed<br>
to the Squid repository, the affected generated pages/files will be<br>
updated automatically.<br>
<br>
The documentation for earlier versions may never be updated though -- it<br>
depends on whether the changes are going to be ported and committed to<br>
the code branches corresponding to those earlier versions.<br>
<br>
<br>
>> The final version will probably move and extend the terminology-related<br>
>> text to the SMP section preamble -- it is kind of wrong to talk about<br>
>> diskers when documenting workers. Improvements and constructive<br>
>> suggestions welcomed!<br>
><br>
> compared to current version I'd change it to:<br>
><br>
>     1: start one main Squid process daemon (default)<br>
>            "no SMP" when rock store is not used<br>
>            "SMP" when rock store in use<br>
<br>
I agree that we should add something like this as a common-case example<br>
of general rules. Thank you.<br>
<br>
Alex.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 20 Mar 2017 20:49:06 +0100<br>
From: Matus UHLAR - fantomas <<a href="mailto:uhlar@fantomas.sk">uhlar@fantomas.sk</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] squid workers question<br>
Message-ID: <<a href="mailto:20170320194906.GA30456@fantomas.sk">20170320194906.GA30456@<wbr>fantomas.sk</a>><br>
Content-Type: text/plain; charset=us-ascii; format=flowed<br>
<br>
>> On 10.03.17 08:52, Alex Rousskov wrote:<br>
>>> Sorry, but that 2010 documentation is outdated. It was written before<br>
>>> Rock store, a 2011 feature that changed what "SMP mode" means. This is<br>
>>> my fault. Here is a replacement draft that I was working on until wiki<br>
>>> went down:<br>
>>><br>
>>>> NAME: workers<br>
>>>> DEFAULT: 1<br>
>>>>     Number of main Squid processes or "workers" to fork and maintain.<br>
>>>><br>
>>>>     In a typical setup, each worker listens on all http_port(s) and<br>
>>>>     proxies requests without talking to other workers. Depending on<br>
>>>>     configuration, other Squid processes (e.g., rock store "diskers")<br>
>>>>     may also participate in request processing. All such Squid processes<br>
>>>>     are collectively called "kids".<br>
>>>><br>
>>>>     Setting workers to 0 disables kids creation and is similar to<br>
>>>>     running "squid -N ...". A positive value starts that many workers.<br>
<br>
>On 03/20/2017 09:20 AM, Matus UHLAR - fantomas wrote:<br>
>> The default of 1 (only) creates kids for each rock store configured.<br>
<br>
On 20.03.17 12:32, Alex Rousskov wrote:<br>
>What makes you think that? I believe "workers 1" in the presence of rock<br>
>cache_dirs should create one kid to handle HTTP transaction _plus_ one<br>
>kid for each rock cache_dir.<br>
<br>
That's exactly what I meant, for inclusion to your paragraph.<br>
Should I replace "kids" with "one extra kid"?<br>
and should I replace (only) by "however"?<br>
<br>
>>>>     When multiple concurrent kids are in use, Squid is said to work in<br>
>>>>     "SMP mode". Some Squid features (e.g., ufs-based cache_dirs) are not<br>
>>>>     SMP-aware and should not or cannot be used in SMP mode.<br>
>>>><br>
>>>>     See <a href="http://wiki.squid-cache.org/Features/SmpScale" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/<wbr>Features/SmpScale</a> for details.<br>
><br>
>> very nice, thanks. However this is not meant for the wiki, but for:<br>
>> <a href="http://www.squid-cache.org/Doc/config/workers/" rel="noreferrer" target="_blank">http://www.squid-cache.org/<wbr>Doc/config/workers/</a><br>
><br>
>To be more precise, the text is meant for src/cf.data.pre, from which<br>
>squid.conf.documented (and Doc/Config pages) are generated from. Not<br>
>sure why you say "However" though.<br>
<br>
You mentioned you were working on the draft until wiki went down.<br>
I understood the paragraph as replacement for "workers" documentation, not<br>
as something to be written to wiki...<br>
<br>
>> maybe that pages could be updated (all but 3.2 versions are the same).<br>
><br>
>Once the above worker documentation changes are polished and committed<br>
>to the Squid repository, the affected generated pages/files will be<br>
>updated automatically.<br>
><br>
>The documentation for earlier versions may never be updated though -- it<br>
>depends on whether the changes are going to be ported and committed to<br>
>the code branches corresponding to those earlier versions.<br>
<br>
it's up to the release team.<br>
I would recommend update the docs on the web to avoid issues for people<br>
using older squid versions, e.g. in enterprise environment<br>
<br>
>>> The final version will probably move and extend the terminology-related<br>
>>> text to the SMP section preamble -- it is kind of wrong to talk about<br>
>>> diskers when documenting workers. Improvements and constructive<br>
>>> suggestions welcomed!<br>
>><br>
>> compared to current version I'd change it to:<br>
>><br>
>>     1: start one main Squid process daemon (default)<br>
>>            "no SMP" when rock store is not used<br>
>>            "SMP" when rock store in use<br>
><br>
>I agree that we should add something like this as a common-case example<br>
>of general rules. Thank you.<br>
<br>
if we replace the current paragraph with your proposed one, I have proposed<br>
change at the top<br>
<br>
--<br>
Matus UHLAR - fantomas, <a href="mailto:uhlar@fantomas.sk">uhlar@fantomas.sk</a> ; <a href="http://www.fantomas.sk/" rel="noreferrer" target="_blank">http://www.fantomas.sk/</a><br>
Warning: I wish NOT to receive e-mail advertising to this address.<br>
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br>
Eagles may soar, but weasels don't get sucked into jet engines.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 20 Mar 2017 14:08:48 -0600<br>
From: Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.<wbr>com</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: Re: [squid-users] SSL Bump issues<br>
Message-ID:<br>
        <<a href="mailto:d729abc8-9a3a-25e0-9185-d1cdbd2d91cc@measurement-factory.com">d729abc8-9a3a-25e0-9185-<wbr>d1cdbd2d91cc@measurement-<wbr>factory.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 03/19/2017 07:58 PM, mr_jrt wrote:<br>
<br>
> ...but the only way I've got any successful SSL proxying is with:<br>
><br>
><br>
> ...but as expected, that's clearly not doing any bumping from the logs:<br>
><br>
><br>
><br>
> When I put anything more in, i.e.<br>
><br>
><br>
> Then it turns on the mode:<br>
><br>
><br>
> ...but then I just get errors about no ciphers:<br>
><br>
<br>
Please note that your configuration and other details in the post did<br>
not get through to the mailing list (probably due to some fancy quoting<br>
provided by Nabble that does not get through to the actual squid-users<br>
mailing list).<br>
<br>
Alex.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 21 Mar 2017 12:35:25 +0530<br>
From: Sohan Wijetunga <<a href="mailto:sohanwijetunga@gmail.com">sohanwijetunga@gmail.com</a>><br>
To: <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
Subject: [squid-users] blocking or allowing specific youtube videos<br>
Message-ID:<br>
        <<a href="mailto:CAOUuUH671PqQQF4sd9ykGarqFiVOp_TZ8HMs6GfEBh3QTVjkwA@mail.gmail.com">CAOUuUH671PqQQF4sd9ykGarqFiVO<wbr>p_TZ8HMs6GfEBh3QTVjkwA@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Project subject is blocking or allowing specific youtube videos. For that<br>
research I hope to add more features but currently I’m stuck to take full<br>
urls from clients. According to my project, environment should be client<br>
server environment. All the client’s youtube traffic should be manage<br>
through the gateway. I currently following squid helper programs it seems<br>
to be fulfil my requirement but those examples are not enough for testing.<br>
Using of squid helper program is to do some development in my research<br>
future. I really need to do that project using squid.<br>
<br>
<br>
<br>
 I look forward to hearing from you soon.<br>
<br>
Thank you.<br>
<br>
Best Regards,<br>
<br>
Sohan.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.squid-cache.org/pipermail/squid-users/attachments/20170321/435d3a19/attachment.html" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>pipermail/squid-users/<wbr>attachments/20170321/435d3a19/<wbr>attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of squid-users Digest, Vol 31, Issue 59<br>
******************************<wbr>*************<br></blockquote><div><br></div><div><br></div><div><br></div><div class="gmail_default" style="font-family:georgia,serif">​@Antony.Stone</div><div class="gmail_default" style="font-family:georgia,serif">1. ​I am using mikrotik routerboard to redirect traffic, with this rule:</div><div class="gmail_default" style="font-family:georgia,serif"><div class="gmail_default">dd action=dst-nat chain=dstnat comment="Redirect port 80 to SquidProxy" dst-port=80 protocol=tcp \ src-address=10.24.7.100 to-addresses=10.24.7.101 to-ports=3128</div></div></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:georgia,serif">3.​ It is not in default route, packets is been redirected.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">​4. There is no iptable rules, firewall is disabled for this test.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Regards</div><br></div></div>