Chris Nighswonger wrote:
> Hi all,
> We run a webradio which is broadcast via an external streaming
> service (A). In an effort to keep the Internet pipe from becoming
> conjested with audio streaming traffic from on-campus users listening
> to the stream, we setup an internal streamer (B) for use on campus. Of
> course you have those who are not paying attention to the notice to
> use the inside streamer rather than the outside. Since I run dg/squid,
> I am configuring squid to redirect traffic requests headed for A to B.
> There are two ways of accessing the stream. One is via a playlist
> file. (i.e. http://streamserver.com/list.asx) The other is directly.
> (i.e. http://streamserver.com:1234/) I have setup the following to
> handle the playlist url's:
>
> acl streamlink url_regex -i ^http://streamserver.com/list.
> http_access deny streamlink
> deny_info http://192.168.0.x:8000/list.m3u streamlink
>
> This part works great! (Thanks Henrik. :)
>
> The following is my setup to handle the direct connections:
>
> acl streamserver dstdomain .streamserver.com
> acl streamport 1234
Assuming this is not a typo, you forgot an important feature. The ACL type.
acl streamport port 1234
> http_access deny streamserver streamport
> deny_info http://192.168.0.x:8000/mountpt streamserver streamport
>
> This one does not work at all. Watching the access.log, squid
> authenticates the request and then proceeds to pass the traffic to the
> external streaming server (A). Looking into the packets with wireshark
> shows that they are indeed headed for streamserver.com:1234....
>
> Two questions:
>
> 1. Am I using the correct acl types to match
> http://streamserver.com:1234/ (dstdomain + port)?
> 2. Am I doing this entire redirect the hard way? I would think that
> squid would be the logical place to take care of this. Or is it
> iptables?
>
> Thanks,
> Chris
>
>
>
>
Chris
Received on Thu Feb 01 2007 - 14:42:17 MST
This archive was generated by hypermail pre-2.1.9 : Thu Mar 01 2007 - 12:00:01 MST