On 13/03/2014 7:09 p.m., PSA4444 wrote: > I'm running squid as a reverse proxy with many web servers behind it, using > host headers to determine which site the user is trying to access. > > One of these web servers runs IIS, with multiple websites on different > ports: 443, 444, 445, etc. > > I would like squid to be able to connect to this server on a different port > based on which address the user tries to access. > > https://help.mydomain.com:443 -> 10.0.1.4:443 > https://app.mydomain.com:443 -> 10.0.1.4:444 >
One the requests are received Squid is perfectly able to route them to different cache_peer. That is done somewhat like you tried already. This configuration depends more on getting the requests at all though. Since HTTPS certificate validation hinges very much on matching the domain certified with the domain fetched when the server cert is delivered to the client before any of the HTTPS requests are sent to tell the server what domain is being fetched. This big problem can be avoided in two ways: 1) using a wildcard certificate for *.mydomain.com that can validate both sub-dmains on your listening https_port. 2) SNI (Server Name Indication) extension feature of SSL/TLS. Where the client tells the server which domain is being accessed so the server can send out a certificate for that domain. Squid does not yet support method #2 IIRC. Any contributions towards that are welcome. > I have tried the following to achieve this: > > cache_peer help.mydomain.com parent 443 0 no-query originserver ssl > sslversion=3 connect-timeout=8 connect-fail-limit=2 > sslflags=DONT_VERIFY_PEER front-end-https=on name=help login=PASSTHRU > > cache_peer app.mydomain.com parent 444 0 no-query originserver ssl > sslversion=3 connect-timeout=8 connect-fail-limit=2 > sslflags=DONT_VERIFY_PEER front-end-https=on name=app login=PASSTHRU > > unfortunately, accessing both these sites connects to the site running on > port 443 on the IIS server :( > > How can I achieve what I'm trying to? > For the cache_peer side you are on the right track but there are a few issues that need to be fixed: 1) use cache_peer_access to determine for each request which peer server it is going to: acl help dstdomain help.mydomain.com cache_peer_access help.mydomain.com allow help cache_peer_access help.mydomain.com deny all ... etc 2) remove sslflags=DONT_VERIFY_PEER. It is okay for initial testing that the SSL/TLS connections will work. But before this goes into production you should setup Squid with the CA appropriate to verify the peers certififcates. Verifying peers prevents hijacking of the HTTPS connections between your proxy and the master servers. 3) you may need the forceddomain= option on app.mydomain.com to deliver the port change. Amos