Virtual private network: Difference between revisions
John Leach (talk | contribs) m (Text replacement - "Border Gateway Protocol" to "Border Gateway Protocol") |
John Leach (talk | contribs) m (Text replacement - "{{subpages}}" to "{{PropDel}}<br><br>{{subpages}}") |
||
Line 1: | Line 1: | ||
{{subpages}} | {{PropDel}}<br><br>{{subpages}} | ||
{{TOC|right}} | {{TOC|right}} | ||
{{seealso|Tunneling protocol}} | {{seealso|Tunneling protocol}} |
Revision as of 04:49, 8 April 2024
This article may be deleted soon. | ||
---|---|---|
A virtual private network (VPN) "is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN..." [1] Motivations for VPNsBefore the term VPN came into general use, other terminology was used. Some authors discourage the terms, but others find they are a valuable complement to the more technical VPN terminology, as they emphasize business relationships. The most basic motivation to have a VPN is financial: if the customer does not have to build a private network but can map it onto a commodity IP service, both the capital and operational costs drop. Small users, who might not be able to fund highly skilled networking personnel, can outsource that cost. Indeed, cloud computing technology is a superset of VPNs, which outsources servers as well as the network. It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement. The customer usually can articulate a set of requirements:[2]
Providers also speak informally of "clue factor", or the knowledge level of the customer. Some VPN technologies are too complex for customers, or, indeed, service providers. For example, it has been easier for many traditional telephone companies to use "layer 2 VPN" technology to emulate existing Frame Relay or dedicated line services, rather than train technicians in routing. Administrative controlIf all the sites are under the control of a single network administration authority, such as an enterprise, the VPN is called an intranet. If the sites are under the control of multiple administrators that have agreed to technical and operational policies, the VPN is called an extranet. The global Internet is under the control of multiple administrators that agree to exchange reachability to a set of addresses under the authority of the Internet Assigned Numbers Authority (IANA), using the Border Gateway Protocol. A number of large SPs are treating their customers' public Internet connectivity as "just another VPN", yet one that is totally isolated from the intranets and extranets. Modern VPN technology lets the same addresses appear, without conflict, in multiple VPNs. Frequent misconceptions
User experienceWhen a computer end user brings up the local VPN software, called the VPN client, on a computer that has previously had general Internet connectivity, that connectivity will cease, or be under the control of the VPN. Technical frameworkIn almost all cases a VPN is an overlay network onto a lower-level connectivity network, such as the Internet, a non-public set of IP nodes over a private routed network, or IP over on-demand services such as dialup. Implementation architectureCustomer organizations may have a network support group that runs a backbone, through which multiple, administratively isolated, VPNs can run. For example, an enterprise with multiple physical sites, connected by satellite links, might have separate VPNs for finance, manufacturing, research, and human resources. When a backbone is administered in this manner, the VPNs are called customer-provisioned VPNs (CPVPN). Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the quality of service, availability, and bandwidth that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called provider-provisioned VPNs (PPVPN)s.[3] In PPVPNs, the customer sites interconnect to a backbone is operated by a service provider, who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an Internet Service Provider (ISP), an Application Service Provider (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc. [4] Initially, think of the sites speaking to the backbone through some mutually agreed protocol; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are tunneled through the provider backbone. Sites connect to the "(inter-site) backbone" through customer edge (CE) devices or functions. The CE need not be a physical device. A CE may be aware of multiple VPNs. There are many situations where a given enterprise, or set of enterprises forming an extranet, may use a combination of CPVPNs and PPVPNs. Customer provisioningIn a customer-provided VPN, the customer manages connectivity among the CE. It is possible and common to have CPVPNs tunnel among customer sites using a secure tunneling protocol, such as IPSec, over physical connections to Internet Service Providers. The ISP, in such cases, will be completely unaware of the VPNs. Provider provisioningIn a provider-provisioned VPN, the CE provide reachability information to provider edge (PE) devices or functions that are aware of both the VPN, and the provider backbone onto which the VPNs are mapped. Again, a PE need not be a physical device. Most often, however, it is a router. Observe, however, that the CE at Site 1 is multihomed, for fault tolerance, to two diverse PE. Not shown in this level of diagram, but a CE also could be fault tolerant, with redundant components. The PEs are aware of the VPNs, but also of the interconnection of PEs, which is hidden from the customers. PEs can require significant control plane processing power both to route and to maintain VPN information. Internal to the provider backbone may be provider (P) devices or functions that maintain connectivity in the provider backbone, but are themselves unaware of the VPNs. A routing protocol runs among them, but simply passes the reachability of the P's and PE's. Links to and among P devices usually are very high capacity. In most large provider, they are multigigabit optical facilities. The physical devices on which the P function is implemented does not need a powerful control plane but is optimized in the forwarding plane. Connectivity to the CE and PEWhile the first VPNs used Internet Protocol version 4 (IPv4) for connectivity to the CE if the CE was an onsite physical device operated by the SP, or from the CE to the PE if the CE belongs to the customer, the VPN is not limited to running as a routed network. In a given environment, there may be:
Some L2 offerings are called virtual private LAN service, while other L1 offerings are called virtual private line service, both having the abbreviation VPLS. Using L2VPN and L1VPN is much less likely to lead to confusion. L2VPNs and L1VPNs usually need a routing protocol to pass VPN administration information, although there are provider-provisioned autodiscovery mechanisms that will isolate the customer from this requirement. Communicating policies and reachability between customer and providerDepending on the type of VPN in use, the customer may run a routing protocol internal to the customer sites, of which the SP need not be aware. If the customer needs to tell the PE what VPNs exist, what address spaces each support, and even if there are restrictions on connectivity within a single VPN, then this needs to be manually configured, which is maintenance-intensive, or the information can be sent through extensions to a routing protocol such as the Border Gateway Protocol (BGP)[4] or Open Shortest Path First (OSPF) [5] Secure VPNsThe policies and procedures for any virtual private network must include some means of ensuring privacy. One definition runs:
There are many ways to manage the privacy requirements. Security requirements, policies and procedures can all be different in various applications, and several different tunneling protocols are available. In a trusted VPN, the security is part of the service; in effect the customer trusts the service provider to maintain data integrity and privacy.
Of course this can be done over virtual circuits as well as over physical ones. In a fairly common example, Asynchronous Transfer Mode connections support an Internet Protocol service. In a secure VPN, encryption is used to achieve privacy.
A number of different encrypting protocols may be used to construct a secure VPN. IPsec is most often used for secure VPNs between an organisation's offices and may also be used for "road warriors", individuals connecting to the organisation's network from home or from laptops. VPNs based on SSL are also common; for example, many companies (e.g. [1] [2]) offer a single user VPN service for users who need to circumvent the Great Firewall of China or other censorship. A similar service may also be provided using PPTP or SSH. A hybrid VPN has elements of both the other types.
References
|