A Guide to Managing
Remote Users
Managing
a Remote Site Network
April 10, 2000
By John Shireley
In general, you'll
be connecting a remote network via a fixed digital circuit, and most likely
using routers between the two. With enough bandwidth management planning
and a proper router configuration, your remote users should operate as
though they were in the same building. Depending on the strictness of
your security policy and complexity of your network, you can leave things
well enough alone after you're set up. Usually you will only deal with
issues such as circuit outages or router firmware upgrades as necessary.
There’s another
thing to be aware of when trying to keep the infrastructure invisible
and seamless to your users. A workstation or other host on a remote network
really doesn’t know or care that it’s talking to another host
on another subnet in terms of infrastructure or individual host configuration.
Your connecting routers act as gateways and handle all of that. Security
is still a large concern of course, but as long as you apply the same
policies to your remote network that you do to your local one, and the
transport mechanisms between them, you’ll be fine.
If the remote network
isn’t attached to your central site directly via a point-to-point
circuit and you’re using the Internet to access each other, security
becomes a bigger concern. You need to consider firewall and VPN technologies.
Many dedicated firewalls now offer integrated VPN support. The easiest
way to address this issue would be to configure a pair of dedicated units
to talk to each other directly. This remains invisible to the desktop
clients on either side (or servers), and should ease most of your security
concerns. Since the secure traffic is tunneled from end-to-end by the
hardware, there is nothing further to configure at the desktop level which
greatly decreases your support and management burden.
Another alternative
to consider for connecting smaller client networks via the Internet if
you need to be more budget-conscious is to install them with a dial-on-demand
setup. This eliminates the cost of a dedicated circuit connection on their
side, which most ISPs charge higher fees for. Using ISDN access as an
example, you only need to purchase a single dial-up ISDN account (telco
fees remain the same, of course) from the service provider. Here’s
how it works: You install a router that supports a special feature that
allows it to dial in and share the connection with the rest of the network
by acting as the gateway. When no traffic is present for a predefined
time period, the unit closes the connection. When new traffic is sensed,
it calls the ISP back and re-establishes the connection.
There are several
caveats here, however. This particular setup will only work when you don’t
need to access their network for management purposes during off-hours;
if no one is there using it, it’s down and you can’t access
it (unless you set up "camping," but most ISPs frown on this
since it wastes their resources). Network-to-network security can be a
major hassle if you can’t get a static IP address for your far side.
Because the router is constantly redialing the connection, it’s usually
getting a different IP address assigned. You will not be able to add it
to any access-control lists on your side. In general, it’s an inexpensive
way to have a remote network reach you via the Internet, but there are
quite a few trade-offs for you to consider.
Bandwidth
Considerations
Bandwidth considerations
can be quite intimidating. One of your most difficult challenges will
be determining how much you’re going to need between locations, which
of course is determined by application type and usage patterns. This is
an area where you can’t allocate enough money. To be the most cost-effective,
you’ll need to utilize techniques that allow you to maximize your
available resources. Methods for calculating your bandwidth needs greatly
depend on your particular application.
When determining
the right formula, first address what is the specific type of data (large
files or small files) and the application delivery method (e-mail or database
access, for example), as well as your performance expectations. After
you’ve determined the amount of bandwidth overhead needed for each
application and how many users will require access, you can begin to formulate
what type of connection speed will be necessary by compounding these elements
using a simple linear equation. Bandwidth needed will be the variable
you’re solving for, and you should multiply users by applications
by data overhead (and latency requirements) of each application. There
are many resources already available to you, but make sure you’re
examining the right parameters to meet your unique needs. No one particular
bandwidth calculator will be the precise one, so try several to ensure
that you’re getting the whole picture.
Even after you've
deployed as much bandwidth as possible, you may still run into some latency
or other speed issues, especially as your users increase their traffic
on your circuit. If you suddenly find your T1 feeling more like a rusty,
old modem connection, explore the possible reasons why, and don't limit
yourself to known applications. In fact, the applications that you planned
for most likely are not causing the slow-down problems. Streaming video
from auction sites within the accounting department is more likely the
culprit. Perform a site visit and walk around to see what people are doing.
You'd be surprised at just how brazen some folks are with their Web browsers.
Develop fair usage
policies with management that are enforceable. Consider purchasing some
type of traffic-shaping or limiting device, such as a firewall that is
able to filter based on content. That will return your circuit back to
normal.
If you've eliminated
extraneous traffic as the culprit, it's time to use the packet sniffers
and traffic analyzers. These tools should be in your arsenal: They are
extremely helpful in determining exactly what is happening on your network.
If you find your circuit is getting clobbered by legitimate traffic, it's
time to think about load-balancing across multiple circuits, or upgrading
to a larger one.
Disaster
Recovery
Finally, you should
create a failover or disaster-recovery solution for your remote connection.
Since you’re connecting your remote network with your central one,
there are probably important business processes occurring every day that
can not tolerate a great deal of downtime. One very good method of providing
for recovery from a failed circuit is to have two in place instead of
one. One primary circuit, which is going to be your fattest pipe, and
one secondary circuit for emergency use. In addition to cost savings,
it’s better to use a separate type of circuit as an auxiliary one.
It is less likely to be affected by whatever brought the first circuit
down. Do make sure that your fail-over circuit(s) can meet the bare minimum
of your transfer and latency needs however; it's not going to do you any
good to bring a connection back up that no one can use.
As you can see managing
a remote and mobile workforce requires a great deal of forethought. It
is not enough to merely hang a remote-access server off your Windows NT
server. You must carefully examine your security needs, user requirements,
environmental constraints, network capabilities, and support capacity
long before you divvy out that first dial-up number. But through careful
planning, you can bring your distant workers back into the fold.
|
REPORTS
ANALYTICS
Follow 
