In "The Eternal Quest: Connect Your Small Network to the Internet," November 2000, and "Beyond Internet Connection Sharing," December 2000, I explain how to set up a Windows 2000 system as a Network Address Translation (NAT) router. In this issue, I finish up that router configuration and have enough space left to show you a cool trick about Windows File Protection (WFP). (For more information about NAT and WFP, see "Related Articles in Previous Issues," page 174.)
Completing Your NAT Router
In my past two columns, I explained how to get the NAT function working and arrange the connection to the Internet either through an ISP or, as in the training lab example I presented in my December column, through a corporate network. I configured the router in that example to let anyone on the nonroutable private 192.168.0.0 network access the Internet and to map a particular port from the router to a port on a system on the internal network. Now, I take that setup a step further and give the NAT router control of an entire subnet's worth of routable addresses, rather than limit the router to sharing ports on its one routable address.
Typically, giving a router a bunch of addresses lets the router act as a static router—a go-between for two or more subnets, all of which contain routable addresses. Although having enough routable addresses to give one to each system in your internal network would be nice, you might not have that many addresses. In such a situation, you won't give a routable address to each system in the internal network. Instead, you'll set up the router to perform port address translation in most cases, meaning that most traffic from the internal network to the external network will use simple Internet Connection Sharing (ICS)-like port address translation. What will be different is that you'll set up the NAT router to essentially "glue" a routable address to a computer on the internal, nonroutable network.
To make this process easy to follow, I'll use a specific example. Let's say that the Win2K system that acts as your router connects to the Internet through an Ethernet connection and has the IP address 206.246.253.9. Let's also suppose that your local ISP, IT department, or other provider has given you a small range of addresses, from 206.246.253.180 through 206.246.253.183. In IP network terms, this range of addresses means that you have network number 206.246.253.180 with subnet mask 255.255.255.252. Because you can't use the first or last address in the subnet, you have only two routable addresses—206.246.253.181 and 206.246.253.182. You need the first one for the router, so you have only the second address, 206.246.253.182, available to assign to an internal system.
On the internal network, suppose you have a mail server at 192.168.0.10 that you'd like the outside world to see. Your goal, then, is to associate routable address 206.246.253.182 with nonroutable address 192.168.0.10, so that, for example, someone on the Internet can ping 206.246.253.182 and receive answers to that ping not from the router, but from the internal machine at 192.168.0.10.
This process has three steps. First, you need to make sure that routers on the public Internet send traffic intended for the .181 and .182 addresses to the router at address 206.246.253.9. You don't need to perform this step yourself—your ISP or IT department will take care of it. The service provider must set up its routers to point to your Win2K system as the router for the .181 and .182 addresses.
Second, you need to prepare your router to accept incoming traffic for the addresses in the assigned block. To do so, you open the Routing and Remote Access Administration tool and right-click the object representing the NIC that is attached to the public Internet. Choose Properties, and you'll see the Local Area Connection Properties dialog box, which has tabs labeled General, Address Pool, and Special Ports. Click the Address Pool tab to display the screen that Figure 1, page 174, shows. To tell the tool about the range of addresses, click Add, fill in the resulting dialog box, and click OK. Now, the system is ready to act as the router for that range of addresses.
Third, you need to "glue" 206.246.253.182 to the mail server at 192.168.0.10. On the Address Pool tab, click Reservations, and you'll see a dialog box that contains a Reserve this public IP address field. Fill in the routable 206.246.253.182 address. In the For this computer on the private network field, type the mail server's nonroutable IP address. Finally, select the Allow incoming sessions to this address check box. Click OK to close the dialog box, and you're finished.
Disabling WFP
To finish this column, let's switch gears and talk a bit about WFP. This neat Win2K feature prevents applications from overwriting important system files.
For example, suppose an application designer comes up with an interesting twist for a dialog box. The developer decides not only to use the dialog box in the application but also to share it with the world by rewriting comdlg32.dll. Comdlg32.dll is the Windows DLL that contains the code for several common dialog boxes, such as the one that many applications present when you click File, Open. (By the way, this scenario is "based on a real story," as many TV movies advertise. Several years ago, I installed a graphics application that used a new version of this file.) In this scenario, the programmer's new dialog box might not work with every Windows application. Although the new application works fine because the developer built it with the modified comdlg32.dll in mind, other applications that used to work might mysteriously begin to misbehave.
WFP protects you from this type of problem. If you had installed this application on your Win2K machine and the application's setup program overwrote comdlg32.dll, WFP would wake up within seconds and notice that comdlg32.dll had been modified. WFP would then access hidden directory \winnt\system32dllcache and retrieve a backup copy of the original comdlg32.dll. WFP would overwrite the new comdlg32.dll with the original, and all would be well. WFP protects all .dll, .ocx, .exe, and .sys files shipped with Win2K, not any files that you add later.
But what if you want to overwrite a DLL? Maybe you're a developer, or maybe you need to run a quirky application that simply won't work without a special modification of some system DLL. (Well-designed applications shouldn't require you to overwrite a system file, but some do.) Here's a workaround.
Go to the application's directory and create a zero-byte file that you name appname.exe.local. Then, copy the special .dll file (or .exe, .ocx, or .sys file—whatever file your application is trying to use to supersede a standard OS file) to the application's directory. The zero-byte file in the application's directory signals Win2K to search that directory for all .dll, .exe, .ocx, and .sys files that the application uses before looking in the \winnt\system32 directory.
For example, suppose I want to run an application called marksapp.exe, which I've installed in directory C:coolapp on my Win2K machine. I try to execute the application, but it refuses to run, even though it has run on Windows NT in the past. I call the vendor, who explains that the application can't run without its special version of the route .exe file. If the vendor isn't forthcoming in identifying which file you need a special version of (or if the vendor is only a fond memory at this point), you can track down the file. Use the Event Viewer to look in the System log, where you'll see Event ID 64002 from source "Windows File Protection" alerting you to the fact that something or someone tried to overwrite route.exe, but that WFP saved the day and restored the file.
The fix to make marksapp.exe work is easy. First, I go to C:\coolapp and create a zero-byte file and name it marksapp .exe.local. Then, I copy the modified route.exe file to C:\coolapp. Marksapp .exe will now run fine.
Alternatively, I could just go to HKEY_LOCAL_MACHINE\SOFTWAREMicrosoft\Windows NT\CurrentVersionWinlogon and set the entry SFCDisable to FFFFFFD9, then reboot. However, disabling WFP wholesale might not be a particularly bright idea, so I don't recommend it.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000
mag.com/articles. ZUBAIR AHMAD "Windows 2000's Network Address Translation," February 2000, InstantDoc ID 7882 DARREN MAR-ELIA "Taming DLL Hell," November 2000, InstantDoc ID 15705 MARK MINASI Inside Out, "Beyond Internet Connection Sharing," December 2000, InstantDoc ID 16011 Inside Out, "The Eternal Quest: Connect Your Small Network to the Internet," November 2000, InstantDoc ID 15732 KEN SPENCER "The System File Checker," November 2000, InstantDoc ID 15706 "File Signature Verification," November 2000, InstantDoc ID 15707 |
