Before we start discussing virtual private networks (VPNs), what they mean, and why they're useful, take a second to consider that acronym, VPN: "virtual," as in simulated, "private," as in secret and confidential, and "network," as in a collection of computers.
Logically, a VPN is simply an extension of a private network. In reality, private networks are geographically isolated from remote users and other private networks by nonsecure communication lines such as the Internet. By using a secure, network-level protocol like IPSec, a private link can be emulated between two separate networks. What is actually the wrapping of data before it passes through nonsecure extranets or intranets is perceived by both requestor and authenticator as a private dedicated line. Because data packets are protected by encryption, any in transit interception results in unreadable data.
Unlike using IPSec for peer-to-peer transmissions, VPNs use a dedicated server that is tied to the private network. By accepting connections from only VPN-authorized clients, the VPN server allows private traffic within the physical enclave to proceed normally without requiring additional internal security.
Before you can establish a VPN connection, VPN authorization must be confirmed for the client. Authorization is based on the remote access policies set by the network administrator and on the dial-in properties of the client requesting the connection. Once a user is determined to be authorized and one-way or mutual authentication occurs, the VPN can be established. Windows 2000 includes two protocols that are used to encapsulate data over the virtual private network:
An authorized but isolated user can access the protected resources of a private or hidden network by authenticating to the network's VPN server and establishing a VPN connection. The remote user can be at home or on the road needing to connect through an ISP and the Internet, or the remote user can be part of the same intranet but detached from the secure or hidden network.
For example, suppose engineering has a hidden enclave within an enterprisewide network, complete with secret documents and alpha-version software. They want to grant access to the hidden network to the VP of Engineering but don't want to compromise the confidentiality of the information as it crosses the company's intranet. By providing a VPN server that blocks unauthorized users but allows the vice president to authenticate and establish a VPN connection, engineering's secret network is extended to one more user.
Simply because you have a VPN connection to a private network does not mean that you have full access. You still need the correct permissions to access specific resources.
Once the client establishes a VPN connection with the VPN server, the user appears to be accessing the private network directly. Figure 18-7 shows remote access for an Internet-based VPN.
Figure 18-7. Remote access for an Internet-based VPN.
A VPN connection can also be established for two mutually exclusive private networks. In this case, both the VPN client and VPN server are routers. Like remote access VPNs, router-to-router VPNs can involve enclaves that are part of the same intranet, or they can involve private networks that require the Internet infrastructure for communication. Figure 18-8 shows a router-to-router connection for an intranet-based VPN.
Figure 18-8. A router-to-router VPN connection.
Here the VPN client authenticates itself to the VPN server, and a secure VPN connection is negotiated. Again, the logical appearance in both cases is that the private networks are physically connected. You'll find more on VPNs in Chapter 32.