Building Scalable Remote Access by Mike Fratto  Client Issues and Support Remote-node networking, extending the network over a dial-up link, requires placing a number of pieces on the remote-access server and the client in order to work properly. The configurations are generally unforgiving-one seemingly harmless misconfiguration and the link will behave erratically, if at all. The job of connecting remote users to the network has become simpler with Windows 95 because of the Telephony Application Programming Interface (TAPI) and the inclusion of network capabilities in the distribution OS. Windows 3.X and DOS users will probably require more support. The kind of clients you will need depends upon both what your users will need to do over the asynchronous link and the existing infrastructure of your LAN. Utilizing open, well-implemented link p rotocols will enhance the flexibility of your remote-access solution. Most remote-access servers support more than one link protocol, however they generally support only one link protocol to a port. Common link protocols that are used to negotiate network traffic between the server and the client are: CSLIP/SLIP Compressed/Serial Line Internet Protocol lets users attach to the network as an IP node. It is effective at supporting IP remote access, but offers little flexibility and growth. ARA Apple Remote Access allows Macintosh machines to connect to AppleTalk networks but it doesn't provide for IP. PPP Point to Point Protocol encapsulates LAN protocols for transmission across a remote access link. It handles the address negotiation for remote nodes and allows the user to connect to a network with multiple network protocols simultaneously. In a heterogeneous network, finding a solution that will fit your needs is critical in terms of building a stable platform for your users. PPP is by far the most versatile link protocol and is supported on virtually every platform, while ARA and C/SLIP are waning due to attrition or limited vendor support. Further work on PPP, such as the Point-to-Point Tunneling Protocol (PPTP) and Multilink PPP (MPP+), promises enhanced services that can be rolled out to the enterprise with fewer problems than replacing one protocol stack with another, along with the attendant applications. Currently, most enhanced PPP services are proprietary, or at the least not completely interoperable. However standards are emerging that will soon offer reliable VPN, and MPP to the remote user. With Windows 95, the PPP and LAN networking stacks are built into the operating system and they require little attention (for the most part) from the user once the initial installation is completed. Windows 3.x users, however, have a more difficult task of connecting to the network because the protocol stacks run as drivers from DOS or a re loaded as Dynamic Link Libraries (DLLs) in the Windows environment, which can cause spurious errors if they are not loaded in the correct order. Even for experienced users, installing the proper stacks and clients properly can be a daunting task. For this reason, using vendor supplied clients may reduce the amount of resources that need to be dedicated to user support. Like other network clients, the installations need to be tested on a variety of systems to ensure the clients will install cleanly. Many clients that support IPX, for example, modify the NET.CFG and AUTOEXEC.BAT files incorrectly, which can leave a machine in an unusable state. Remote node clients really involve two distinct types: dialers that make connections and applications that allow the user to work. A different type of client, remote control, answers the need of getting to the desktop without having to attach a modem directly to it. Dial-up clients make the connections between the remote PC and the remote-access server. Depending on your users, the applications should reside in the native environment your users use. Although a DOS dialer can be run from the command line to make a connection, and then Windows can be launched, the difficulty of use will create discontent from users who have to shut down their applications in order to quit Windows and then connect to the network. More than that, some users may have special needs that need to be addressed, such as token-based security systems or dial-back to access-protected parts of the network unavailable to average users. Application clients supplied by vendors generally only come with rudimentary features (usually enough to test connectivity and little else). Many third-party vendors supply more powerful clients, especially for IP networks, at reasonable costs that let users connect to remote systems, transfer files, and perform other network tasks. Of course, you also need to ensure your existing network applications will operate over the link as we ll. The limited bandwidth available over remote-access links can render data-heavy applications virtually useless. If the dialer client negotiates a standard protocol such as PPP and IP, then virtually any IP-based (in this case) application will be able to run over the link just as if it were attached to the LAN. Remote-control clients are special programs that let users run applications, such as Microsoft Word, over a remote link that otherwise would be impossible to do. Remote-control applications let users take control of a remote desktop by redirecting input and output over the serial port. While they are easy to use and can be very useful, they can pose severe security risks if they are not managed wisely. A remote-control host without a password provides a wide open back door into your network. Even if a user doesn't know a specific machines address, most remote-control packages provide methods for searching for active machines. Application servers that redirect user I/O over a dial-up line serves two functions-it serves as authentication to network services and allows users to access organization-owned software from virtually anywhere. Although not as fast as being on the LAN, user can access desktop applications otherwise unreachable from remote locations. Costs can become an issue when you have to support specific applications that require purchasing additional software for remote users. Software licenses can be bought in bulk, but careful assessment of your users needs will help you use those licenses most efficiently. Many vendors ship dialers with unlimited licenses, but be sure to ask before making a purchase. The link protocol used will largely determine whether you'll be paying for clients or not. Proprietary link protocols, or protocol implementations, will raise the cost not only of installing the clients, but also of the support cost because you'll be tied to a specific application. Updated January 17, 1997 Print This Page E-mail this URL