On 25/01/2015 11:43 p.m., Marcus Kool wrote: > > > On 01/24/2015 11:24 PM, Amos Jeffries wrote: >> On 25/01/2015 9:39 a.m., Marcus Kool wrote: >>> >>> >>> On 01/24/2015 10:15 AM, Amos Jeffries wrote: >>>> On 22/01/2015 10:11 a.m., Marcus Kool wrote: >>>>> I am using Squid 3.4.9 and have an issue with tcp_outgoing_address. >>>>> >>>>> The Squid server is connceted to the internet with multiple NICs and >>>>> uses >>>>> tcp_outgoing_address a.public.IP.address >>>>> >>>>> and also want to use an ICAP server on the same host using >>>>> >>>>> icap_service reqmod_urlfilterdb reqmod_precache >>>>> icap://a.local.ip.address:1344/reqmod_icapd bypass=off routing=on >>>>> on-overload=wait ipv6=off >>>>> >>>>> It seems that Squid binds the connection to the ICAP server the >>>>> same way >>>>> it binds >>>>> connections to webservers using the rule with tcp_outgoing_address >>>>> and that it not desired nor workable. >>>>> >>>>> I tried >>>>> >>>>> acl myicaphost dst a.local.ip.address >>>>> tcp_outgoing_address a.public.IP.address !myicaphost >>>>> >>>>> but Squid issues the following errors: >>>>> 2015/01/21 21:58:32 kid1| WARNING: myicaphost ACL is used in context >>>>> without an HTTP request. Assuming mismatch. >>>>> 2015/01/21 21:58:32 kid1| commBind: Cannot bind socket FD 10 to >>>>> XX.XX.XX.XX: (99) Cannot assign requested address >>>>> 2015/01/21 21:58:32 kid1| essential ICAP service is down after an >>>>> options fetch failure: icap://XX.XX.XX.XX:1344/reqmod_icapd >>>>> [down,!opt] >>>>> >>>>> So the question is how to send web traffic over a specific NIC and >>>>> traffic to the ICAP server over an other (default?) NIC ? >>>> >>>> >>>> Please try the attached patch against Squid-3.4. It should make your >>>> config work. >>>> >>>> Amos >>> >>> Thank you for the patch. >>> It resolves 1 issue: there is no longer the warning >>> WARNING: myicaphost ACL is used in context without an HTTP request. >>> Assuming mismatch. >>> >>> But the binding to the wrong NIC with the external IP still happens: >>> >>> 2015/01/24 17:19:48.027 kid1| Xaction.cc(133) openConnection: >>> Adaptation::Icap::OptXact opens connection to 10.10.0.6:1344 >>> 2015/01/24 17:19:48.027 kid1| AsyncCall.cc(18) AsyncCall: The AsyncCall >>> Adaptation::Icap::Xaction::noteCommConnected constructed, this=0x1d9d7e0 >>> [call53] >>> 2015/01/24 17:19:48.027 kid1| comm.cc(549) comm_openex: comm_openex: >>> Attempt open socket for: a.public.IP.address >>> 2015/01/24 17:19:48.027 kid1| comm.cc(590) comm_openex: comm_openex: >>> Opened socket local=a.public.IP.address remote=[::] FD 10 flags=1 : >>> family=2, type=1, protocol=6 >>> >>> The firewall and routing was changed to allow traffic from the external >>> IP to >>> the internal IP so for us the urgency of the issue is low, but >>> the binding remains on the external IP despite the ACL saying not to >>> do it. >> >> Aha, conceptual problem. >> >> tcp_outgoing_address does not forbid things. There is no "allow/deny" >> action, just a set-IP action. It either sets the IP or it leaves it >> alone. > > Do you agree that the binding should not take place if a socket > is created with a destination address 'myicaphost' ? The myicaphost is > 10.10.0.6 and the comm debug output above shows that the socket *is* bound. I cant agree because I dont know why it was binding. Squid only uses bind() if there is an explicit outgoing address required to be used. > >> Your rule sets the IP when the dst is non-myicaphost. So what >> tcp_outgoing_address rule or OS level routing rule matches when it *is* >> myicaphost? > > Sorry, I don't know which routing decision is taken. All I know is that > the routing has been changed to make the connection to the ICAP server > work. > > I tried to show with the comm debug output that the connection to the > ICAP server (10.10.0.6) is still bound. I replaced the public IP address > with "a.public.IP.address" (I do not want to show the real IP but > it is definitely a public IP address). That obfuscation is fine, as long as its clear which IP is which. Perhapse a new debug trace after applying the patch will help resolve what the remaining problem is? Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
