On Mon, 17 May 2010 08:07:23 -0700 (PDT), Quin Guin <quinguin_at_yahoo.com>
wrote:
> Amos,
>
> Thank you for your reply and see reply below:
>
> Thanks,
>
> Guin
>
NP: your email client needs to be fixed too it seems. It's attributing
your reply to me.
>
> ----- Original Message ----
> From: Amos Jeffries <squid3_at_treenet.co.nz>
> To: squid-users_at_squid-cache.org
> Sent: Sat, May 15, 2010 2:14:14 AM
> Subject: Re: [squid-users] http CONNECT method with fwd proxy to content
> server on same subnet
>
> Quin Guin wrote:
>> Hi,
>>
>> I have a new need for deploying squid in my environment and I have
>> been trying to set it up but it is not working as expected. Please
>> see me requirements below and I have tried this with both 2.7-stable9
>> and 3.1.3 on CentOS4.6 64bit.
>>
>> I have a remote server sending a HTTP CONNECT to my server but my
>> server can't handle an HTTP CONNECT. So I wanted to use squid to
>
> Something is badly broken there. CONNECT is not a generic HTTP request
> method. It is specifically for browser-to-proxy and proxy-to-proxy
> communication.
> You should never receive it at a web server or web app interface.
>
>
> I agree this is not a good design but I didn't have a say in it but I
did
> get stuck with getting it to work. The request are coming from
> browser-to-proxy over 8080 and my idea is to
proxy(squid)-to-proxy(ours)
> that doesn't handle CONNECT method. Yes I know this is far from ideal
but
> I am just trying to have SQUID as a forward proxy receive the request
then
> send it as a regular https request still encrypted with out the CONNECT
> method to our "proxy".
>
>> handle the CONNECT method and then send the https requests to my
>> local server to handle the request. I know that a transparent proxy
>> doesn't know how to handle the SSL requests because is not operating
>
> Yes, nor does it legally handle CONNECT method. Since interception mode
> should only be handling valid web server interface methods.
>
> I agree with that..
>
>> as a normal proxy. So I have been using squid as a fwd proxy but it
>> keeps sending the http CONNECT method to my end server which is
>> causing issues. So I am asking for ideas on what I need to do to look
>> at do this. I have tried various iptables rules and cache_peers but
>> nothing is seeming to work I am using pretty much the default config
>> except for my local network IPs and ACL to allow the traffic.
>>
>> I would appreciate any ideas..
>
> Do you have access or control to configure the remote server properly?
>
> No I do not but I really wish I did..because then I would not be doing
> this.
Okay. Being able to swing RFC 2616 section 9.3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
about in the right direction should be of some assistance with that in the
long term.
>
> What is your current squid.conf configuration for http_port, http_access
> and cache_peer rules?
>
> Here is the config:
>
> acl manager proto cache_object
> acl localhost src 127.0.0.1/32
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl SOL src xxx.xxx.xxx.xxx/24 # novarra
>
>
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localnet
> http_access allow CONNECT SOL
> http_access allow CONNECT localnet
> http_access allow SOL
> http_access deny all
The rules "allow CONNECT SOL" and "allow CONNECT localnet" are duplicates
of "allow localnet" and "allow SOL".
The CONNECT ones can be removed from there again.
> icp_access allow localnet
> icp_access deny all
>
> http_port 8080
> htcp_port 0
> icp_port 0
>
> never_direct allow all
Ah, never_direct seems to be your problem.
What you need is this I think:
never_direct deny SOL
never_direct allow all
> cache_peer 172.18.0.39 parent 8775 0 no-query default
> cache_peer_access 172.18.0.39 allow CONNECT
Um, 172.18.0.39 being a web server? it will need "originserver" option and
drop the CONNECT access permission. You DON'T want the CONNECT to be
relayed on as-is.
Amos
Received on Tue May 18 2010 - 01:28:38 MDT
This archive was generated by hypermail 2.2.0 : Tue May 18 2010 - 12:00:05 MDT