Using Remote
Access Service (RAS), you can easily set up a Windows NT Server 4.0 system to
act as a gateway between remote systems and your LAN-based hosts (e.g., UNIX
systems, IBM mainframes, IBM AS/400s, Digital Equipment VAXs). In this
environment, remote systems can dial in to the RAS server and then directly
access a host using TCP/IP-based services such as Telnet or FTP. Similarly, if
you have a conventional SNA environment attached to your LAN, you can also use
RAS to accommodate access to IBM mainframes and AS/400s via SNA Server.
You can use a wide variety of remote systems to access a host via a RAS
server, but I'll focus on these three remote system configurations: a Macintosh
system using TCP/IP to access a UNIX host, a Windows 3.x system using TCP/IP to
access a UNIX host, and a Windows 3.x system using SNA Server to access an IBM
host. (The absence of DOS, NT Workstation, and UNIX configurations from this
list does not mean that you cannot use them as remote systems--I've excluded
them for the sake of my sanity.) I'll also touch briefly on using SNA Server to
access an IBM host from Windows 95 and NT Workstation systems.
TCP/IP for Host Access
Before jumping into the remote system configurations for direct TCP/IP
access to a host, let's pause and look at three big-picture considerations that
relate to the way TCP/IP operates. First, do you have (or need) a TCP/IP router
(called a gateway) in your LAN? Second, do you have a name server in your LAN,
and if so, is it configured to support your host? Third, how should you assign
the IP address to the remote system? Let's examine each of these considerations.
A TCP/IP gateway provides a path that lets your TCP/IP traffic travel from
one logical network (IP subnet) to another. If all your local and remote systems
use IP addresses that reside in the same subnet, you don't need a gateway. If
your remote systems use IP addresses that reside in a separate subnet, you must
have a gateway in place to move traffic between the subnets. The most common
application for a TCP/IP gateway is to provide a link to the Internet (which, of
course, is a huge collection of TCP/IP subnets).
The second consideration--name serving--affects your ability to
reference hosts by name. For example, if you want to launch a Telnet session to
a UNIX host named AIXLAB, you would probably like to say
TELNET AIXLAB
A name server provides a central service to convert IP names into IP
addresses. If you have a name server, make sure you configure the name of your
UNIX host in it. If you don't have a name server, don't feel obligated to
implement one: You have two alternatives.
First, you can define host-to-address mapping files in each remote system
in a hosts file. Most TCP/IP implementations support the ability to resolve
names from such a file. Second, you can avoid using names entirely and use only
the IP address to initiate connections. For example, if the IP address for
AIXLAB is 216.56.55.63, you can use the command
TELNET 216.56.55.63
The final consideration is how to set the IP address on the remote system.
You have two options: You (or the user) can manually configure the IP address on
the remote system, or you can have the IP address download from the RAS server
dynamically.
Given a choice, opt for letting the server determine the address. This
approach provides centralized control and eliminates the possibility of a typo
in an IP address. Unfortunately, you will find that many Point-to-Point Protocol
(PPP) implementations do not support dynamic address assignment, or even worse,
their implementations of dynamic address assignment are incompatible with
Microsoft's implementation (hey, it happens). In these cases, you must manually
assign IP addresses in your remote systems.
Time to PPP
With a backdrop now in place, let's talk about two specific configurations
for direct TCP/IP access to a host system in your LAN: access from a Macintosh
and access from a Windows 3.x system. Strangely enough, the Macintosh connection
is the easier connection to set up--the Macintosh operating system better
integrates TCP/IP than does the Windows 3.x environment.
To enable Mac-to-AS/400 access over TCP/IP, you need the MacTCP control
panel installed on your Mac, and you need add-on support for PPP. In my testing
(and in real life), I use the ConfigPPP program; however, you can find many
other free PPP implementations on the Web. ConfigPPP installs as both a system
extension and a control panel. You must configure both the MacTCP and the
ConfigPPP modules (via their control panel interfaces).
First, access the MacTCP control panel and select the PPP interface in the
opening dialog box. Press More to access the detailed configuration options, as
shown in Screen 1. Perform the following actions in this dialog box:
- In the Obtain Address field, select Server to have the address
downloaded from the RAS server, or select Manually to set up a static address.
Screen 1 shows the configuration to obtain an address from the server.
- In the Routing Information area, set the Gateway Address to the address
of your IP router, or to 0.0.0.0 if a router is not present. (The example in
Screen 1 does not define a gateway.) If you choose to server-assign the IP
address, the RAS server can also download the IP address of the default gateway.
- If you chose Server in step 1, skip to step 4. If you chose Manually,
configure the IP address in the IP Address configuration area. You must first
choose the class of address (A, B, or C) and then set the address value. The
format of this entry field is rather strange, so be prepared to spend some time
to figure it out.
- If you are using a name server, specify the name of the domain it
services and its IP address. For example, Screen 1 shows that the system at
204.56.55.1 handles names for the duke.com domain.
Press OK when you complete the configuration. You must restart your Mac to
put these settings into effect.
Next, move to the ConfigPPP process. In the ConfigPPP control panel dialog
box, shown in Screen 2, make the following settings on the opening panel:
- Set the Port Name to the location of your modem attachment. Usually,
this setting is Modem Port.
- Set the desired Idle Timeout. A value of None means that the PPP
connection will not time out and disconnect when no traffic is present. (I find
no time out desirable.)
- Set the Echo Interval to Off.
- In the check-box section, select only Hangup on Close.
The previous ConfigPPP steps set only basic system-level information. You
must now define the particulars of your RAS connection. Click New and specify a
name for this connection--a logical name that does not have to match the
computer name of the RAS server. After specifying a name, you return to the
initial ConfigPPP display. Then, click Config to set the configuration details
as follows:
- Set the Port Speed to the speed at which you want your Mac to talk to
your modem. This setting needs to be at least as fast as your modem speed.