Exinda EXNV-10063, Руководство администратора

Страница: 314 / 623

Exinda Network Orchestrator 3 Using | 314
3.5 Configuring for common use cases and scenarios
The following list of topics demonstrate some common ways you can use the features of your Exinda Appliance to
monitor, manage and control network traffic.
3.5.1 Monitoring and controlling traffic in a captive portal system 314
3.5.2 Backhauling Internet traffic 319
3.5.3 Setting and enforcing quotas 321
3.5.4 Creating Applications from DSCP-marked traffic (like Riverbed accelerated traffic) 325
3.5.5 Clustering and high availability 326
3.5.6 Controlling anonymous proxy traffic 333
3.5.1 Monitoring and controlling traffic in a captive portal system
Integrating your Exinda Appliance with a captive portal
The Exinda Appliance can be a part of a captive portal system by using the HTTP Redirect policy to redirect
unauthenticated traffic to the login page of your captive portal system.
When users have authenticated with your captive portal, your portal system sends the login user information and the
group to which you want the user to belong, to the Exinda appliance through the appliance Active Directory API. You
may choose to have a single authenticated user group or you may choose to have several user groups to indicate a level
of service, such as Gold, Silver, and Bronze service levels.
On the Exinda Appliance, you need to create user-group network objects that link with these Active Directory groups,
which then identify the traffic as belonging to authenticated users. In the Optimizer policy tree, you need to create
policies for the authenticated traffic using the user group network objects and you will also need to create a policy to
redirect unauthenticated HTTP traffic to your captive portal, and another policy to block other types of unauthenticated
traffic. You should note that you should ensure that DNS traffic for the unauthenticated users is not blocked.
Since the Exinda Appliance matches traffic to the filters in the policies (and virtual circuits) from the top of the Optimizer
policy tree, you need to ensure that the most specific filters appear first in the tree. The policies should appear in the
following order.
1.
Authenticated traffic, to which you may want to apply various policies
2. Remaining (unauthenticated) HTTP traffic, which you will redirect to a login URL using the HTTP Redirect policy
3.
Remaining (unauthenticated, non-HTTP) traffic, which you may want to block or throttle.
NOTE
When redirecting traffic to a URL, ensure that traffic to that URL does not fall into the redirect policy as this will cause
a redirect loop. This will not be an issue if the captive portal is on your local network such that traffic from the
unauthenticated users can get to the captive portal directly without going through the Exinda appliance.
If the captive portal is positioned such that the unauthenticated users traffic goes through the Exinda appliance,
then add a policy before the redirect policy that will capture the traffic to the captive portal and will allow it through.
If you have a single authenticated users group, you can create separate virtual circuits for the authenticated and
unauthenticated users. Multiple policies can then be added to the authenticated user virtual circuit to manage these
users.