CN1297105C - Method for implementing multirole main machine based on virtual local network - Google Patents

Abstract

The present invention discloses a method for realizing a multi-role host computer based on a virtual private network (VPN). In the method, a provider edge (PE) router which is connected with a VPN site where a multi-role host computer is positioned is provided with an access control strategy of a VPN retransmitting table of a message which can be accessed by the multi-role host computer. Thus, when the PE router receives a data message from the VPN site, the identity of a host computer which transmits the message is identified according to a source address of the message; if the host computer is the multi-role host computer, then information of a target VPN to be accessed is obtained according to the source address of the message, and the corresponding retransmitting table of the VPN message is searched, and the message is transmitted according to the information, else the message is transmitted according to the VPN attribute of an accessed interface of the host computer. The multi-role host computer based on an operator virtual private network is easy to realize by adopting the scheme and has the advantages of high flexibility and manageability.

Description

A Method of Realizing Multi-Role Host Based on Virtual Private Network

technical field

The invention relates to a virtual private network (VPN), in particular to a method for realizing a multi-role host in the VPN.

Background technique

VPN (Virtual Private Network, virtual private network), is that enterprises or specific user groups use public networks (such as network resources of operators) to build their own private networks to meet their own application needs; through VPN, enterprises or specific user groups can Establish secure, reliable connections, and transfer data at low cost between its branch offices, remote users, business partners, and more. The traditional VPN network is based on IP technology. It uses IP network facilities to simulate a private wide area network. Enterprises or specific user groups use public IP networks to build their own private networks. MPLS/BGP VPN is a kind of IPVPN service that uses Multi-Protocol Label Switching (MPLS) technology and Border Gateway Protocol (BGP) in public networks. Based on it, the RFC2547 standard (RFC, Request for Comments Protocol, Internet's Standard), the VPN described in this standard is a VPN (Provider Provide VPN, PPVPN) provided by the operator. The VPN device is located on the network side, and the operator provides the VPN service for the user. The PE equipment provided by the supplier is enough. Refer to Figure 1. In Figure 1, the service provider's backbone network consists of P equipment and PE equipment. In the device shown in Figure 1:

CE (Custom Edge, User Edge Router): It is an integral part of the user network, with an interface directly connected to the service provider, usually a router, used to connect a VPN user site (Site) to PE.

PE (Provider Edge, backbone network edge router): the operator's edge router, which is the edge device of the operator's network and the main body of implementing MPLS/BGP VPN services. It maintains an independent routing table for each VPN user site, and The user's CE is directly connected. In an MPLS network, all VPN processing occurs on PE routers.

P (Provider, backbone network core router): The backbone router in the carrier network, mainly not directly connected to CE. The P router has the basic forwarding capability of MPLS.

In the current PP VPN solution based on RFC2547, it is required to associate an interface with a VPN instance, that is, assign this interface to a certain VPN attribute, indicating that the data services from this interface must access the VPN associated with the interface, or It is said that users accessing from this interface can only access this specific VPN, and the data services flowing in from this interface can only be the services of the VPN to which this interface belongs. However, in many applications, it cannot be guaranteed that the clients connected to an interface belong to the same VPN. For example, some special servers, or some important hosts in the government network, the VPN they can access and the VPN in the same region The other hosts are different, these hosts usually require more access rights and are not restricted by a VPN, that is, the hosts are required to have multi-role capabilities. In addition, those customers who pass the access server authentication through dial-up authentication and then access different VPNs also require the ability to have multiple roles. Since they are geographically with other hosts, if they access the VPN through the same interface, According to the PP VPN solution in RFC2547, the diversity and particularity of VPNs that these special hosts can access are restricted. In addition, if the VPNs that each host in a region can access are different, then there is no need to associate the access link of this region with a certain VPN. Realize the user's VPN access.

In the current PP VPN application based on RFC2547, no solution has been proposed for this kind of multi-role host. Therefore, in actual networking applications, only such a special host can be connected to PE with a separate interface, and then use the Extranet network topology to solve this problem. For example, in Figure 2, host PC1 requires the multi-role capability of accessing VPN1 and VPN2. PC1 is connected to the carrier’s edge router PE1 through a separate interface or link, and the multi-role function of PC1 is realized by configuring the VPN forwarding table on PE1. Role. But in this way, if the VPNs that can be accessed by this special host are quite different, each host with different VPN access needs to monopolize an access interface. In this way, the number and relationship of VPNs will accumulate and expand, which will lead to a large number of interface resources. Waste and management hassle.

Contents of the invention

The object of the present invention is to provide a virtual private network-based method for realizing multi-role hosts, which has strong flexibility and manageability for realizing multi-roles of hosts.

In order to achieve the above object, the method for realizing multi-role host based on virtual private network provided by the present invention includes:

On the backbone network edge router PE connected to the virtual private network VPN site where the multi-role host is located, set a VPN message forwarding table that the multi-role host can access, and associate the interface of the VPN site with the VPN where it is located;

When the backbone network edge router receives the data message from the above VPN site, it will identify the identity of the host sending the message according to the source address of the message, if it is a multi-role host, then obtain the information of the destination VPN according to the source address of the message, Find the corresponding VPN message forwarding table according to the information and forward the message, otherwise, forward the message according to the message forwarding table of the VPN to which the host belongs.

Configure a static route in the forwarding table of each VPN that the multi-role host needs to access. The next hop of this route is the VPN interface name of the VPN site where the multi-role host is located.

Static routes are not configured in the VPN associated with the interface of the VPN site where the multi-role host resides.

Publishing the static route to the inside of the VPN other than the VPN associated with the interface of the VPN site where the multi-role host is located.

When there are more than two multi-role hosts belonging to the same VPN site, set the addresses of the above-mentioned multi-role hosts to be continuous.

When there is one multi-role host, the static route is a host route; when there are multiple multi-role hosts, the static route is a network segment route.

Configure a filtering policy for multi-role hosts on the PE, and associate the policy with the interface of the VPN site containing the multi-role host, so that when the PE receives data packets from the VPN site where the multi-role host is The source address identifies the identity of the host that sent the message.

A VPN site including multi-role hosts is connected to PEs through public network interfaces.

The present invention provides another method for realizing a multi-role host based on a virtual private network, including:

On the backbone network edge router PE connected to the VPN site where the multi-role host is located, create a virtual private network VPN packet forwarding table that the multi-role host can access, and associate the interface of the VPN site with the VPN;

When the edge router of the backbone network receives the data message from the above VPN site, it will identify the VPN that the host sending the message can access according to the source address and destination address of the message, and forward the user message according to the message forwarding table of the VPN .

Establish a VPN access control table on the edge router of the backbone network, the table includes source address and VPN fields, and is used to describe the access relationship between the user identified by the message source address and the VPN.

Since the present invention sets the VPN message forwarding table that the multi-role host can access on the PE connected to the VPN site where the multi-role host is located, it is not only easy to realize the multi-role host based on the operator's virtual private network, but also through the PE Configure the filtering policy for the multi-role host or set the multi-role host table, so that the multi-role host has strong flexibility and manageability.

Description of drawings

Figure 1 is a MPLS/BGP VPN model diagram;

Fig. 2 is a schematic diagram of an implementation method of an existing multi-role host;

Fig. 3 is a structural diagram of multi-role hosts accessing different VPNs;

Fig. 4 is the embodiment flowchart of the method of the present invention;

Fig. 5 is an example diagram of data flow control of a multi-role host.

Detailed ways

The present invention will be described in further detail below in conjunction with the accompanying drawings.

In the existing PP VPN application scheme based on RFC2547, different VPNs can only be distinguished through interfaces. For example, in the network shown in Figure 3, Site 1 (site1) of VPN1 accesses the PE1 device of the backbone network through an interface. , this interface is bound under VPN1. According to the regulations of RFC2547, all data services entering through this interface should be forwarded through the forwarding table of VPN1 in PE1. Access, thus restricting all hosts in VPN1 site1 to only belong to VPN1. However, in actual networking, it is often impossible to guarantee that the VPN attributes of all hosts in VPN1 site1 are the same. For example, there may be a server PC1, which is a server shared by everyone, and users in other multiple VPNs can also access it; or this PC is a host with some kind of privilege, which can access resources belonging to multiple VPN networks. The above requirements indicate that in actual networking, it is necessary to eliminate the limitation that VPN services can only be distinguished through interfaces, so that multi-role host users in a site connected to PEs through the same interface can access different VPNs and simultaneously access multiple Moreover, users in the above VPN can also access the multi-role host in the site.

The present invention solves this application requirement in this way. On the PE equipment of the backbone network, each host is distinguished according to the source address of the datagram. , connect it to the VPN network that can be accessed, so that this special user can access the required VPN. For those common VPN users, they still perform network access according to the VPN to which the access interface belongs. Specifically, the present invention solves this application requirement in this way. On the PE device, according to the source address of the datagram, the host of this special attribute is distinguished. For this special host, each VPN that allows it to be accessed is configured as required, and For a host without these privileges, its identity is judged by its source address, and it is connected to the VPN to which the interface belongs, and the normal forwarding process is followed. For example, PC1 in Figure 3, it accesses from the interface of VPN1, obtains its identity on the PE according to the source address of the datagram from this host, and then obtains the information of the destination VPN according to the source address, and according to The destination VPN information of the datagram is to search for different VPN message forwarding tables, so that the datagrams from PC1 can reach other VPN sites, and the datagrams from other VPN sites can also be forwarded to this special VPN site. PC1, therefore, configure a static route on PE1 that allows PC1 to access the VPN. The next hop is the name or address of the private network interface of VPN1. This static route may be a host route or a network segment route. That is, when there are many hosts with such special roles in the VPN1 site, assign the same subnet address to these hosts. Then advertise these static routes to different VPNs. For the VPN to which the multi-role host itself belongs, the VPN associated with the access interface may or may not be configured with static routes, because dynamic routing protocols can be used to exchange routes.

The present invention will be described below by taking FIG. 3 as an example. Figure 3 is a simple MPLS VPN network, in which there are three VPNs, VPN1, VPN2, and VPN3, where site1 belongs to VPN1 geographically, and it connects to PE1 through an interface serial 0 to access other sites of VPN1. Due to networking reasons, there is a host PC1 in site1, which is a server. In addition to being accessed by users in VPN1, users in VPN2 and VPN3 also need to access this server, so this server cannot only access VPN1, but also do not want to allow this server to access PE1 through a single interface. At this time, this problem can be solved by using the method described in the present invention to configure and operate the relevant PE equipment.

Assuming that the address of PC1 in the figure is 10.110.1.1, it accesses PE1 on the backbone network through VPN1 site1; the address of VPN1 site2 is 100.1.0.0/16, the address of VPN2 site1 is 100.2.0.0/16, and the address of VPN3 site1 is 100.3 .0.0/16, PE2 connected to the backbone network; the address of VPN1 site3 is 100.4.0.0/16, the address of VPN2 site2 is 100.5.0.0/16, the address of VPN3 site3 is 100.6.0.0/16, connected to the backbone network PE3. Due to the access of multi-role host PC1 on PE1, PE1 must have the forwarding table information of all VPNs to be accessed by the multi-role host PC1 in the site to which it is connected. This requires that PE1 needs to configure corresponding VPN1, The packet forwarding tables of VPN2 and VPN3 also need to configure static routes under the above VPN forwarding tables, so that data packets from other VPNs, that is, sites of VPN2 and VPN3 can flow into the multi-role host of VPN1 Site. Refer to FIG. 4 to illustrate the specific steps of the above method. First perform step 1 on the backbone network edge router PE1 connected to the VPN site VPN1 Site1 where the host PC1 is located, and set a virtual private network (VPN) message forwarding table that the host PC1 can access. That is, set up packet forwarding tables for three VPNs, VPN1, VPN2, and VPN3. For example, use the following command to set VPN1 to set the forwarding table of VPN1 above, and set the forwarding tables of VPN2 and VPN3 in the same way.

ip vrf VPN1; create a VPN named VPN1

rd 100:1; Configure the RD (routing distinguisher) identifier of this VPN1 to be 100:1

route both 100:1; configure the VPN policy of this VPN1 to be 100:1 for both inbound and outbound.

The above configuration can allow data packets to flow into the correct VPN, so the returned data packets also need to ensure that they can flow through the private network interface serial 0. Since there is only one multi-role host PC1 in VPN1 Site1 in this example, VPN2, VPN3 Configure a static route internally. The next hop can be the private network interface name of VPN1. This static route is a host route, so the configuration as shown in the following command can be used:

ip route vrf VPN2 10.110.1.1 255.255.255.255 serial 0;

ip route vrf VPN3 10.110.1.1 255.255.255.255 serial 0;

In VPN2 and VPN3, configure a static route whose address is 10.110.1.1 and the next-hop outbound interface is serial 0.

In this way, the data flow from VPN2 and VPN3 can be imported into interface serial 0 by configuring static routing. Advertise the above static routes to the inside of VPN2 and VPN3.

The VPN1, VPN2, and VPN3 forwarding tables set up in this way are as follows:

VPN1:

100.1.0.0/16 nexthop: pe2

100.4.0.0/16 nexthop: pe3

VPN2:

100.2.0.0/16 nexthop: pe2

100.5.0.0/16 nexthop: pe3

10.110.1.1 nexthop: serial 0

VPN3:

100.3.0.0/16 nexthop: pe2

100.6.0.0/16 nexthop: pe3

10.110.1.1 nexthop: serial 0

Then go to step 2 to associate the interface serial 0 connecting VPN1 site1 to PE1 with VPN1, and bind the interface serial 0 to VPN1, such as using the following command:

interface serial 0; use serial port serial 0;

ip vrf forwarding VPN1; associate serial 0 with VPN1;

ip addr 10.110.0.2 255.255.0.0; Configure the IP address of this interface as 10.110.0.2.

In step 3, configure the filtering policy for host PC1, such as using the following command:

access-list 101 per 10.110.1.1 any; configure a policy that allows packets with a source address of 10.110.1.1 to pass through, and 101 is the policy number.

In step 4, associate the configured filtering policy for host PC1 with the private network interface serial 0, so that when PE1 receives a data packet from the VPN1 site where the multi-role host resides, it can identify the host PC1's address based on the source address of the packet. identity. Such as using the following command to achieve:

interface serial 0; use serial port serial 0;

special-host access-list 101 access-vpn VPN1 VPN2 VPN3; datagrams matching the 101 access policy can access VPN: VPN1, VPN2, VPN3.

Based on the above configurations, the multi-role host PC1 in VPN1 can be accessed by VPN1, VPN2, and VPN3. If there are many hosts with the same access attribute in site1, they can have consecutive addresses through a reasonable planning method so that these The hosts are in the same subnet, which greatly simplifies the configuration on PE1. In this way, you can directly configure the filtering policy for a network segment, that is, configure network segment routing. like:

access-list 101 permit 10.110.0.0 255.255.0.0 any; Configure a policy that allows packets whose source addresses belong to the 10.110.0.0 network segment to pass.

Then configure the reverse static route to point to this special network segment, such as:

ip route vrf VPN2 10.110.0.0 255.255.0.0 serial 0

ip route vrf VPN3 10.110.0.0 255.255.0.0 serial 0

If you need to change the VPN that users can access, you only need to flexibly change the access policy on the PE. For data packets that fail to match the policy, they are directly connected to the VPN to which the interface belongs. If the user needs to access the public network, he can check the forwarding table of the public network and access the public network if no forwarding item is found in the accessible VPN. Of course, the premise is that the address space of the VPN is a private address space. It can be configured as follows:

special-host access-list 101 access-vpn VPN1 VPN2 VPN3 Internet; if the datagram conforming to access policy 101 does not find forwarding information in VPN1, VPN2, and VPN3, it can check the forwarding table of the public network for forwarding.

In addition, if the VPNs that each host in site1 needs to access are quite different, you can no longer associate the interface accessing the PE with a private network, but use the public network interface, but on this interface There should be no routing protocol interaction, so as to prevent private network routes from leaking into the public network when users use the private network address space. If the address space of the public network is used, the user's different VPNs and the public network can be accessed directly at the same time, and Internet access can be realized. In this case, the data packets whose policy matching fails can be directly forwarded according to the forwarding table of the public network.

Finally, in step 5, PE1 forwards the received message to realize the multi-VPN access of the multi-role host and the sharing of the multi-role host PC1 by the users in the multi-VPN.

Refer to FIG. 5 for the specific implementation of the above step 5. When PE1 receives a data packet from VPN1 Site1, it performs policy matching according to the source address of the datagram and the pre-configured policy rules. If the match is successful, it means that the host sending the datagram is a multi-role host, so the matching The datagram accesses the corresponding VPN according to the policy configuration, checks the forwarding table of the VPN that can be accessed, finds the forwarding item, and forwards it according to the normal forwarding process. Therefore, if the datagram comes from PC1, it will be matched successfully and forwarded through the corresponding VPN forwarding table; if the datagram is from a common user, it will not be matched successfully and can only be forwarded by the forwarding table of VPN1. It is also possible to locate the forwarding table of the VPN that the data message should check at once according to the purpose and source address of the data message, and then forward the message.

The returned data flow, that is, the data packet from VPN2, is forwarded from PE2 to PE1 through the static route advertised by PE1, and then forwarded to VPN1 site1 through the inner layer label of the data packet, and reaches the multi-role host PC1.

In short, by flexibly adjusting the policy on PE1, you can control the VPN range accessed by each host in the connected site.

It should be noted that, first, a multi-role host table can also be set on PE1, and this host table is associated with the interface of VPN1 Site1 that contains the multi-role host PC1. This table can only include the source address of the packet. In this way, when PE1 receives a data packet from the VPN site where the multi-role host is located, it can match the source address of the packet with the packet source address in this table, and then Identify the identity of the host that sent the message.

Second, establish a VPN access control table on the PE device, which includes source address and VPN fields, and is used to describe the access relationship between the user identified by the source address of the message and the VPN. In this way, when PE1 receives data packets from VPN2 and VPN3 sites, it identifies the VPN that the host sending the packet can access according to the source address of the packet, and forwards the user packet according to the packet forwarding table of the VPN. If the aforementioned VPN access table includes a destination address field, it is more conducive to packet forwarding. This situation is especially applicable to the situation where the accessed VPNs in the accessed VPN Site are relatively scattered and difficult to determine, and it can also meet the needs of public network users for access.

Claims (10)

1. A method for realizing a multi-role host based on a virtual private network, comprising: On the backbone network edge router PE connected to the virtual private network VPN site where the multi-role host is located, set a VPN message forwarding table that the multi-role host can access, and associate the interface of the VPN site with the VPN where it is located; When the backbone network edge router receives the data message from the above VPN site, it will identify the identity of the host sending the message according to the source address of the message, if it is a multi-role host, then obtain the information of the destination VPN according to the source address of the message, Find the corresponding VPN message forwarding table according to the information and forward the message, otherwise, forward the message according to the message forwarding table of the VPN to which the host belongs. 2. The method according to claim 1, characterized in that: a static route is configured in the forwarding table of each VPN that the multi-role host needs to access, and the next hop of the route is the VPN interface of the VPN site where the multi-role host is located name. 3. The method according to claim 2, characterized in that no static route is configured in the VPN associated with the interface of the VPN site where the multi-role host is located. 4. The method according to claim 2, characterized in that: publishing the static route to the inside of the VPN other than the VPN associated with the interface of the VPN site where the multi-role host is located. 5. The method according to claim 4, characterized in that: when there are more than two multi-role hosts belonging to the same VPN site, the addresses of the multi-role hosts are set to be continuous. 6. The method according to claim 5, wherein when there is one multi-role host, the static route is a host route; when there are multiple multi-role hosts, the static route is a network segment route. 7. The method according to claim 1, 2, 4, 5 or 6, characterized in that: configuring a filtering policy for multi-role hosts on the PE, and correlating the policy with the interface of the VPN site containing the multi-role hosts so that when the PE receives a data packet from the VPN site where the multi-role host is located, it can identify the identity of the host sending the packet according to the source address of the packet. 8. The method according to claim 7, wherein the VPN site including the multi-role host is connected to the PE through a public network interface. 9. A method for realizing a multi-role host based on a virtual private network, comprising: On the backbone network edge router PE connected to the VPN site where the multi-role host is located, create a virtual private network VPN packet forwarding table that the multi-role host can access, and associate the interface of the VPN site with the VPN; When the edge router of the backbone network receives the data message from the above VPN site, it will identify the VPN that the host sending the message can access according to the source address and destination address of the message, and forward the user message according to the message forwarding table of the VPN . 10. The method according to claim 9, characterized in that a VPN access control table is established on the edge router of the backbone network, the table includes source address and VPN fields, and is used to describe the connection between the user identified by the source address of the message and the VPN. access relationship.