|
Hi,
I see that the configured acl is not called for all requests.
I do see that the ecap is called, it sets the option X-PMeta-Splice via visitEachOption correctly, but the classifyRequest note acl is not evaluated, and the request is not spliced.
However, I do see that this acl is evaluated for some other requests, but only when the X-PMeta-Bypass is set to: 'no'.
This config worked as expected when using an external acl type for the same request, but i also saw the same issue when using note when i tried to use it to classify the external acl.
Is there perhaps a bug/misconfiguration with the note acl?
The current config is:
acl classifyRequest note -m X-PMeta-Bypass yes
acl step1 at_step SslBump1
acl step2 at_step SslBump2
ssl_bump peek step1
ssl_bump splice step2 classifyRequest
ssl_bump stare all
ssl_bump bump all
adaptation_meta X-PMeta-Bypass "%adapt::<last_h{X-PMeta-Splice}"
Thanks,
Frida
From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, June 15, 2021 21:35 To: Frida Safran <fsafran@xxxxxxxxxxxxxx>; squid-users@xxxxxxxxxxxxxxxxxxxxx <squid-users@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: Passing Proxy Protocol Headers to external ACL On 6/15/21 4:18 AM, Frida Safran wrote:
> In addition to using an external acl to annotate connections and decide > whether splice/bump, I would like to try using an ecap service to > achieve this. > I would like to create an acl using info from the ecap service, and > bump/splice using the following configuration: > > acl classifyRequest note splice yes > > acl step1 at_step SslBump1 > acl step2 at_step SslBump2 > > ssl_bump peek step1 > ssl_bump splice step2 classifyRequest > ssl_bump stare all > ssl_bump bump all > > > If I set a custom option from within the ecap service, can i use that > via the above note acl? I believe that should work in principle, provided the eCAP service is consulted before Squid starts evaluating "ssl_bump splice step2 classifyRequest". If you do not restrict what requests your eCAP REQMOD service gets, then it should be consulted during step1 (at least). The logic is the same for eCAP and ICAP here -- Squid "primary" code does not know the difference between those two adaptation interfaces. > Can i set a custom option without setting it in > 'adaptation_masterx_shared_names' Yes, you should be able to. The adaptation_masterx_shared_names directive is unrelated to setting transaction annotations IIRC. It is about sharing metadata across adaptation services. > Or, should I instead use: > > acl classifyRequest note %adapt::<last_h{splice} yes This option cannot work AFAICT because the "note" ACL requires a constant (i.e. known at configuration time) annotation name. Squid will not substitute %adapt::<last_h{splice} with anything in this context. HTH, Alex. > ------------------------------------------------------------------------ > *From:* Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> > *Sent:* Monday, June 14, 2021 16:24 > *To:* squid-users@xxxxxxxxxxxxxxxxxxxxx <squid-users@xxxxxxxxxxxxxxxxxxxxx> > *Cc:* Frida Safran <fsafran@xxxxxxxxxxxxxx> > *Subject:* Re: Passing Proxy Protocol Headers to external ACL > > On 6/14/21 2:29 AM, Frida Safran wrote: > >> Regarding proxy_protocol - is there a known patch for v4 I could use by >> any chance? > > I am not aware of any such patches. The changes were significant, fixing > many PROXY protocol handling bugs. Virtually anything can be backported, > but it would be a large effort with noticeable stability risks and > long-term maintenance overheads. Preparing for a v5 upgrade may be a > better strategy in this particular case. > > >> Regarding icap, I suppose the acl is getting evaluated before the icap >> and that is why they aren't available: > >> acl classifyRequest external TransactionClassificator >> ssl_bump peek step1 >> ssl_bump splice step2 classifyRequest >> ssl_bump stare all >> ssl_bump bump all > > According to [1], the above configuration should result in two ICAP > REQMOD requests (if configured) before classifyRequest is consulted > during step2. I am aware of SslBump bugs in that area, but I would > expect at least one ICAP REQMOD request anyway. The requests > existence/timing should be easy to confirm using cache.log with > debug_options set to at least "ALL,3 82,9 93,9" and/or a logging or > pausing external ACL script in combination with an icap_log (to compare > logged timestamps). > > [1] > https://urldefense.com/v3/__https://wiki.squid-cache.org/Features/SslPeekAndSplice__;!!ORgEfCBsr282Fw!6SDlCpq2n2kV1WuiNQ7focWt2YMDj-Xs9aEp29dC32pwZUHSLIkrD7dnojPghFBhQQ$ > <https://urldefense.com/v3/__https://wiki.squid-cache.org/Features/SslPeekAndSplice__;!!ORgEfCBsr282Fw!6SDlCpq2n2kV1WuiNQ7focWt2YMDj-Xs9aEp29dC32pwZUHSLIkrD7dnojPghFBhQQ$> > > > > HTH, > > Alex. > > >> ------------------------------------------------------------------------ >> *From:* Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >> *Sent:* Sunday, June 13, 2021 17:46 >> *To:* squid-users@xxxxxxxxxxxxxxxxxxxxx <squid-users@xxxxxxxxxxxxxxxxxxxxx> >> *Cc:* Frida Safran <fsafran@xxxxxxxxxxxxxx> >> *Subject:* Re: Passing Proxy Protocol Headers to external ACL >> >> On 6/13/21 7:31 AM, Frida Safran wrote: >> >>> 1. Is it possible to pass proxy protocol headers to an external acl as >>> part of the format? >> >> It should be possible. Use %proxy_protocol::>h logformat %code in your >> external_acl_type FORMAT configuration. We added that support to Squid >> v5. Not available in the official v4. >> >> >>> 2. Is it possible to pass all/specific icap headers to an external acl? >>> I have been trying to use %icap::>h to pass all the icap headers to >>> an external acl, but it resolves to "-" >> >> It should be possible if your external ACL is evaluated _after_ the >> corresponding ICAP headers are received, but I would not be surprised if >> there are bugs in this area -- the ICAP headers may be available but not >> provided to the ACL evaluation code. Which squid.conf directive is >> triggering your external ACL evaluation in this use case? >> >> >> HTH, >> >> Alex. > |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
