Академический Документы
Профессиональный Документы
Культура Документы
Problem Description
Policy tracing is use when debugging access to web sites. When something is allowed and it
should be denied, or vice-versa, using the policy trace feature is the best way to diagnose that
type of issue. In this article, we will go over enabling the trace and examining the debug file that
was generated by it.
Resolution
Enabling policy trace
Note: Although IS possible to recreate the rule via CPL and add it to the local policy file via
command line, it will not be possible to view the output of the debug file.
Policy trace can be enabled globally or by setting up a specific rule. Enabling the global option is
quick and easy but it can generate a lot of data very quickly so it's not the recommended way of
taking a policy trace but it can be an valid option on a proxy that doesn't have too much traffic.
Go to Configuration / Policy / Policy Options. Set the option to "Trace all policy execution"
Click 'Apply'
Reproduce the issue as quickly as possible
Disable policy tracing
Click 'Apply'
Move ahead in this article to the section "Analyzing the policy trace"
To open the debug file generated by the policy trace, go to https://<proxy ip>:8082/policy
You should see policy trace filenames in there. If you enabled the global policy trace option,
the file will be called "default_trace.html". If you used a rule, the file name will depend on the
object you created. Click on the file to display it. The default extension is html but the content of
the file is plain text. Let's look at what a typical policy trace looks like. The numbers in red were
added for this article. They are explained in more details further down.
Those markers show the top and bottom of every transaction. A transaction is a web
transaction. A 'Get' request for example. Accessing one web site will generate many transactions
since every object (html code, java, images, banners, everything has it's own transaction).
In the above example, this rule doesn't have a source condition, has 3 categories set as
destination and 'Deny' configured as the action. The policy debug shows "miss" for this rule
which means that this transaction did not match the condition. In this case here, google.com did
not match the BCWF categories "Alcohol", "Auctions" or "Gambling"
This rule was a match so an action was taken by the proxy. In this example, there are no
conditions, it's simply a rule with an "Allow" action so everything would match that rule. Not
that this is the last rule evaluated so that means the proxy reached the end of the active policy.
This line shows connection details specific to that transaction. We know that the service was
HTTP, that the source IP was 10.1.1.10 and that the port used to connect to the proxy was 8080
For our example above, we can see that it was a "get" request made to www.google.com. Most
common types of requests are "get", when the browser fetches an object, and "post", when
information is sent from the browser back to the server (form information and file uploads for
example).
This line is important when debugging a problem with a web site. We can see that it was
Firefox 3.0.11 that made this request, which means it's the browser itself. Some user-agents out
there will make a request directly. Winamp, Microsoft Outlook and iTunes are examples of user-
agents that go directly to the internet. Those user-agent don't support everything that a browser
does so they sometimes cause problems, especially with authentication. Usually, the result of that
is the user getting prompted to enter credentials. We have seen occurrences of iTunes going into
a loop of authentication when the proxy was setup in a transparent way and authentication was
configured to use cookie surrogates. The iTunes user-agent would not save the cookie and make
the request over and over again, and the proxy would.
(9) Category
url.category shows he matching category (or categories) bound to the URL accessed. If you see
"unlicensed/unavailable", it means that the license for the content filtering database has expired.
Additional information
For some connections, instead of seeing "match" or "miss", the proxy will report "n/a" which
means the rule did not apply to that connection. In most cases, it is because the rule is specific to
a protocol and the connection was not using that protocol. Another typical scenario would be
user or group specific rule when a connection went by unauthenticated.
Remember to turn off policy tracing after debugging is complete. Policy tracing (specially
enabling tracing for all policy evaluation) will generate lots of logs so it should be turned off
when not in use.