![]()
Section 2
|
|
The Tunnel Master is a server product to be placed within your organization - behind the company firewall. One Tunnel Master within the corporate LAN would typically be enough, but if needed the network can be expanded on demand. Just plug in new Tunnel Masters as needed. There are no exact measurements on the load that one Tunnel Master can handle, but from initial tests it was reported that 160 active Tunnel Slaves (running a max of 33.3 Kbps) averaged the Tunnel Master at about 5% CPU usage (just to give an impression). The Tunnel Master consist of two basic modules. The Tunnel Master itself (TM.EXE) and a command line utility (SETTUN.EXE) that feeds instructions to the Master. As shown below, a very simple, low resource usage user-interface constitutes the look and feel of the Tunnel Master:
A set of optional command line parameters are available. We will address parameters as needed throughout this guide, but for a summary check the list below:
The Tunnel Master functions by creating an interface on the TCP/IP stack which applications use to communicate. Packets received by this interface are then sent to the appropriate node within the VPN network. The routing changes on your network are accomplished by automatically inserted PROXY ARP entries, one per known Tunnel Slave. These entries will add all the necessary routing capability in order for your network to recognize, and communicate with Tunnel Slaves. Use the OS/2 command line utility 'ARP' to follow the process. If you find that the PROXY ARP entries don't do the job in your network, then static routing can be used to achieve the same effect. To do that, just update the company router with a static route from the LAN0 address to the the Tunnel Network address.
As a small command line utility program, SETTUN feeds instructions to the Tunnel. When used, the executable must be located and run within the same directory as the Tunnel component being controlled. Both SETTUN and TM can be run with the -? option to show a list of available parameters.
Notice, you can just run TM.EXE with default values - that will automatically
put it into operation. You probably would like to change passwords and
customize it a bit, so read on.
This will create a VPN subnet of 254 * 254 (64516) nodes. From this address space, smaller subnets can be assigned to the remote stations, which will run the Tunnel Slave application. For example:
This will create a remote subnet of 254 usable addresses with 10.1.2.1 being
the remote router.
The simple use of the 'PASSWORD.TXT' file is illustrated below (remember that the password file should be located in the same directory as the Master itself):
The password file is mandatory on a Tunnel Master setup. Without the password file, no slaves will be able to connect. The Tunnel Master offers different levels of security. Via plug-ins you can add DES encryption (extra cost option) or even write your own plug-in to apply the security that matches your organization's needs.
Tunnel Software is often used in networks where monitoring is done in one central location. Several methods exists (e.g. Syslog), but instead of binding Tunnel/2 to any of these, it will spawn a .CMD file when an error occurs (fatal as well as non-fatal). The .CMD file, called 'TRACE.CMD' must be located in the working directory of Tunnel/2 in order to be called. The actual error is then provided as a command line parameter for 'TRACE.CMD' - simple, yet flexible and effective! Use the Tunnel Slave to connect remote workstations to your corporate network via the normal public Internet (or other media, such as X.25 - upon request). The Tunnel Slave is made up of two programs (like the Master). You need the Tunnel Slave itself (TS.EXE) and the small SETTUN utility to control the Slave's activity. Both programs will display the available options if started with the parameter -?.
The Tunnel Slave has several command line parameters. Only three parameters are mandatory: Master Address, ISP Gateway Address and Password.
Tunnel Slave robustnessThe Tunnel Slave is designed to work using unstable phone lines and accordingly introduces quite a few mechanisms to keep the bunny going, and going, and . . .
![]() Tunnel/2 could run over a leased line, but as that would bring back in a cost which Tunnel/2 was designed to avoid, an Internet dialer is mostly needed to establish connectivity with the Internet. InJoy is able to provide a robust PPP implementation with dial-on-demand capability. By configuring InJoy's 'disconnect actions' to connect when InJoy sees the string 'RING', it is possible to cause a remote site to connect by dialing the phone number of the modem and then hanging up after one ring. This provides a capability of being able to bring the remote site online when a connection is desired from an outside source. The tunnel master has the capability of accepting a phone number from each Tunnel Slave. If the Tunnel Master receives a packet destined to a remote slave which is not currently on line, it uses the stored phone number to dial the remote system and hang-up. This will cause the remote system to connect. Once the Tunnel Slave is connected, any packets the master is storing for this slave are forwarded. The packet buffering allows for speedy delivery once the connection is there and thereby speedy connections for the TCP/IP applications. In order to provide two way dial-on-demand, the Tunnel Master must have one or more modems with which to dial the remote sites. The communication ports for these modems must be listed in the 'DEVICES.TXT' file, found in the same directory as the master. These modems will be configured by sending them the contents of the 'INITSTR.TXT' file, found in the same directory as the master. The initialization string must be the same for each modem, so modems must be sufficiently similar for this to work. In practice, this is rarely a concern as simple dialing requires little more than a simple reset string such as 'AT&F'. The 'INITSTR.TXT' should NOT contain empty lines or CRLF, as TM.EXE will send out the necessary CRLF. A further point to note is that since these modems do not connect with the remote site there is little reason to use expensive, high speed modems. Almost any reliable modem will do. Collected in this check list are all the actions needed to successfully setup the dialing of remote Slaves:
Tunnel/2 with the InJoy Internet Dialer![]() InJoy is the leading OS/2 dialer and in July 1997 it had risen to first place in OS/2 software sales. If you are not familiar with this program you should take a look at the fastest, most featured and reliable Internet dialer for OS/2. InJoy was highly honored when nominated as one of the Best Internet Tools (cross platform) by the Shareware Industry Foundation. The Dial-On-Demand (DOD) is accomplished by using the standard InJoy Dial-On-Demand in one direction - from workstation to ISP. The other way around the Tunnel Master uses a few modems to trigger the InJoy Dialer to do a call back. The setup for both types of Dial-On-Demand is shown in the following InJoy dialogue:
Besides the Dial-On-Demand features, InJoy offers many features which help in setting up a robust VPDN environment. Features like re-dial, re-connect, exit at failure, tracing (both built in and supporting the OS/2 utilities IPTRACE and IPFORMAT), connection logs, terminal mode, multiple phone number lists and autostarting/stopping at literally any event. |