Dear All,
I am still unable to setup ACLS correctly...! Anyway Now I have decided to setup Delay Pools for Fixed-Bandwidth (No Time Restriction) for youtube/videos/streaming etc.
Please share your experience. Here's details:
1. No Bandwidth Restriction on "OpenIPs" for example
acl OpenIPs src "/etc/squid3/AlwaysOpenIPs.txt"
2. 5 Mbps Bandwidth Restriction on "FixBandwidthIPs" i.e
acl FixBandwidthIPs src "/etc/squid3/FixBandwidthIPs.txt"
3. Deny All other to access youtube/videos/streaming i.e
http_reply_access deny deny_rep_mime_flashvideo
Thank you very much for your time and kind help.
--- On Thu, 6/21/12, Anonymous <eletters_mail@xxxxxxxxx> wrote:
> From: Anonymous <eletters_mail@xxxxxxxxx>
> Subject: Re: Time based Video Streaming Access
> To: "Amos Jeffries" <squid3@xxxxxxxxxxxxx>, "Odhiambo Washington" <odhiambo@xxxxxxxxx>
> Cc: squid-users@xxxxxxxxxxxxxxx
> Date: Thursday, June 21, 2012, 10:43 AM
> Thank you very much for detailed
> information with examples.
>
> I have setup ACL as given below:
>
> # ---------Start Here ------------------------
> acl OpenIPs src "/etc/squid3/AlwaysOpenIPs.txt"
> acl TimedTubed src "/etc/squid3/TimeBasedIPs.txt"
> acl NoTubeTime time SMTWHFA 09:00-14:59
> acl deny_rep_mime_flashvideo rep_mime_type video/x-flv
> http_reply_access allow OpenIPs
> http_reply_access allow TimedTubed NoTubeTime
> http_reply_access deny deny_rep_mime_flashvideo
> http_reply_access allow all
> # ---------End Here ------------------------
>
> Now "TimedTubed" (Time based youtube/video streaming access)
> can access all other web sites BUT after the restricted time
> (09:00-14:59) @ 15:00, they can not access the you tube
> website.
> I want to allow the "TimedTubed" IPs to access you tube only
> from 15:00 till 08:59.
>
> Thank you very much for your time and kind help.
>
> Regards.
> -------------------------------------------------------------
> --- On Thu, 6/21/12, Amos Jeffries <squid3@xxxxxxxxxxxxx>
> wrote:
>
> > From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
> > Subject: Re: Time based Video Streaming
> Access
> > To: "Anonymous" <eletters_mail@xxxxxxxxx>
> > Cc: squid-users@xxxxxxxxxxxxxxx
> > Date: Thursday, June 21, 2012, 4:27 AM
> > On 20.06.2012 20:31, Anonymous
> > wrote:
> > > Dear Amos Jeffries and All,
> > >
> > > Thank you very much for great help. I am trying
> to
> > understand the
> > > actual working of "http_reply_access [allow|deny]"
> and
> > "http_access
> > > [allow|deny]". Can you please tell me the format,
> > especailly the
> > > "ORDER" of ACL Statements, as "http_reply_access
> > [allow|deny]" and
> > > "http_access [allow|deny]" are bit tricky and I
> am
> > confused howto set
> > > the order of acl statements.
> >
> >
> > http_access lines are tested as soon as the HTTP
> request is
> > received. Using only the TCP connection and HTTP
> request
> > details (no HTTP reply details). To decide whether
> Squid is
> > going to reject the request or try to handle it.
> >
> > http_reply_access is tested as soon the HTTP reply is
> > received. Using TCP connection details, HTTP request
> and
> > reply details. To decide whether Squid is going to
> deliver
> > the response or send an error instead.
> >
> >
> > There is no configuration relevant in ordering of
> between
> > http_access and http_reply_access lines. Each one will
> be
> > separated in to a sequence of its own type of line.
> > eg
> > http_access allow A
> > http_reply_access deny B
> > http_access allow C
> >
> > is the same as:
> >
> > http_access allow A
> > http_access allow C
> >
> > http_reply_access deny B
> >
> >
> >
> > "acl" directive lines are just definitions of how to
> run a
> > particular test. The only ordering they have is to be
> listed
> > in the config before they are used on any other
> directive
> > lines.
> >
> >
> > Lines for each access directive type (eg, http_access)
> are
> > processed top-to-bottom first matching whole line does
> its
> > action. Individual ACL on each line are tested
> left-to-right
> > with first mis-matching ACL stopping that lines test.
> >
> > For example:
> > http_access allow A B C
> > http_access deny D E
> >
> > means:
> > if A *and* B *and* C tests all match, ALLOW the
> > request
> > OR,
> > if D *and* E tests all match, DENY the request
> > OR
> > do the opposite of DENY
> >
> >
> > With some logic performance tricks like:
> > If B does not match the whole first line will not
> > match so C will not be tested. (one less test ==
> faster
> > handling time).
> >
> >
> > More details can be found at http://wiki.squid-cache.org/SquidFaq/SquidAcl
> >
> >
> > HTH
> > Amos
> >
> >
> > >
> > > Thank you very much for your time and help.
> > >
> > >
> > > --- On Wed, 6/20/12, Amos Jeffries <squid3@xxxxxxxxxxxxx>
> > wrote:
> > >
> > >> From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
> > >> Subject: Re: Time based Video
> > Streaming Access
> > >> To: squid-users@xxxxxxxxxxxxxxx
> > >> Date: Wednesday, June 20, 2012, 7:23 AM
> > >> On 19.06.2012 23:57, Anonymous
> > >> wrote:
> > >> > Hello Respected All,
> > >> >
> > >> > I want to setup Time based Video
> Streaming
> > Access for
> > >> different IPs
> > >> > (same subnet), few IPs are allowed every
> time
> > video/you
> > >> tube streaming
> > >> > access, while other IPs (IPs list in file
> as
> > SRC) are
> > >> only allowed in
> > >> > set time duration any other IPs are not
> > allowed to
> > >> access Video/You
> > >> > tube access. Here's setup:
> > >> > -------------------
> > >> > Ubuntu 12.04
> > >> > Squid 3.1.x
> > >> > Two Groups of IPs
> > >> > G-1 = Allowd Everytime
> > >> > G-2 = Time Restriction (09:00-14:59)
> > >> > G-3 = Everybody, Deny Access to
> Video/You
> > tube
> > >> streaming every time.
> > >> > ------------------------------
> > >> > acl OpenIPs src
> "/etc/squid3/AlwaysOpenIPs.
> > txt" # G-1=
> > >> List of IPs
> > >> > allowed for Video Streaming Everytime.
> > >> > acl TimedTubed src
> > "/etc/squid3/TimeBasedIPs.txt" # G-2
> > >> = List of IPs
> > >> > allowed for set time duration.
> > >> > acl NoTubeTime time SMTWHFA 08:30-14:59 #
> Time
> > duration
> > >> when you
> > >> > access to Time based IPs.
> > >> > acl deny_rep_mime_flashvideo
> rep_mime_type
> > video/x-flv
> > >> # ACL to Deny
> > >> > Video Straming for everyone else.
> > >> > http_reply_access allow OpenIPs
> TimedTubed
> > NoTubeTime
> > >>
> > >> This above line can only allow the IPs which
> are
> > listed in
> > >> *both* OpenIPs and TimedTubed.
> > >> It will allow them only during NoTubeTime.
> > >>
> > >>
> > >> If I'm reading your policy description above
> > correctly you
> > >> actually want:
> > >>
> > >> # G-1 policy = Allowed Everytime
> > >> http_reply_access allow OpenIPs
> > >>
> > >> # G-2 policy = Time Restriction
> (09:00-14:59)
> > >> http_reply_access allow TimedTubed
> NoTubeTime
> > >>
> > >>
> > >> > http_reply_access deny TimedTubed
> > >>
> > >> That above line seems wrong according to your
> > stated
> > >> policies. It will block TimedTubed IPs from
> going
> > to
> > >> non-YouTube content.
> > >>
> > >>
> > >> # G-3 policy = Deny Access to Video/You
> tube
> > >> streaming every time.
> > >> > http_reply_access deny
> > deny_rep_mime_flashvideo
> > >>
> > >> http_reply_access allow all
> > >>
> > >> > ------------------------------
> > -----------------------
> > >> > Above mentioned ACLs are not working
> properly,
> > General
> > >> Internet
> > >> > Access (http_access) is also denied when
> used
> > with
> > >> "http_reply_access
> > >> > deny" I want to only deny video
> streaming/you
> > tube in
> > >> set time
> > >> > duration and allow internet access.
> > >> >
> > >> > Thank you in advance.
> > >>
> > >>
> > >> One thing to note here. Blocking in
> > http_reply_access means
> > >> the video is already arriving when you decide
> not
> > to deliver
> > >> it. squid id forced to do one of two things:
> > >>
> > >> a) close the server connection and wait out
> > the TCP reset
> > >> timouts (15 minutes) before re-using the
> socket.
> > Not a major
> > >> issue on networks with low web traffic, but
> can be
> > a major
> > >> problem if you are needing to use those
> sockets
> > again fast.
> > >>
> > >> b) read in the entire video from the server
> > and discard it
> > >> before re-using the socket. Avoids TCP
> timeouts,
> > but
> > >> provides wastes bandwidth and may on some
> videos
> > take longer
> > >> than a 15-min TCP reset would have.
> > >>
> > >>
> > >> NOTE: You also need to consider an http_access
> or
> > >> miss_access ACL block to prevent people not
> allowed
> > to view
> > >> videos from even making a request to the video
> site
> > in the
> > >> first place. This front-line block is where
> the
> > bandwidth
> > >> and speed savings will come from. The
> > http_reply_access can
> > >> be used as an inefficient but more accurate
> block
> > only for
> > >> those requests which get past your front-line
> > blocking.
> > >>
> > >>
> > >> Amos
> > >>
> >
> >
>
