[squid-users] Making destination IP available in ICAP REQMOD request

[NgTech LTD]

Hey Moti,

It is a good assumption that the same caching dns server (not 8.8.8.8 or
1.1.1.1) that the client use will return the relevant destination ip for
the domain.
Its possible to do such a query in the icap service with low timeout(2-3)
seconds.
can this be good enough for your use case?

Eliezer

On Mon, Jan 18, 2021, 00:28 Moti Berger <moberger at metanetworks.com> wrote:

> Hi
>
> My goal is to obtain the destination IP when sending an HTTP request for
> my ICAP server so it would be able to decide the kind of adaptation
> required based on it.
>
> Looking at squid (5.0.4) code I discovered the following:
>
> It seems that "everything" starts at ClientRequestContext.
> I've noticed that noteAdaptationAclCheckDone calls startAdaptation which
> calls more methods, eventually getting
> to Adaptation::Icap::ModXact::makeRequestHeaders where it iterates over
> headers defined by the adaptation_meta configurations in squid.conf.
> For each, it calls the 'match' method where it tries to format (and
> assemble) it. There it seems that the value is taken from an AccessLogEntry:
>
>>    case LFT_SERVER_IP_ADDRESS:
>>             if (al->hier.tcpServer)
>>                 out = al->hier.tcpServer->remote.toStr(tmp, sizeof(tmp));
>>             break;
>>
>
> So the AccessLogEntry object seems to be the key.
> At REQMOD time, I don't get the value of the destination IP.
> Looking further I found that the DNS resolving happens when it's decided
> that the request should be forwarded to the destination server.
>
> So I tracked the flow and it seems to start from FwdState::Start method
> which gets an AccessLogEntryPointer.
> Then it calls methods that eventually do the DNS resolving
> (Dns::nbgethostbyname) and ending in (FwdState::connectStart) which have
> the IP to connect to.
> So it seems that this flow will populate the AccessLogEntry.
> This seems right since during RESPMOD, the same code above
> (in Adaptation::Icap::ModXact::makeRequestHeaders) is running and this time
> the `match` method eventually gets the destination IP.
> I added logs that prints the AccessLogEntryPointer and in the FwdState.cc
> the log says address 0x5592ab521e30*12 and in the Notes.cc the log says
> address 0x5592ab521e30*25.
>
> Two things that I haven't found yet:
> 1. The place where the AccessLogEntry is populated
> 2. Where after the adaptation, the forwarding to the destination server
> occured (assuming it should be forwarded)
>
> I couldn't figure out a way to start the DNS resolving just before
> the startAdaptation starts as it requires all sorts of objects that seem to
> be unavailable there.
> I wonder if you can help me to find a way to do it.
>
> Thanks,
> Moti
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20210118/30fa32c7/attachment-0001.htm>