JP6770132B2 - VPN construction program - Google Patents

Description

The present invention relates to a communication system, a communication device and a VPN (Virtual Private Network) construction method, and more particularly to a communication system, a communication device and a VPN construction method constituting a DMVPN (Dynamic Multipoint Virtual Private Network).

When building a VPN between a large number of bases such as companies via a wide area network, a mechanism to build a secure network that can directly exchange data between bases without going through the VPN device at the head office DMVPN is one of the solutions provided. DMVPN is an abbreviation of "Dynamic Multipoint Virtual Private Network", and it is possible to construct a hub-and-spoke VPN and generate a virtual tunnel between spokes on demand when communication between spokes occurs. In other words, DMVPN can provide performance close to full mesh while adopting a hub-and-spoke type configuration. The virtual tunnel is constructed by encapsulating the original packet with the carrier protocol by the VPN device.

For example, the VPN device, which is a spoke under the LAN (Local Area Network) of the base, and the VPN device, which is a hub located at the head office, are connected by a virtual tunnel via a wide area network such as the Internet. At this time, a virtual tunnel is always set between the hub and the spokes, and the spokes are configured to generate a virtual tunnel only when necessary. In this way, the DMVPNN virtual tunnel is a virtual tunnel in which a plurality of spokes are connected to the hub and there are a plurality of destinations. Therefore, a multipoint GRE (Generic Routing Encapsulation) that performs routing encapsulation at multiple points is used. In addition, IPsec (Internet Protocol Security), which encrypts the transferred data, is used to ensure the security of communication in the virtual tunnel.

That is, the hub and each spoke are connected by a static IPsec virtual tunnel, and an IPsec virtual tunnel is established between the spokes on demand. With this configuration, it is possible to flexibly construct a network that reduces the load on the hub and ensures communication security.

In addition, IPsec is defined by the IETF (Internet Engineering Task Force) as a VPN standard protocol in order to perform highly secure LAN-to-LAN communication between routers via the Internet. IPsec is a technology that encrypts communication between routers that connect a LAN to the Internet via the Internet according to a predetermined protocol, and prevents data transmitted and received between these routers from being eavesdropped or tampered with. .. That is, the routers that connect the LAN to the Internet encrypt and encapsulate the packets transferred in the Internet by IPsec to construct a secure VPN.

In addition, there is NHRP (Next Hop Resolution Protocol) as a technology used in DMVPN.

NHRP is a protocol for address resolution in an NBMA (Non Broadcast Multiple Access) environment, which is a multi-access network that does not support broadcasting, and is specified in RFC (Request For Comments) 2332 of the IETF. NHRP is for resolving the NBMA (Non Broadcast Multiple Access) address, which is the physical address on the wide area network side of the destination VPN device, from the destination IP (Internet Protocol) address (private IP address on the virtual network) of the virtual tunnel. It is a protocol.

In DMVPN, for example, a dynamic virtual tunnel between spokes is created by the following procedure.

Each spoke under the hub notifies the hub of the private IP address and NBMA address of its own virtual tunnel in advance by NHRP registration. Then, the hub holds the mapping information of the private IP address and the NBMA address of the virtual tunnel of each spoke.

When terminal A in the private network under one spoke A communicates with terminal B in the private network under another spoke B, the data packet is transmitted in the route of terminal A → spoke A → hub → spoke B → terminal B. Will be done.

At this time, when the hub detects that the spoke A that is the source of the packet and the spoke B that is the destination of the packet can dynamically generate a virtual tunnel, it sends an NHRP traffic notification to the spoke A. The NHRP traffic notification stores the private IP address of the terminal B in the private network under the spoke B.

Upon receiving the NHRP traffic notification, spoke A sends an NHRP resolution request to the private IP address of terminal B in the private network under spoke B.

The NHRP resolution request is received at spoke B via the hub.

Spoke B returns an NHRP resolution response to Spoke A. The private IP address and NBMA address of the virtual tunnel of spoke B are stored in the NHRP resolution response.

In spoke A that has received the NHRP resolution response, route information is generated that packets destined for the private network under spoke B are forwarded to the private IP address of the virtual tunnel of spoke B. At the same time, the spoke A holds the mapping information between the private IP address and the NBMA address of the virtual tunnel of the spoke B.

Spoke A uses the address information of spoke B that it holds to create a virtual tunnel to spoke B. As a result, the data packet after the virtual tunnel is generated is directly transmitted from the spoke A to the spoke B without passing through the hub, and is transmitted to the terminal B in the private network under the spoke B.

In the above description, it is assumed that the hub that receives the NHRP resolution request from spoke A sends it to spoke B, and spoke B returns the NHRP resolution response. However, if the protocol allows the return of the NHRP resolution response based on the mapping information cached in the hub, the hub that received the NHRP resolution request may return the NHRP resolution response. Here, for the sake of simplicity, it is assumed that the hub that received the NHRP resolution request from spoke A sends it to spoke B, and spoke B returns the NHRP resolution response.

Here, NAT (Network Address Translation) and STUN (Simple Traversal of User Datagram Protocol through NATs) protocols will be reviewed as technologies related to VPN.

NAT is an address translation performed by the gateway device that connects the private network and the Internet, and the private IP address and the global IP address held by the gateway device are translated. NAT is defined by the IETF RFCs 2766, 2663, 3022 and the like. Here, NAT means NAT in a broad sense including NAPT (Network Address Port Translation) in a narrow sense. And the address port shall mean either an address only, an address and a port.

The STUN protocol is a global IP address port required for a communication device located behind a device that executes NAT (NAT device) to communicate across a NAT device when making a UDP (User Datagram Protocol) connection. , Used to get the NAT type. The STUN protocol is specified in the IETF RFC3489.

The network configuration in which the STUN protocol operates consists of a STUN server, a NAT device, and a STUN client.

The STUN server is a server that provides services related to the execution of the STUN protocol, and is an address information providing device that is provided on the Internet and provides information necessary for communicating beyond a NAT device.

A STUN client is a communication device in a private network located behind a NAT device. The STUN client sends a test message to a STUN server on the Internet via a NAT device, and acquires information on what the STUN client looks like from the STUN server. That is, the STUN client acquires the global IP address port and NAT type required for communication across the NAT device from the STUN server.

In the STUN protocol, NAT is classified into four types (NAT types) according to the mapping method of the address / port translation of NAT executed by the NAT device. There are four NAT types, full cone NAT, address limiting cone NAT, port limiting cone NAT, and symmetric NAT, depending on the restrictions on the terminals on the Internet side that can access the port assigned by NAT.

Full-cone NAT does not limit the terminals on the Internet side that can access the port assigned by NAT, and makes the session port once opened accessible to anyone. That is, regardless of the communication partner, the address / port is translated according to the entry in the NAT translation table and passed to the inside of the NAT device (private network side).

The address restriction cone NAT restricts the terminals on the Internet side that can access the port assigned by NAT in an address-dependent manner. That is, it is made accessible only from a terminal having an address on the Internet side that has been accessed by a terminal under the NAT device, and address / port translation is performed according to the entry in the NAT translation table to pass it inside the NAT. The "terminal under the NAT device" means a terminal on the private network side connected to the NAT device.

The port restriction cone NAT restricts the terminals on the Internet side that can access the port assigned by NAT depending on the address and the port. In other words, it can be accessed only from terminals that have an address and port number on the Internet side that have been accessed by terminals under the NAT device, and address / port translation according to the entry in the NAT translation table is performed and passed inside the NAT device. Let me.

Symmetric NAT generates an entry in the NAT translation table for the communication source terminal, which has a different port number for each destination on the Internet side of the communication destination. In other words, if the destination on the Internet side changes, the port number for the NAT Internet will always change. Then, as the terminal on the Internet side that can access the port assigned by NAT, it is limited only when the terminal on the private network side of the communication source and the terminal on the Internet side of the communication destination have a one-to-one correspondence.

The operation until the STUN client knows the global IP address / port after its own NAT translation is as follows.

The STUN client sends a STUN request message to the global IP address port of the STUN server.

When a STUN request message passes through a NAT device, a NAT translation table entry is generated and the source IP address port is rewritten from the private IP address port to the global IP address port.

When the STUN server receives the STUN request message, it sends the STUN response message to the global IP address port of the source address port of the STUN request message. At this time, the STUN server includes the global IP address port in the STUN response message.

When the STUN response message passes through the NAT device, the destination address port is rewritten to the private IP address port based on the NAT translation table entry, and the STUN response message is received by the STUN client.

The STUN client can know its own global IP address and global port from the information of the global IP address / port included in the STUN response message.

The STUN server has two IP addresses and port numbers. Then, when the STUN client sends a STUN request message, the request message can include an IP address change and a port number change request. As a result, the source IP address and port number of the response message from the STUN server can be changed. In the STUN protocol, this mechanism allows the STUN client to specify the NAT type of the NAT device to which it is connected by performing communication between the STUN client and the STUN server several times.

Techniques relating to VPN devices, NAT and STUN are disclosed in Patent Documents 1 to 3.

Patent Document 1 discloses a VPN device capable of shifting to P2P communication when P2P (peer-to-peer) communication is possible during communication. Even if there is a NAT device whose operating characteristics change depending on the conditions and only communication via the relay server can be performed at the start of a call, P2P communication may be possible during the communication. In such a case, the VPN device disclosed in Patent Document 1 can shift to P2P communication.

This VPN device is equipped with a NAT type determination unit, performs NAT type determination processing when communicating with the other device via a relay server, and has a high possibility of performing P2P communication with the other device. If it is determined, the process of shifting to P2P communication is performed. Further, this VPN device includes an external address / port acquisition unit that acquires external address / port information used when accessing the own device from the external side of the relay device.

The external address / port acquisition unit executes communication of a predetermined test procedure with the STUN server, and receives a response packet containing the global IP address and port assigned for communication of the own device from the STUN server. .. In addition, the NAT type is determined by STUN. The NAT type determination unit determines whether or not P2P communication is possible depending on the combination of NAT types installed on the transmitting side and the receiving side.

When shifting to P2P communication, the calling side and the called side are connected using the call control port via the call control server, and communication port information for performing communication via the relay server is exchanged. Then, in the communication via the relay server, the information of the P2P port that performs P2P communication is exchanged. The call control server is a device that holds identification information of a registered terminal or the like and provides a service related to call control between communication devices for calling a specific destination and establishing a communication path.

Patent Document 2 is a VPN device capable of determining the NAT type of a relay device between networks in which address translation is performed, promptly determining the communication possibility with the other device, and constructing a communication path with the other device. To disclose.

The VPN device sends at least two test packets to the STUN server to different address ports on the STUN server. Then, the NAT type of the relay device is determined based on the external address / port information included in the response packets from the different address ports to these test packets, and the communication possibility is determined.

When it is determined that communication is possible and the process shifts to P2P communication, a connection request including external address / port information is transmitted from the calling side to the called side via the call control server. When the called party receives a connection request via the call control server, the called party acquires the external address / port information of its own device from the STUN server in the same manner as the calling party. Then, the connection response including the external address / port information is returned to the calling side via the call control server.

In this way, both the calling side and the called side acquire the external address / port information of the other party via the call control server, and thereafter, the external address / port information is obtained between the calling side and the called side. It is used for P2P communication. The call control server is a device that holds identification information of a registered terminal or the like and provides a service related to call control between communication devices for calling a specific destination and establishing a communication path.

Patent Document 3 discloses a communication device such as an IP-PBX (Private Branch Exchange) or an IP key telephone system that connects between local networks connected via the Internet or the like.

The IP-PBX acquires the access information (global IP address / port) of its own device from the router or STUN server that functions as the gateway of the local network, and creates an e-mail in which the acquired access information is inserted in the text. Then, the IP-PBX transmits the e-mail to a remote IP telephone deployed in a different local network as a destination. A remote IP telephone registers with the IP-PBX using the access information described in the e-mail. By this registration, the IP-PBX controls incoming / outgoing calls to the IP telephone at a remote location.

Japanese Unexamined Patent Publication No. 2011-188358 JP-A-2010-283594 Japanese Unexamined Patent Publication No. 2011-041138

In DMVPN, in a network environment in which the spokes are located under the NAT device, the two spokes trying to perform inter-spoke communication cannot know each other's global IP address after NAT translation. The reachable address information of the transferred data that is notified on the Internet is the global IP address. Therefore, in a network environment in which the spokes are located under the NAT device, the global IP addresses of the other spokes cannot be known in both spokes, and a virtual tunnel cannot be dynamically established between the spokes.

For example, DMVPN can realize a full-mesh VPN by arranging VPN devices at the head office and each base in a corporate network via the Internet. Normally, it is necessary to select an ISP (Internet Service Provider) for connecting to the Internet. In some ISPs, carrier grade NAT has been introduced against the background of the IP address exhaustion problem.

When the ISP for connecting the VPN device to be a spoke to the Internet has introduced a carrier grade NAT, the IP address port of the spoke under the carrier grade NAT is translated by the carrier grade NAT. Therefore, even if an attempt is made to dynamically generate a virtual tunnel between spokes under a carrier grade NAT, it is not possible to know the global IP address port after each NAT translation.

On the other hand, Patent Documents 1 to 3 disclose a technique for knowing the global IP address port after NAT conversion using the STUN protocol.

Then, in the technology disclosed in Patent Document 1 and Patent Document 2, the calling side and the called side exchange the global IP address port after NAT conversion acquired by using the STUN protocol with each other via the call control server. It is configured as follows. Further, in the technique disclosed in Patent Document 3, the global IP address port after NAT conversion acquired by using the STUN protocol is configured to be notified to a remote IP telephone by using e-mail.

The call control server in Patent Document 1 and Patent Document 2 holds identification information of a registered terminal or the like, and provides a service related to call control between communication devices for calling a specific destination and establishing a communication path. It is a device. Then, Patent Document 1 and Patent Document 2 assume an environment in which such a call control server is deployed. Further, Patent Document 3 presupposes that a configuration for transmitting an e-mail is required.

Therefore, there is a problem that the techniques disclosed in Patent Documents 1 to 3 cannot be used for a system to which such a premise cannot be applied.

In other words, even if the global IP address port after NAT translation can be obtained, the spokes on DMVPN that do not have a call control server deployed environment or a configuration for sending e-mail will send that information to the spokes of the other party. There is a problem that it cannot be communicated.

The present invention is a communication system capable of dynamically generating a virtual tunnel by notifying the acquired global IP address / port information after NAT translation between the spokes in an environment where the spokes on the DMVPN are under the control of the NAT device. , Communication device and VPN construction method.

In order to achieve the above object, the communication system, which is one embodiment of the present invention, functions as a spoke constituting DMVPN (Dynamic Multipoint Virtual Private Network), and NAT (NAT) of packets transmitted and received between networks in different address spaces. Network Address Translation) External address / port information that is installed under the relay device that performs address translation and is the address information that can be accessed from the address space outside the relay device, which is generated by the NAT address translation. The external address / port information is acquired from an address information providing device having a reply function, and the external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN. It functions as a hub constituting the DMVPN, the first communication device and the second communication device, which are at least two communication devices, and receives from each of the first communication device and the second communication device under the control. The first communication device and a third communication device that registers the external address / port information included in the NHRP registration packet in mapping information associated with each of the first communication device and the second communication device are included. The communication device 3 is used in communication from the first communication device, which is the spoke of the packet transmission source, to the second communication device, which is the spoke of the packet transmission destination, via the third communication device. When it is detected based on the mapping information that a virtual tunnel can be generated between the first communication device and the second communication device, the first communication device is instructed to generate the virtual tunnel. Then, the first communication device, which has been instructed to generate the virtual tunnel by the third communication device, has the external address of the first communication device in the extended field of the NHRP resolution request packet used in the DMVPN. The second communication device that transmits including the port information and receives the NHRP resolution request packet from the first communication device puts the second communication in the extended field of the NHRP resolution response packet used in the DMVPN. The first communication device that replied including the external address port information of the device and received the NHRP resolution response packet is the external address port of the second communication device included in the NHRP resolution response packet. information Based on the above, the virtual tunnel is generated between the second communication device and the second communication device.

Further, the communication device which is another form of the present invention is generated by the NAT address translation via a relay device which performs NAT (Network Address Translation) address translation of packets transmitted and received between networks in different address spaces. External address / port information for acquiring the external address / port information from an address information providing device having a function of returning external address / port information which is address information that can be accessed from the address space outside the relay device. The acquisition means and the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN (Dynamic Multipoint Virtual Private Network) include the external address / port information and transmit the external address / port information to the DMVPN hub. In inter-spoke communication via the hub, when notified that a virtual tunnel can be created with the destination spoke, the external address / port information is entered in the extended field of the NHRP resolution request packet used in the DMVPN. The external address / port information of the destination spoke is obtained from the extended field of the NHRP resolution response packet used in the DMVPN sent by the destination spoke that has been transmitted to the destination spoke and received the NHRP resolution request packet. Includes an address resolution means to be acquired and a tunnel generation means to generate the virtual tunnel between the destination spoke and the destination spoke based on the external address / port information of the destination spoke acquired by the address resolution means. It is characterized by that.

Further, another form of the present invention, the VPN construction method, functions as a spoke constituting a DMVPN (Dynamic Multipoint Virtual Private Network), and a NAT (Network Address Translation) address of a packet transmitted and received between networks in different address spaces. The external address from an address information providing device that is installed under the relay device that performs conversion and has a function of returning external address port information, which is address information that can be accessed from the address space outside the relay device. Each of the first communication device and the second communication device, which are at least two communication devices for acquiring port information, has the external address port in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN. A third communication device that transmits information including information and functions as a hub that constitutes the DMVPN is included in the NHRP registration packet received from each of the first communication device and the second communication device under the control. The external address / port information is registered in mapping information associated with each of the first communication device and the second communication device, and is the spoke of the packet transmission source via the third communication device. In communication from the first communication device to the second communication device which is the spoke of the packet transmission destination, the third communication device is between the first communication device and the second communication device. When it is detected based on the mapping information that the virtual tunnel can be generated, the first communication device is instructed to generate the virtual tunnel, and the third communication device is instructed to generate the virtual tunnel. The first communication device that has received the message transmits the extended field of the NHRP resolution request packet used in the DMVPN, including the external address / port information of the first communication device, and the first communication device receives the message. The second communication device that has received the NHRP resolution request packet returns the extended field of the NHRP resolution response packet used in the DMVPN, including the external address / port information of the second communication device, and the NHRP. The first communication device that has received the resolution response packet communicates with the second communication device based on the external address / port information of the second communication device included in the NHRP resolution response packet. Virtual ton It is characterized by generating flannel.

Further, another way of constructing a VDC, which is another embodiment of the present invention, is to use a relay device that performs NAT (Network Address Translation) address translation of packets transmitted and received between networks in different address spaces. The external address / port information is acquired from an address information providing device having a function of returning external address / port information which is address information that can be accessed from the address space outside the relay device generated by address translation. , The external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in DMVPN (Dynamic Multipoint Virtual Private Network) and transmitted to the DMVPN hub, and from the hub via the hub. When it is notified that a virtual tunnel can be created with the destination spoke in the inter-spoke communication, the external address / port information is included in the extended field of the NHRP resolution request packet used in the DMVPN. The external address / port information of the destination spoke is acquired from the extended field of the NHRP resolution response packet used in the DMVPN sent to the destination spoke and returned by the destination spoke that has received the NHRP resolution request packet. Based on the acquired external address / port information of the destination spoke, the virtual tunnel is generated between the destination spoke and the destination spoke.

According to the present invention, in an environment where the spokes on the DMVPN are under the control of the NAT device, the acquired global IP address / port information after NAT translation can be notified between the spokes to dynamically generate a virtual tunnel.

It is a block diagram which shows the structure of the communication system of 1st Embodiment of this invention. It is a block diagram which shows the structure of the communication apparatus of 1st Embodiment of this invention. It is a sequence diagram explaining the operation between the apparatus in the communication system of 1st Embodiment of this invention. It is a flow diagram explaining the operation of the communication apparatus of 1st Embodiment of this invention. It is a block diagram which shows the structure of the communication system of the 2nd Embodiment of this invention. It is a sequence diagram explaining the operation between devices in the communication system of the 2nd Embodiment of this invention. It is a block diagram which shows the structure of the communication apparatus of 2nd Embodiment of this invention. It is a block diagram which shows the extended field of the NHRP protocol packet. It is a flow chart which shows the operation of a hub. It is a flow chart which shows the operation of a spoke. It is a sequence diagram which shows the conversion control of a port number in the IPsec packet transmission and reception of NAT traversal. It is a figure which shows the correspondence of whether or not the dynamic virtual tunnel can be generated by the combination of NAT type. It is a flow diagram which shows the control operation according to the NAT type of the own device side and the NAT type of the other device side in the spoke. It is a flow chart which shows the update operation of the external address / port information in a spoke.

A mode for carrying out the present invention will be described with reference to the drawings.

It should be noted that the embodiments are exemplary, and the disclosed devices, systems and methods are not limited to the configurations of the following embodiments.

(First Embodiment)
The communication system of the first embodiment will be described.
FIG. 1 is a block diagram showing a configuration of a communication system according to a first embodiment of the present invention. The communication system 1 of the present embodiment is a network form that constitutes a DMVPN (Dynamic Multipoint Virtual Private Network) in which a private network of a company or the like is connected via a wide area network 60.

The first communication device 10 is a communication device that belongs to the first private network 61 and functions as spokes of DMVPN. The second communication device 20 is a communication device that belongs to the second private network 62 and functions as spokes of DMVPN. Further, the third communication device 30 is a communication device that belongs to the third private network 63 and functions as a hub of DMVPN. In FIG. 1, only the first communication device 10 and the second communication device 20 are shown as the communication devices to be spokes, but this is an example of the minimum configuration, and the number of communication devices to be spokes is large. It is optional. The first private network 61, the second private network 62, and the third private network 63 are private networks belonging to the same company or the like. When it is not necessary to explain each private network separately, the term "private network" is used for the explanation.

The first communication device 10 is installed under the control of the first relay device 40 that performs NAT address translation in the first private network 61. Further, the second communication device 20 is installed under the control of the second relay device 50 that performs NAT address translation in the second private network 62. In addition, when it is not necessary to explain each relay device separately, it will be generically referred to as "relay device".

NAT refers to a function that performs address translation of packets sent and received between networks in different address spaces. That is, NAT converts the address information used in the private network and the address information used in the wide area network held by the relay device. Further, here, NAT means NAT in a broad sense including NAPT (Network Address Port Translation) in a narrow sense. And the address port shall mean either an address only, an address and a port number.

Further, "installed under the control" means that the relay device is installed inside the private network as a boundary. Therefore, "outside" and "outside" mean the wide area network side with the relay device as a boundary.

Further, an address information providing device 70 is connected to the wide area network 60, and the external address / port information generated by NAT address translation is returned to the first communication device 10 and the second communication device 20. Has a function. Here, the external address / port information is address information that allows access to the first communication device 10 and the second communication device 20 from the wide area network side, which is the address space outside each relay device.

Each of the first communication device 10 and the second communication device 20 acquires external address / port information from the address information providing device 70. Then, the external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registered packet used in DMVPN and transmitted.

The third communication device 30 uses the external address / port information included in the NHRP registration packet received from each of the first communication device 10 and the second communication device 20 under the control of the first communication device 10 and the second communication device 20. It is registered in the mapping information associated with each of the communication devices 20 of the above. Here, "subordinate" means spokes to the hub in the configuration of DMVPN.

The first communication device 10 which is the spoke of the packet transmission source communicates with the second communication device 20 which is the spoke of the transmission destination by a virtual tunnel via the third communication device 30.

The third communication device 30 communicates between the first communication device 10 and the second communication device 20 via the third communication device, and the first communication device 10 and the second communication device 20 are used. Detects that a virtual tunnel can be created between and based on the mapping information. Then, the third communication device 30 instructs the first communication device 10 to create a virtual tunnel.

Upon receiving an instruction to generate a virtual tunnel from the third communication device 30, the first communication device 10 sets the external address / port information of the first communication device 10 in the extended field of the NHRP resolution request packet used in DMVPN. Include and send.

The second communication device 20 that has received the NHRP resolution request packet from the first communication device 10 includes the external address / port information of the second communication device 20 in the extended field of the NHRP resolution response packet used in DMVPN. Reply.

Then, the first communication device 10 that has received the NHRP resolution response packet communicates with the second communication device 20 based on the external address / port information of the second communication device 20 included in the NHRP resolution response packet. Create a virtual tunnel in.

The communication device of the first embodiment will be described.

FIG. 2 is a block diagram showing a configuration of a communication device according to the first embodiment of the present invention.

The communication device 100 of the first embodiment has a configuration including an external address / port information acquisition means 110, an address resolution means 120, and a tunnel generation means 130.

The external address / port information acquisition unit 110 acquires external address / port information from the address information providing device via a relay device that performs NAT address translation of packets transmitted / received between networks in different address spaces.

The external address / port information is address information that can be accessed from the wide area network side, which is the address space outside the relay device generated by NAT address translation. The address information providing device is a device having a function of returning the external address / port information to the communication device 100.

The address resolution means 120 includes the external address / port information in the extended field of the NHRP registration packet used by the DMVPN and transmits it to the hub of the DMVPN.

When the address resolving means 120 is notified by the hub that a virtual tunnel can be created between the spokes and the spokes of the other party in the inter-spoke communication via the hub, the address resolving means 120 makes a partner the NHRP resolution request packet used in DMVPN. Send to the first spoke. Include external address and port information in the extended fields of the NHRP resolution request packet.

Further, the address resolution means 120 acquires the external address / port information of the destination spoke from the extended field of the NHRP resolution response packet used in the DMVPN returned by the destination spoke that received the NHRP resolution request packet.

The tunnel generation means 130 generates a virtual tunnel with the destination spoke based on the external address / port information of the destination spoke acquired by the address resolution means 120.

Next, the VPN construction method of the first embodiment will be described with reference to FIGS. 3 and 4.

FIG. 3 is a sequence diagram illustrating an operation between devices in the communication system 1 of the first embodiment shown in FIG.

FIG. 4 is a flow chart showing the operation of the communication device 100 of the first embodiment shown in FIG.

The VPN construction method of the first embodiment is implemented by operating the communication system 1 and the communication device 100.

First, the operation between the devices in the communication system 1 will be described with reference to FIG.

Each of the first communication device 10 and the second communication device 20 that function as spokes constituting the DMVPN acquires external address / port information from the address information providing device 70 (S101, S102).
The first communication device 10 and the second communication device 20 are under the control of the first relay device 40 and the second relay device 50 that perform NAT address translation of packets transmitted and received between networks in different address spaces. Will be installed. Then, the address information providing device 70 has a function of returning the external address / port information generated by NAT address translation to the first communication device 10 and the second communication device 20. The external address / port information can access the first communication device 10 and the second communication device 20 from the wide area network side, which is the address space outside the first relay device 40 and the second relay device 50, respectively. Possible address information.

Each of the first communication device 10 and the second communication device 20 that have acquired the external address / port information transmits the external address / port information including the external address / port information in the extended field of the NHRP registration packet used in DMVPN (S103, S104).

This NHRP registration packet is received by the third communication device 30 that functions as a hub that constitutes DMVPN. Then, the third communication device 30 uses the external address / port information included in the NHRP registration packet received from each of the first communication device 10 and the second communication device 20 as the first communication device 10 and the second communication device 20. It is registered in the mapping information associated with each of the communication devices 20 (S105).

Communication is performed from the first communication device 10 which is the spoke of the packet transmission source via the third communication device 30 to the second communication device 20 which is the spoke of the packet transmission destination. In this communication, the third communication device 30 detects that a virtual tunnel can be generated between the first communication device 10 and the second communication device 20. The third communication device 30 performs this detection based on the mapping information (S106).

The first communication device 10 is instructed to create a virtual tunnel (S107).

Upon receiving an instruction to generate a virtual tunnel from the third communication device 30, the first communication device 10 sets the external address / port information of the first communication device 10 in the extended field of the NHRP resolution request packet used in DMVPN. It is included and transmitted (S108).

The second communication device 20 that has received the NHRP resolution request packet from the first communication device 10 includes the external address / port information of the second communication device 20 in the extended field of the NHRP resolution response packet used in DMVPN. Reply (S109).

The first communication device 10 that has received the NHRP resolution response packet virtually communicates with the second communication device 20 based on the external address / port information of the second communication device 20 included in the NHRP resolution response packet. Generate a tunnel (S110).

Subsequent communication between the first communication device 10 and the second communication device 20 is performed by a dynamically generated virtual tunnel without going through the third communication device 30 which is a hub.

Next, the operation of the communication device 100 will be described with reference to FIG.

External address / port information is acquired from the address information providing device via a relay device that performs NAT address translation of packets sent and received between networks in different address spaces (S201).

The external address / port information is address information that can be accessed from the wide area network side, which is the address space outside the relay device generated by NAT address translation. The address information providing device is a device having a function of returning the external address / port information to the communication device 100.

NHRP registration is performed by including the external address / port information in the extended field of the NHRP registration packet used in DMVPN and transmitting it to the hub of the DMVPN (S202).

Inter-spoke communication via the hub is executed (S203).

In inter-spoke communication via the hub, the hub notifies that a virtual tunnel can be created between the spokes and the other spoke (S204).

The external address / port information is included in the extended field of the NHRP resolution request packet used in DMVPN and transmitted to the destination spoke (S205).

The NHRP resolution request packet returned by the destination spoke in response to the NHRP resolution request packet is received, and the external address / port information of the destination spoke is acquired from the extended field of the NHRP resolution response packet (S206).

A virtual tunnel is created between the spokes and the spokes based on the acquired external address / port information of the spokes (S207).

As described above, in the present embodiment, the external address / port information whose NAT address is translated by the relay device is acquired from the address information providing device. Then, it can be included in the extended field of the NHRP protocol packet and notified between the spokes.

Therefore, in an environment where the spokes on the DMVPN are under the control of the NAT device, the acquired global IP address / port after NAT translation can be notified between the spokes, and a virtual tunnel can be dynamically generated.

(Second Embodiment)
Next, a second embodiment of the present invention will be described.

(Configuration of Communication System of Second Embodiment)
FIG. 5 is a block diagram showing a configuration of a communication system according to a second embodiment of the present invention.

In the communication system 2 of the present embodiment, the first VPN device 11 and the second VPN device 21 which are the spokes of each base and the third VPN device 31 which is the hub of the head office are connected by a virtual tunnel via the Internet 65. It is in the form of constructing a DMVPN. Then, the spokes of the first VPN device 11 and the second VPN device 21 generate a dynamic virtual tunnel only when necessary. Here, only the first VPN device 11 and the second VPN device 21 are illustrated as the minimum configuration, but the number of bases and the number of VPN devices to be spokes installed therein is arbitrary. The virtual tunnel is routed by the multipoint GRE, and the transfer data is encrypted by IPsec to ensure the security of communication.

The first VPN device 11 connects the first LAN 12, which is the LAN of the base, to the LAN side interface, and connects the first gateway 41 that performs NAT address translation to the WAN (Wide Area Network) side interface. .. That is, the first VPN device 11 is installed under the control of the first gateway 41, and the first LAN 12 is under the control. In the route information of the first VPN device 11, the first gateway 41 is set as the default gateway, and the private IP address of the first gateway 41 is set.

Further, the second VPN device 21 connects the second LAN 22 which is the LAN of the base to the LAN side interface, and connects the second gateway 51 which performs NAT address translation to the WAN side interface. That is, the second VPN device 21 is installed under the second gateway 51, and the second LAN 22 is under the control. In the route information of the second VPN device 21, the second gateway 51 is set as the default gateway, and the private IP address of the second gateway 51 is set.

The first gateway 41 and the second gateway 51 convert the address information used in the private network under their respective control and the address information used in the Internet 65 held by each gateway. In the present embodiment, the address information used in the private network is a private IP address port, and the address information used in the Internet 65 is a global IP address port.

In the following description, "NAT address translation" is simply referred to as "NAT" or "NAT translation". Further, a gateway having a NAT function is also referred to as a "NAT device".

A STUN server 71 is installed on the Internet 65. The STUN server 71 returns the external address / port information generated by NAT executed by each corresponding gateway to the first VPN device 11 and the second VPN device 21 which are STUN clients by the STUN protocol. Has a function.

Here, the external address / port information is address information that can access the first VPN device 11 and the second VPN device 21 from the Internet 65, respectively, and means a global IP address / port.

In addition, the external address / port information includes NAT types classified according to the mapping method of address / port translation performed by each gateway. That is, there are four types, full cone NAT, address limiting cone NAT, port limiting cone NAT, and symmetric NAT, depending on the restrictions of terminals on the Internet side that can access the port assigned by NAT.

Corresponding the above configuration with the communication device 1 of the first embodiment shown in FIG. 1 is as follows.

The first VPN device 11, the second VPN device 21, and the third VPN device 31 correspond to the first communication device 10, the second communication device 20, and the third communication device 30, respectively.

The first gateway 41 and the second gateway 51 correspond to the first relay device 40 and the second relay device 50, respectively.

The Internet 61 corresponds to the wide area network 60, and the STUN server 71 corresponds to the address information providing device 70.

Further, as in the first embodiment, also in this embodiment, NAT refers to a function of performing address translation of packets transmitted and received between networks in different address spaces, and refers to NAT in a broad sense including NAPT in a narrow sense. means. And the address port shall mean either an address only, an address and a port number.

Looking at the communication system 2 physically configured as described above from the viewpoint of a virtual network, the DMVPNN route information is distributed by a dynamic routing protocol such as BGP (Border Gateway Protocol), and is as follows. Is set to.

The first VPN device 11 and the second VPN device 21 that are spokes on the virtual network constructed with DMVPN and the third VPN device 31 that is a hub are called stations, and each station has its own tunnel IP address. ing. The tunnel IP address is an IP address on the virtual network assigned to the tunnel interface and is used when sending and receiving packets between stations on DMVPN.

In the first VPN device 11, the tunnel IP address of the third VPN device 31, which is a hub, is set as the next hop to the second LAN 22 under the second VPN device 21, which is the spoke destination. Similarly, in the second VPN device 21, the tunnel IP address of the third VPN device 31, which is a hub, is set as the next hop to the first LAN 12 under the first VPN device 11 which is the spoke destination. ing.

Further, in the third VPN device 31 which is a hub, the tunnel IP address of the first VPN device 11 is set as the next hop to the first LAN 12 under the first VPN device 11. Similarly, in the third VPN device 31, which is a hub, the tunnel IP address of the second VPN device 21 is set as the next hop to the second LAN 22 under the second VPN device 21.

Further, as the IP address assigned to the physical interface of each station, there are a private IP address and a global IP address. For example, since the first VPN device 11 and the second VPN device 21 belong to the private network, a private IP address is assigned. Since the third VPN device 31 is located on the Internet, it has a global IP address.

When the terminal belonging to the first LAN 12 transmits a data packet to the terminal belonging to the second LAN 22, the packet is routed by the tunnel IP address set as described above and passes through the tunnel constructed by DMVPN. That is, the data packet having the IP header of the tunnel IP address is GRE-encapsulated, the IP header of the IP address of the physical interface is added, and the data packet is transferred within the Internet 65. Then, in the tunnel between stations, the transferred packet is encrypted by IPsec.

(Operation between devices in the communication system of the second embodiment)
FIG. 6 is a sequence diagram illustrating operations between devices in the communication system 2 of the second embodiment shown in FIG.

In order for the DMVPN to function, the first VPN device 11 and the second VPN device, which are spokes to the hub, are before starting communication between the terminal belonging to the first LAN 12 and the terminal belonging to the second LAN 22. Registration of the NHRP protocol by 21 is performed in advance.

First, each of the first VPN device 11 and the second VPN device 21 acquires information necessary for registering the NHRP protocol.

Each of the first VPN device 11 and the second VPN device 21 makes an inquiry to the STUN server 71 deployed on the Internet 65, and acquires their own global IP address port and NAT type after NAT translation (). S301, S302).

The operation at this time will be described by taking the first VPN device 11 as an example.

The first VPN device 11 uses its own private IP address port as a source address and transmits a STUN request destined for the global IP address port of the STUN server 71. When this STUN request goes out to the Internet 65 via the first gateway 41, NAT conversion is performed. That is, the source address of the STUN request is rewritten from the private IP address port of the first VPN device 11 to the global IP address port assigned by NAT translation, and the entry is generated.

The STUN server 71 that has received the STUN request transmits a STUN response including the global IP address port of the source address of the STUN request to the global IP address port as a destination.

This STUN response reaches the first gateway 41, which is the destination's global IP address port. In the first gateway 41, NAT translation in the reverse direction is performed based on the entry generated when the above STUN request passes. That is, the destination of the STUN response is rewritten from the global IP address port to the private IP address port of the first VPN device 11 based on the entry, and is received by the first VPN device 11.

In this way, the first VPN device 11 uses the STUN protocol to acquire a global IP address port that is NAT-translated when going out to the Internet 65. Also, the NAT type of the first gateway 41 is specified. The first VPN device 11 stores the acquired global IP address port and NAT type in its own device as global IP address port information.

The second VPN device 21 also acquires the global IP address port and NAT type that are NAT-translated by the second gateway 51 and stores them in the own device by the same operation as described above.

It should be noted that the above-mentioned NAT-translated global IP address port is periodically acquired by the STUN protocol. Then, if there is a change in the global IP address port, it is kept up to date. The process for keeping the global IP address / port up-to-date will be described later.

Each of the first VPN device 11 and the second VPN device 21 obtained from the STUN server 71 for the global IP address port and NAT type to be NAT-translated are registered with NHRP for the third VPN device 31 which is a hub. (S303, S304).

Each of the first VPN device 11 and the second VPN device 21 transmits an NHRP registration request to the third VPN device 31. A NAPT extension, which will be described later, is added to the extension section of the NHRP registration request, and the global IP address port and NAT type acquired from the STUN server 71 are stored.

The third VPN device 31 that has received the NHRP registration request retrieves the global IP address port and NAT type of the first VPN device 11 and the second VPN device 21 included in the NAPT extension of the NHRP registration request. Then, the third VPN device 31 registers mapping information in which the tunnel IP address on the virtual network of each spoke, which is the source address of the NHRP registration request, is associated with the global IP address port and the NAT type (). S305).

The third VPN device 31 for which NHRP registration has been completed returns the NHRP registration response to the first VPN device 11 and the second VPN device 21. At this time, the acquired NAPT extension information is used as the destination physical IP address of the NHRP registration response and the destination UDP port number used in NAT traversal of IPsec.

When the NHRP registration is completed, DMVPN can be used.

Inter-spoke communication via the hub is performed between the terminal belonging to the first LAN 12 and the terminal belonging to the second LAN 22 (S306).

When the terminal belonging to the first LAN 12 transmits a data packet to the terminal belonging to the second LAN 22, the data packet is transferred to the first VPN device 11 which is a spoke.

The first VPN device 11 forwards a data packet addressed to a terminal belonging to the second LAN 22 under the second VPN device 21 to the third VPN device 31 which is a hub according to the route information.

The third VPN device 31 transfers a data packet addressed to a terminal belonging to the second LAN 22 under the second VPN device 21 to the second VPN device 21.

Since the destination of the data packet is the terminal belonging to the second LAN 22 under its own control, the second VPN device 21 forwards the data packet to the terminal belonging to the second LAN 22. The data packet is received at the terminal.

In the above operation, when the hub third VPN device 31 transfers a data packet, it is determined whether or not inter-spoke communication is possible between the first VPN device 11 and the second VPN device 21. (S307).

This determination is made based on the NAT type corresponding to both spokes of the mapping information registered in the third VPN device 31. Details will be described later.

When it is determined that spoke-to-spoke communication is possible between the first VPN device 11 and the second VPN device 21, the third VPN device 31 sends NHRP to the first VPN device 11 that is the source of the data packet. A traffic notification is sent to instruct the implementation of address resolution (S308).

The first VPN device 11 that has received the NHRP traffic notification starts NHRP resolution.

The first VPN device 11 transmits an NHRP resolution request to the private IP address port of the terminal belonging to the second LAN 22 (S309).

At that time, the NAPT extension of the first VPN device 11 is added to the extension part of the NHRP resolution request. The NAPT extension stores the global IP address port and NAT type acquired by the first VPN device 11 from the STUN server 71.

The NHRP resolution request is received by the second VPN device 21 via the third VPN device 31 in the same manner as the data packet from the terminal belonging to the first LAN 12 to the terminal belonging to the second LAN 22.

The second VPN device 21 that has received the NHRP resolution request transmits an NHRP resolution response to the first VPN device 11 (S310).

The NAPT extension of the second VPN device 21 is added to the extension of the NHRP resolution response. The NAPT extension stores the global IP address port and NAT type acquired by the second VPN device 21 from the STUN server 71.

The NHRP resolution response reaches the first VPN device 11 via the third VPN device 31 according to the route information, and is received by the first VPN device 11.

The first VPN device 11 provides NAPT extension information in addition to the IP address information (IP address on the physical network and IP address on the virtual network) of the second VPN device 21 as the source address information of the NHRP resolution response. To get.

The first VPN device 11 that has acquired the global IP address port of the second VPN device 21 that is the destination spoke uses that information to create a dynamic virtual tunnel with the second VPN device 21. (S311).

At this time, the first VPN device 11 adds the route information of the virtual network. That is, the next hop to the second LAN 22 under the second VPN device 21 becomes the tunnel IP address on the virtual network of the second VPN device 21.

With the above operation, NHRP resolution is completed.

After the spoke-to-spoke tunnels of the first VPN device 11 and the second VPN device 21 are generated, routing is performed based on the route information of the second LAN 22 under the second VPN device 21 generated by the first VPN device 11. Will be done. Therefore, the data packet from the terminal of the first LAN 12 to the terminal of the second LAN 22 is directly transferred from the first VPN device 11 to the second VPN device 21.

This route information exists only while the information of the second VPN device 21 is alive. In the NHRP protocol, a survival time is provided in the spoke information of the other party so that the dynamically generated virtual tunnel is deleted when not in use.

(Communication device of the second embodiment)
Subsequently, the communication device of the second embodiment will be described with reference to FIG. 7.

FIG. 7 is a block diagram showing a configuration of a communication device according to a second embodiment of the present invention.

The communication device 200 shows the configurations of the first VPN device 11 and the second VPN device 21, which are spokes, shown in FIG.

The communication device 200 includes a LAN interface unit 230, a WAN interface unit 240, a communication control unit 210, and an external address / port information storage unit 220.

The LAN interface unit 230 is a functional unit that connects a LAN under the communication device 200 and transmits / receives packets to / from a terminal belonging to the LAN.

The WAN interface unit 240 is a functional unit that sends and receives packets to and from the Internet, and is connected to a gateway having a NAT function.

The communication control unit 210 has a function of relaying packets between the LAN interface unit 230 and the WAN interface unit 240, and is a functional unit that controls the VPN construction of the present embodiment.

The external address / port information storage unit 220 stores the global IP address / port and NAT type that are NAT-translated by the gateway to which the communication device is connected, which is acquired from the STUN server 71. It also stores the global IP address port and NAT type of the communication device that is the spoke of the other party acquired in the NHRP resolution response.

The communication control unit 210 is configured to include an external address / port information acquisition unit 211, an address resolution unit 212, and a tunnel generation unit 213 as functions for controlling the VPN construction of the present embodiment.

The external address / port information acquisition unit 211 includes the STUN application 2111 and acquires the global IP address / port and NAT type by accessing the STUN server 71. The acquired information is registered in the external address / port information storage unit 220 and notified to the address resolution unit 212.

Further, as will be described later, the external address / port information acquisition unit 211 periodically accesses the STUN server 71 to update and notify the acquired information. Further, the conversion process of the destination UDP port number used in the NAT traversal of IPsec is performed. This will also be described later.

The address resolution unit 212 has an NHRP protocol control function, and controls NHRP registration, NHRP registration response, NHRP traffic notification, NHRP resolution request, and NHRP resolution response.

When the address resolution unit 212 receives the notification of acquisition of the global IP address port and NAT type from the external address port information acquisition unit 211, the address resolution unit 212 adds the information as a NAPT extension to the extension unit of the NHRP registration and notifies the hub. ..

When the address resolution unit 212 receives an NHRP traffic notification from the hub during inter-spoke communication via the hub, the address resolution unit 212 adds global IP address port and NAT type information as a NAT extension to the extension unit of the NHRP resolution request to resolve the NHRP. Aim.

The address resolution unit 212 acquires the global IP address port and NAT type information included as the NAPT extension in the extension unit of the NHRP resolution response, and registers it in the external address port information storage unit as the information of the destination spoke.

The tunnel generation unit 213 controls the generation of a dynamic virtual tunnel. Further, the tunnel generation unit 213 includes a tunnel generation control unit 2131 that performs the control described later according to the NAT type when the virtual tunnel is generated.

The above configuration is a configuration related to the present embodiment, and the illustration and description of the configuration related to other functions (route information control, BGP, multipoint GRE, IPsec, etc.) for functioning as spokes of DMVPN are omitted. ..

The communication device 200 has been described as showing the configurations of the first VPN device 11 and the second VPN device 21 which are spokes. On the other hand, the third VPN device 31, which is a hub, shown in FIG. 5, controls NHRP registration and NHRP traffic notification in the present embodiment, as will be understood from the above description. Then, as a configuration required for that purpose, there is a function of generating mapping information based on the information acquired by NHRP registration and a function of determining whether or not to generate a dynamic virtual tunnel based on the generation of mapping information. The "mapping information" and "tunnel generation determination" of the third VPN device 31 shown in FIG. 5 correspond to those functions, and the detailed configuration as an individual communication device is not shown.

(Field configuration of NAPT extension)
Here, the NAPT extension added to the extension part of the NHRP protocol packet used in the present embodiment will be described.

FIG. 8 is a configuration diagram showing an extended field of the NHRP protocol packet.

In the NHRP protocol, a packet of an NHRP message consists of an essential part and an extension part. The extension allows the protocol to be added with its own definition. In the present embodiment, as a NAPT extension to the extension unit, as shown in FIG. 8, the global IP address and global port number of the source spoke that transmits the message and the NAT type of the NAT device to which the source spoke is connected are displayed. The indicated value is added.

As described above, in the present embodiment, information on each other's NAPT extensions is exchanged via the hub between the spokes installed under the NAT device through the NHRP address resolution. Therefore, the spoke that has sent the NHRP resolution request can know the global IP address, global port number, and NAT type of the spoke destination. In addition, in NHRP registration, each spoke notifies the hub of its own NAPT extension information, so the hub retains the global IP address, global port number and NAT type of each spoke in addition to the normal NHRP registration information. be able to.

(Operation of communication device)
Next, the operations of the communication device serving as a hub and the communication device serving as spokes will be described with reference to FIGS. 9 and 10.

FIG. 9 is a flow chart showing the operation of the hub.

FIG. 9 (1) shows the operation at the time of NHRP registration.

The hub receives the NHRP registration request from each spoke under its control (S401).

Then, the hub acquires the global IP address, global port number, and NAT type of each spoke from the NAPT extension added to the extended portion of the received NHRP registration request packet, and registers it in the mapping information associated with each spoke. (S402).

The hub that has performed the NHRP registration returns the NHRP registration response to the spokes (S403).

Further, FIG. 9 (2) shows an operation of determining whether or not to create an inter-spoke tunnel during inter-spoke communication.

The hub knows the occurrence of inter-spoke communication via the hub from the source spoke of the packet to the destination spoke (S411).

The hub identifies the NAT type of the NAT device to which the spokes of the source spoke and the spokes of the destination spoke are connected based on the mapping information generated by the NHRP registration described above (S412). Then, it is determined whether or not the dynamic virtual tunnel can be created based on the combination of these NAT types (S413).

The details of whether or not a dynamic virtual tunnel can be generated based on the combination of NAT types will be described later with reference to FIG. 12, but it is dynamic when the NAT type corresponding to both the source and destination spokes is symmetric NAT. It is determined that the virtual tunnel cannot be created. Further, it is determined that the dynamic virtual tunnel cannot be created even when the NAT type corresponding to one of the spokes of the source and the destination is the symmetric NAT and the other is the port restriction cone NAT.

When it is determined that the dynamic virtual tunnel can be created (S413, possible), the hub sends an NHRP traffic notification to the spokes of the source to instruct the spokes to create a virtual tunnel (S414). The NHRP traffic notification stores the IP address of the terminal on the private network under the destination spoke. Then, communication between the spokes via the hub is performed (S415). Inter-spoke communication via the hub in this case continues until the source spoke that receives the NHRP traffic notification creates a dynamic virtual tunnel with the destination spoke.

If it is determined that the dynamic virtual tunnel cannot be created (S413, impossible), the hub performs inter-spoke communication via the hub without transmitting the NHRP traffic notification (S415).

FIG. 10 is a flow chart showing the operation of the spokes.

FIG. 10 (1) shows an operation of acquiring external address / port information.

The spokes of this embodiment acquire external address / port information from a STUN server deployed on the Internet (S501). The external address / port information is a global IP address / port and NAT type that is the source address information after NAT translation attached to the packet transmitted from the spoke to the Internet. This operation is as described in step S301 and step S302 with reference to FIG.

The spoke that has acquired the external address / port information sends an NHRP registration request to the hub (S502). At this time, the NAT extension is added to the extension portion of the packet of the NHRP registration request. As explained with reference to FIG. 8, the NAPT extension is information including the global IP address, the global port number, and the NAT type acquired by the spoke. At this time, the acquired external address / port information is also registered in the external address / port information storage unit 220 shown in FIG. 7.

As described with reference to FIG. 9 (1), the NHRP registration request transmitted by the spokes is received at the hub. Then, the mapping information is registered in the hub, and the NHRP registration response is returned. The spoke receives this NHRP registration response and knows that the NHRP registration is complete (S503).

Further, (2) of FIG. 10 shows an operation of generating an inter-spoke tunnel.

First, the spokes request communication between the spokes via the hub (S511).

This operation is as described in step S306 with reference to FIG. That is, the data packet received from the terminal in the private network under the spoke is transferred to the other spoke via the hub according to the predetermined route information.

In this operation, the hub determines whether or not direct communication between the spokes is possible as described in step S413 of FIG. 9 (2), and the hub determined that communication between the spokes is possible NHRP with respect to the source spokes. Send traffic notifications. The spoke receives this NHRP traffic notification (S512).

The spoke that receives the NHRP traffic notification initiates address resolution to create a virtual tunnel with the other spoke.

The spoke sends an NHRP resolution request to a terminal of a private network under the destination spoke as a destination based on the address information included in the NHRP traffic notification (S513).

At this time, the NAPT extension of the spoke is added to the extension portion of the packet of the NHRP resolution request. The NAPT extension includes the global IP address, global port number and NAT type acquired by the spoke.

This NHRP resolution request is received at the destination spoke via the hub, and the NHRP resolution response is transmitted from the destination spoke.

The NAPT extension of the destination spoke is added to the extension of the packet of the NHRP resolution response. This NAPT extension includes the global IP address, global port number and NAT type acquired by the destination spoke.

The spoke receives this NHRP resolution response (S514).

The spoke acquires the IP address information of the destination spoke as the source address information of the NHRP resolution response, as well as the NAPT extension information including the global IP address, the global port number, and the NAT type acquired by the destination spoke. The acquired external address / port information of the destination spoke is also registered in the external address / port information storage unit 220 shown in FIG. 7.

The spoke creates a dynamic virtual tunnel with the destination spoke based on the acquired global IP address port of the destination spoke (S515).

At this time, the spoke adds the route information of the virtual network, and the next hop to the private network under the destination spoke is the tunnel IP address on the virtual network of the destination spoke.

Hereinafter, the characteristic functions of the communication device of the present embodiment will be described with reference to FIGS. 11 to 14.

As this characteristic function, the following four functions will be described in sequence.

Port number conversion control for NAT traversal IPsec packet transmission / reception, dynamic virtual tunnel creation availability by combination of NAT types, control operation according to NAT type on own device side / partner device side, and update of external address / port information motion.

(Port number conversion control in NAT traversal IPsec packet transmission / reception)
FIG. 11 is a sequence diagram showing port number conversion control in NAT traversal IPsec packet transmission / reception.

This function is executed by the STUN application 2111 of the external address / port information acquisition unit 211 described with reference to FIG. 7.

NAT traversal is a technique for passing a packet encrypted by IPsec through NAT. Since the data of the portion encapsulated by the ESP (Encapsulating Security Payload) header is encrypted in the packet encrypted by IPsec, NAT cannot read the port number from the packet encrypted by IPsec. Therefore, as NAT traversal, the packet encapsulated in the ESP header is encapsulated in the UDP dummy header, and the packet to which the IP header for transfer is added is generated and transferred. Port number 4500 is used for IPsec packets that use this NAT traversal.

Since the port number of the IPsec packet using NAT traversal is defined in this way, the port number conversion process is required when acquiring the external address / port information by the STUN protocol.

What we want to obtain with the STUN protocol is the global IP address and global port number of the NAT device entry used when IPsec packets using NAT traversal pass through the NAT device.

When using NAT traversal, the source port number is 4500.

In order to obtain the global IP address and port number used by DMVPN, the STUN application 2111 needs to query the STUN server with the source port number 4500. However, port 4500 is defined for NAT traversal and cannot be used with the STUN protocol.

Therefore, the STUN application 2111 uses an arbitrary port number for which the purpose is not defined as a dummy port number, and makes an inquiry to the STUN server.

This function will be described with reference to FIG.

The STUN application 2111 sets the dummy port number as the source port number (S601) and sends a STUN request message to the STUN server (S602).

At this time, in the gateway (NAT device), the private IP address of the spoke, which is the source address of the message, and the dummy port number are NAT-translated into the global IP address and the global port number. That is, an entry for associating the spoke private IP address, the dummy port number, the NAT-translated global IP address, and the global port number is generated (S603).

The STUN server sends a STUN response message including a NAT-translated global IP address and a global port number to the NAT-translated global IP address and the global port number as a destination. This STUN response message is received at the gateway. Based on the entry generated when the STUN request message passes, the gateway translates the destination into the private IP address and dummy port number of the spoke and forwards the STUN response message (S604).

This STUN response message is received by the spoke STUN application 2111.

Further, when transmitting / receiving NAT traversal IPsec packets, the following processing is executed.

When the spokes transmit a NAT traversal IPsec packet, the transmitted packet is once passed to STUN application 2111. Then, in STUN application 2111, the source port number of the transmission packet is converted into a dummy port number before transmission (S605, S606).

When passing through the gateway, the NAT traversal IPsec packet is NAT-translated from the private IP address of the spoke and the dummy port number to the global IP address and the global port number.

On the other hand, when receiving a NAT traversal IPsec packet, the gateway NAT-translates the destination into a spoke private IP address and a dummy port number (S607). That is, the NAT traversal IPsec packet is once received by the STUN application 2111.

The STUN application 2111 confirms that the source IP address of the received NAT traversal IPsec packet does not belong to the STUN server, converts the destination port number to 4500, and outputs the packet (S608).

A NAT traversal IPsec packet with the destination port number set to 4500 is received (S609).

As described above, the port number conversion process for the NAT traversal IPsec packet is performed.

(Whether or not a dynamic virtual tunnel can be created by combining NAT types)
When dynamically creating a virtual tunnel between spokes, the combination of NAT types corresponding to each spoke may make it impossible to generate a tunnel or may be restricted.

FIG. 12 is a diagram showing the correspondence between whether or not a dynamic virtual tunnel can be generated by combining NAT types.

FIG. 12 shows whether or not a tunnel can be generated with a matrix corresponding to each of the source spoke and the destination spoke according to the NAT type.

In the case of full-cone NAT, both the source spoke and the destination spoke are displayed as "○", and dynamic virtual tunnels can be generated without limitation.

If either the source spoke or the destination spoke is a full-cone NAT and the other spoke is an address-restricted cone NAT or a port-restricted cone NAT, "△ 1" is displayed and control for creating communication results must be performed. .. This will be described later with reference to FIG.

Even when the combination of the NAT type of the source spoke and the destination spoke is the address restriction cone NAT and the port restriction cone NAT, it is necessary to perform control for creating a communication record by displaying "Δ1".

If either the source spoke or the destination spoke is a symmetric NAT, and the other spoke is a full-cone NAT or an address-restricted-cone NAT, "△ 2" is displayed, and the control for creating communication results and the symmetric NAT side Control of global port number acquisition is required. This will also be described later with reference to FIG.

If either the source spoke or the destination spoke is Symmetric NAT, and the other spoke is Port Restriction Cone NAT or Symmetric NAT, an "x" is displayed and a dynamic virtual tunnel cannot be created.

In symmetric NAT, if the destinations outside the NAT are different, the NAT device will generate entries with global port numbers that differ by the number of destinations. Therefore, the spokes under the port restriction cone NAT device cannot acquire the global port number on the symmetric NAT side, and cannot create the communication record to the global IP address and port number of the symmetric NAT device.

As described above, the hub recognizes which NAT type NAT device the subordinate spokes are behind by the NAPT extension added to the NHRP registration request notified from each spoke in the NHRP registration. Then, when transferring a data packet from spoke to spoke, the hub refers to the NAT type corresponding to each spoke to determine whether or not the combination of NAT types can generate a dynamic virtual tunnel. Therefore, the hub does not send NHRP traffic notifications when it is a combination of NAT types that cannot generate a dynamic virtual tunnel.

In addition, for each spoke, the NAT type corresponding to the other spoke is acquired through NHRP resolution.

(Control operation according to the NAT type on the own device side / partner device side)
As explained with reference to FIG. 12, control for creating a communication record and control for acquiring a global port number on the symmetric NAT side are required according to the combination of NAT types on the source spoke side and the destination spoke side. It becomes.

FIG. 13 is a flow chart showing a control operation of the spokes according to the NAT type on the own device side and the NAT type on the other device side. This control is executed by the tunnel generation control unit 2131 of the communication device 200 shown in FIG. 7. The tunnel generation control unit 2131 refers to the external address / port information of the own device registered in the external address / port information storage unit 220 and the external address / port information of the other device acquired through NHRP resolution. The external address / port information includes the NAT type.

FIG. 13 (1) is a control for creating a communication record, and is an operation flow in the case of “Δ1” display in FIG.

First, the NAT type on the own device side is identified (S701).

It is determined whether or not the NAT type on the own device side is a full cone NAT (S702).

When the NAT type on the own device side is a full-cone NAT (S702, Yes), no special preparation is required to generate a dynamic virtual tunnel between the spokes.

When the NAT type on the own device side is not a full-cone NAT (S702, No), control is performed to create a communication record for the NAT device to which the own device is connected before creating a dynamic virtual tunnel between the spokes. .. The case where the NAT type is not a full cone NAT is a case where the NAT type is any one of an address limiting cone NAT, a port limiting cone NAT, and a symmetric NAT.

In the case of a NAT type other than full-cone NAT, the NAT device allows only packets from a partner device with a communication record to pass inside the NAT device. "Communication record" means that the destination of the global IP address port that has transmitted the packet over the Internet beyond the NAT device remains as an entry.

Therefore, a dummy UDP packet is transmitted in order to create the communication record (S703).

The dummy UDP packet is a UDP packet without a payload, which is set with the global IP address port of the remote device acquired by NHRP resolution as the destination.

That is, after receiving the NHRP resolution response, the transmitting spoke that has transmitted the NHRP resolution request transmits this dummy UDP packet when the NAT type on the own device side is other than full-cone NAT. Further, after receiving the NHRP resolution request, the receiving side spoke that has received the NHRP resolution request transmits this dummy UDP packet when the NAT type on the own device side is other than the full cone NAT.

This dummy UDP packet is transmitted a plurality of times until a similar dummy UDP packet from the other device is received. When the spoke under the NAT device of the full cone NAT receives this dummy UDP packet, the same dummy UDP packet is transmitted to the other spoke in order to notify that the dummy UDP packet has been received.

As a result of the above, the NAT device to which both spokes are connected has a record of communication with the spoke of the other party.

After receiving the dummy UDP packet from the other spoke, communication is performed between the spokes for creating a dynamic virtual tunnel.

Next, control when the NAT type on the other device side is symmetric NAT will be described.

FIG. 13 (2) is a control for acquiring the global port number of the remote device, and is an operation flow related to “acquisition of the global port number on the symmetric NAT side” displayed by “Δ2” in FIG.

First, the NAT type on the other device side is identified (S711). The NAT type on the other device side is acquired through NHRP resolution.

It is determined whether or not the NAT type on the other device side is symmetric NAT (S712).

When the NAT type on the other device side is not symmetric NAT (S712, No), the NAT type on the own device side is any one of full cone NAT, address restriction cone NAT, port restriction near NAT, and symmetric NAT. Then, the control described with reference to FIG. 13 (1) is performed.

Further, in this case, the external address port acquired through NHRP resolution is used as the other party's external address port (S714). That is, the transmitting spoke that sent the NHRP resolution request uses the external address port included in the received NHRP resolution response, and the receiving spoke that received the NHRP resolution request uses the external address port included in the received NHRP resolution request. To use.

On the other hand, when the NAT type on the other device side is symmetric NAT (S712, Yes), the following processing is performed.

In this case, if the NAT type on the own device side is a symmetric NAT or a port limiting cone NAT, the NHRP traffic notification from the hub is not received, so this control does not apply. That is, this case is applied only when the NAT type on the own device side is a full cone NAT or an address limiting cone NAT.

Even for spokes under the NAT device of Symmetric NAT, the NAPT extension information added to the NHRP message packet transmitted by the spokes is the global IP address / port information acquired by communicating with the STUN server. However, the spoke (for example, spoke B) that is the destination of the spoke (for example, spoke A) under the NAT device of Symmetric NAT has a global IP address that the spoke A uses when communicating with the spoke B. You need to use the port.

That is, when the NAT type on the other device side is symmetric NAT, the external address / port information acquired through NHRP resolution cannot be used.

As described with reference to FIG. 13 (1), even if the NAT type on the own device side is symmetric NAT, the above-mentioned dummy UDP packet is transmitted. Therefore, in FIG. 13 (2), in the case of steps S712 and Yes, the source address of the dummy UDP packet transmitted by the remote device under the NAT device of the symmetric NAT may be used. That is, the source address of this dummy UDP packet is set to the global IP address port that has been NAT-translated by the NAT device of the symmetric NAT and has a communication record.

Therefore, in step S713, a process of using the source address / port information of the dummy UDP packet received from the other party device as the other party's external address / port information is performed.

The NAT type on the own device side is the address restriction cone NAT, and when the above-mentioned dummy UDP packet is transmitted, the processing is performed as follows. First, until a dummy UDP packet is received from the other device side under the NAT device of Symmetric NAT, the external address port acquired through NHRP resolution is set as the destination of the dummy UDP packet transmitted by the own device. Then, when the dummy UDP packet transmitted by the remote device is received, the destination of the dummy UDP packet transmitted by the own device is changed to the port number set as the source address of the received dummy UDP packet and transmitted.

(Update operation of external address / port information)
Since the entry of the NAT translation rule generated by the NAT device is not unique, it has a function of detecting the entry change of the NAT device.

That is, in the tunnel between the spokes and the hub or the tunnel between the spokes, it is necessary to always keep the information of the global IP address port of the NAT device to which the spokes are connected up-to-date.

FIG. 14 is a flow chart showing an operation of updating external address / port information in the spokes.

This operation is an operation executed by the communication control unit 210 of the communication device 200 of FIG. 7, and is executed in cooperation with the external address / port information acquisition unit 211, the address resolution unit 212, and the tunnel generation unit 213.

First, the external address / port information acquisition unit 211 accesses the STUN server at a predetermined timing and periodically acquires the external address / port information from the STUN server (S801). Then, it is determined whether or not the acquired external address / port information has been changed (S802).

If there is no change in the external address / port information in this determination operation (S802, No), the process returns to step S801, and the STUN server is accessed again at the next timing.

On the other hand, when the acquired external address / port information is changed (S802, Yes), the external address / port information acquisition unit 211 uses the external address of its own device registered in the external address / port information storage unit 220. Update port information. At the same time, the external address / port information acquisition unit 211 notifies the address resolution unit 212 and the tunnel generation unit 213 that the external address / port information has been updated.

Upon learning that the external address / port information has been updated, the address resolution unit 212 immediately sends an NHRP registration request to the hub with the updated external address / port information added as a NAT extension (S804).

Further, when the tunnel generation unit 213 learns that the external address / port information has been updated, it transmits a dummy UDP packet with the updated external address / port as the source address to the spokes of the other party (S805). Note that this dummy UDP packet is the same as the packet transmitted for creating the communication record in NAT as described above, and is a UDP packet without a payload. This dummy UDP packet is periodically transmitted while the spoke information of the other party is alive.

By the above operation, the hub updates the external address / port information of the source spoke based on the NAT extension added to the newly received NHRP registration request. Further, the spoke of the other party receiving the dummy UDP packet whose source address has been changed updates the external address port of the source spoke based on the information of the source address.

As described above, in the present embodiment, the spokes acquire the information of the global IP address / port NAT-translated by the gateway, which is a NAT device, from the STUN server. Then, a global IP address, a global port number, and a NAT type can be added to the extended portion of the packet of the NHRP protocol as a NAPT extension to notify the spokes.

Therefore, in an environment where the spokes on the DMVPN are under the control of the NAT device, the acquired global IP address / port after NAT translation can be notified between the spokes, and a virtual tunnel can be dynamically generated.

In addition, a part or all of the above-described embodiment may be described as in the following appendix, but is not limited to the following.
(Appendix 1) It functions as a spoke that constitutes DMVPN (Dynamic Multipoint Virtual Private Network), and is installed under a relay device that performs NAT (Network Address Translation) address translation of packets sent and received between networks in different address spaces. The external address / port information from an address information providing device having a function of returning external address / port information which is address information that can be accessed from the address space outside the relay device generated by the NAT address translation. The first communication device and the second communication device, which are at least two communication devices, are transmitted by including the external address / port information in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN. Communication device and
The external address / port information included in the NHRP registration packet received from each of the first communication device and the second communication device under the control function as a hub constituting the DMVPN is used as the first communication device. And a third communication device registered in the mapping information associated with each of the second communication devices.
The third communication device is used in communication from the first communication device, which is the spoke of the packet transmission source, to the second communication device, which is the spoke of the packet transmission destination, via the third communication device. When it is detected based on the mapping information that a virtual tunnel can be generated between the first communication device and the second communication device, the virtual tunnel is generated for the first communication device. The first communication device, which has been instructed to generate the virtual tunnel by the third communication device, sets the extension field of the NHRP resolution request packet used in the DMVPN to the said first communication device. The second communication device that transmits including the external address / port information and receives the NHRP resolution request packet from the first communication device has the second communication device in the extended field of the NHRP resolution response packet used by the DMVPN. The first communication device that replied including the external address / port information of the communication device and received the NHRP resolution response packet is the external address of the second communication device included in the NHRP resolution response packet. A communication system characterized in that the virtual tunnel is generated between the second communication device and the second communication device based on the port information.
(Appendix 2) The external address / port information includes the NAT type of the relay device, and the third communication device includes the NAT type of the relay device to which the first communication device is connected and the second communication. Addendum 1 characterized in that it is determined whether or not the virtual tunnel can be generated between the first communication device and the second communication device according to the combination of NAT types of the relay device to which the device is connected. The communication system described in.
(Appendix 3) The NAT type includes a full cone NAT, an address limiting cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. The third communication device includes a port limiting cone NAT and a symmetric NAT, and the third communication device includes a NAT type of the relay device to which the first communication device is connected and a NAT type of the relay device to which the second communication device is connected. The communication system according to Appendix 2, wherein it is determined that the virtual tunnel cannot be generated when the combination of the above is the symmetric NAT and the port limiting cone NAT, and when both are the symmetric NAT. ..
(Appendix 4) The NAT type includes a full cone NAT, an address limiting cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. Each of the first communication device and the second communication device includes a port restriction cone NAT and a symmetric NAT, and the NAT type of the relay device to which the own device is connected is the address restriction cone NAT and the port restriction. In the case of either the cone NAT or the symmetric NAT, a dummy UDP (User Datagram Protocol) packet destined for the external address port of the communication partner device is transmitted before the virtual tunnel is generated, and the above is performed. The communication system according to Appendix 2, wherein an entry for NAT address translation relating to the communication partner device is generated in advance.
(Appendix 5) Each of the first communication device and the second communication device receives from the communication partner device when the NAT type of the relay device to which the communication partner device is connected is the symmetric NAT. The communication system according to Appendix 4, wherein the source address port of the dummy UDP packet is used as an external address port of the communication destination device.
(Appendix 6) Each of the first communication device and the second communication device acquires the external address / port information from the address information providing device at a predetermined timing, and the acquired external address / port information is obtained. If it has been updated, the updated external address / port information is included in the extended field of the NHRP registration packet and notified to the third communication device, according to any one of Appendix 1 to 5. Communication system.
(Appendix 7) Each of the first communication device and the second communication device is updated when the external address / port information acquired from the address information providing device at a predetermined timing is updated. The description in Appendix 6 is characterized in that a dummy UDP (User Datagram Protocol) packet in which the address port is set as the source address port is transmitted to the communication partner device to notify the change of the external address port of the own device. Communication system.
(Appendix 8) Access from the address space outside the relay device generated by the NAT address translation via a relay device that performs NAT (Network Address Translation) address translation of packets sent and received between networks in different address spaces. An external address / port information acquisition means for acquiring the external address / port information from an address information providing device having a function of returning external address / port information which is possible address information.
The external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in DMVPN (Dynamic Multipoint Virtual Private Network) and transmitted to the DMVPNN hub, and the hub is transmitted via the hub. In inter-spoke communication, when notified that a virtual tunnel can be created with the other party's spoke, the other party includes the external address / port information in the extended field of the NHRP resolution request packet used in the DMVPN. Address resolution to acquire the external address / port information of the destination spoke from the extended field of the NHRP resolution response packet used in the DMVPN sent to the destination spoke and returned by the destination spoke that received the NHRP resolution request packet. Means and
A communication device including a tunnel generating means for generating the virtual tunnel with the spokes based on the external address / port information of the spokes acquired by the address resolving means.
(Appendix 9) The external address / port information includes the NAT type of the relay device, and the address resolution means is derived from the external address / port information of the destination spoke included in the extended field of the NHRP resolution response packet. , Acquire the NAT type of the relay device to which the spokes of the other party are connected.
The tunnel generation means is characterized by including a tunnel generation control unit that performs tunnel generation preparation control according to the NAT type of the relay device to which the own device is connected and the NAT type of the relay device to which the partner spoke is connected. The communication device according to Appendix 8.
(Appendix 10) The NAT type includes a full cone NAT, an address limiting cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. The tunnel generation control unit includes a port limiting cone NAT and a symmetric NAT, and the NAT type of the relay device to which the own device is connected is one of the address limiting cone NAT, the port limiting cone NAT, and the symmetric NAT. In some cases, before creating the virtual tunnel, a dummy UDP (User Datagram Protocol) packet destined for the external address port of the destination spoke is sent to make an entry for the NAT address translation for the destination spoke. The communication device according to Appendix 9, wherein the communication device is generated in advance.
(Appendix 11) When the NAT type of the relay device to which the destination spoke is connected is the symmetric NAT, the tunnel generation control unit determines the source address port of the dummy UDP packet received from the destination spoke. The communication device according to Appendix 10, wherein the communication device is used as an external address port of the spoke to the other party.
(Appendix 12) The external address / port information acquisition means acquires the external address / port information from the address information providing device at a predetermined timing, and when the acquired external address / port information is updated, the external The communication device according to any one of Supplementary Provisions 8 to 11, wherein an update notification of address / port information is output.
(Appendix 13) The address resolving means includes the updated external address / port information in the extended field of the NHRP registration packet based on the update notification output by the external address / port information acquisition means, and the hub. 12. The communication device according to Appendix 12, wherein the communication device is notified to the user.
(Appendix 14) The tunnel generation control unit sets a dummy UDP (User Datagram) in which an updated external address port is set as a source address port based on the update notification output by the external address / port information acquisition means. Protocol) The communication device according to Appendix 12 or Appendix 13, wherein a packet is transmitted to the spokes of the other party to notify the change of the external address / port of the own device.
(Appendix 15) The external address / port information acquisition means generates a NAT address conversion entry using an arbitrary port number whose purpose is not defined as a dummy port number, and generates a NAT address conversion entry for an IPsec (Internet Protocol security) packet of NAT traversal. At the time of transmission, the source of the IPsec packet is converted from the port number specified in the IPsec packet to the dummy port number and transmitted, and when the IPsec packet destined for the dummy port number is received, the received IPsec is received. The communication device according to any one of Supplementary Provisions 8 to 14, further comprising a port number conversion means for converting a destination port number of a packet into a port number specified in the IPsec packet and outputting the packet.
(Appendix 16) It functions as a spoke that constitutes DMVPN (Dynamic Multipoint Virtual Private Network), and is installed under a relay device that performs NAT (Network Address Translation) address translation of packets sent and received between networks in different address spaces. At least two communication devices that acquire the external address / port information from an address information providing device having a function of returning external address / port information which is address information that can be accessed from the address space outside the relay device. Each of the first communication device and the second communication device transmits the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN including the external address / port information.
The third communication device that functions as a hub constituting the DMVPN receives the external address / port information included in the NHRP registration packet received from each of the first communication device and the second communication device under the control. Registered in the mapping information associated with each of the first communication device and the second communication device,
In communication from the first communication device, which is the spoke of the packet transmission source via the third communication device, to the second communication device, which is the spoke of the packet transmission destination, the third communication device is used. When it is detected based on the mapping information that a virtual tunnel can be generated between the first communication device and the second communication device, the virtual tunnel is generated for the first communication device. Instruct,
The first communication device, which has been instructed to generate the virtual tunnel by the third communication device, has the external address port of the first communication device in the extended field of the NHRP resolution request packet used in the DMVPN. Send with information,
The second communication device that has received the NHRP resolution request packet from the first communication device sets the external address / port information of the second communication device in the extended field of the NHRP resolution response packet used in the DMVPN. Reply including
The first communication device that has received the NHRP resolution response packet communicates with the second communication device based on the external address / port information of the second communication device included in the NHRP resolution response packet. A VPN construction method characterized by generating the virtual tunnel.
(Appendix 17) The external address / port information includes the NAT type of the relay device, and the third communication device includes the NAT type of the relay device to which the first communication device is connected and the second communication device. 16. The appendix 16 is characterized in that it is determined whether or not the virtual tunnel can be generated between the first communication device and the second communication device according to the combination of NAT types of the relay devices connected to the device. VPN construction method.
(Appendix 18) The NAT type includes a full cone NAT, an address limiting cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. The third communication device includes a port limiting cone NAT and a symmetric NAT, and the third communication device is a combination of the NAT type of the relay device to which the first communication device is connected and the NAT type of the relay device to which the second communication device is connected. The VPN construction method according to Appendix 17, wherein it is determined that the virtual tunnel cannot be generated when is a symmetric NAT and a port limiting cone NAT, and both are symmetric NAT.
(Appendix 19) The NAT type includes a full cone NAT, an address limiting cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. Each of the first communication device and the second communication device includes a port restriction cone NAT and a symmetric NAT, and the NAT type of the relay device to which the own device is connected is the address restriction cone NAT and the port restriction. In the case of either the cone NAT or the symmetric NAT, a dummy UDP (User Datagram Protocol) packet destined for the external address port of the communication partner device is transmitted before the virtual tunnel is generated, and the above is performed. The VPN construction method according to Appendix 17, wherein an entry for NAT address translation relating to a communication partner device is generated in advance.
(Appendix 20) Each of the first communication device and the second communication device receives from the communication partner device when the NAT type of the relay device to which the communication partner device is connected is the symmetric NAT. The VPN construction method according to Appendix 19, wherein the source address port of the dummy UDP packet is used as an external address port of the communication destination device.
(Appendix 21) Each of the first communication device and the second communication device acquires the external address / port information from the address information providing device at a predetermined timing, and the acquired external address / port information is obtained. If it has been updated, the updated external address / port information is included in the extended field of the NHRP registration packet and notified to the third communication device in the appendix to any one of the appendices 16 to 20. The VPN construction method described.
(Appendix 22) When the external address / port information acquired from the address information providing device at a predetermined timing is updated, each of the first communication device and the second communication device is updated externally. The description in Appendix 21 is characterized in that a dummy UDP (User Datagram Protocol) packet in which the address port is set as the source address port is transmitted to the communication partner device to notify the change of the external address port of the own device. How to build a VPN.
(Appendix 23) Access from the address space outside the relay device generated by the NAT address translation via a relay device that performs NAT (Network Address Translation) address translation of packets sent and received between networks in different address spaces. The external address / port information is acquired from an address information providing device having a function of returning external address / port information which is possible address information.
The external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN (Dynamic Multipoint Virtual Private Network) and transmitted to the hub of the DMVPN.
When the hub notifies that a virtual tunnel can be created between the spokes and the spokes in the inter-spoke communication via the hub, the external field of the NHRP resolution request packet used in the DMVPN is displayed. Send it to the spokes including the address and port information,
The external address / port information of the destination spoke is acquired from the extended field of the NHRP resolution response packet used in the DMVPN returned by the destination spoke that has received the NHRP resolution request packet.
A VPN construction method characterized in that a virtual tunnel is generated between the spokes of the other party and the spokes of the other party based on the acquired external address / port information of the spokes of the other party.
(Appendix 24) The external address / port information includes the NAT type of the relay device.
The NAT type of the relay device to which the destination spoke is connected is acquired from the external address / port information of the destination spoke included in the extended field of the NHRP resolution response packet returned by the destination spoke.
The VPN construction method according to Appendix 23, wherein tunnel generation preparation control is performed according to the NAT type of the relay device to which the own device is connected and the NAT type of the relay device to which the destination spoke is connected.
(Appendix 25) The NAT type includes a full cone NAT, an address restriction cone NAT, which is a type corresponding to access restrictions from the address space outside the relay device to the external address port generated by the NAT address translation. Includes port limiting cone NAT and symmetric NAT
When the NAT type of the relay device to which the own device is connected is any of the address limiting cone NAT, the port limiting cone NAT, and the symmetric NAT, the outside of the destination spoke before the virtual tunnel is generated. The VPN construction method according to Appendix 24, wherein a dummy UDP (User Datagram Protocol) packet destined for an address port is transmitted to generate an entry for the NAT address translation for the destination spoke in advance.
(Appendix 26) When the NAT type of the relay device to which the destination spoke is connected is the symmetric NAT, the source address port of the dummy UDP packet received from the destination spoke is the external address of the destination spoke. -The VPN construction method according to Appendix 25, which is characterized in that it is used as a port.
(Appendix 27) The external address / port information is acquired from the address information providing device at a predetermined timing, and when the acquired external address / port information is updated, an update notification of the external address / port information is output. The VPN construction method according to any one of Appendix 23 to 26, wherein the VPN construction method is performed.
(Supplementary Note 28) The VPN construction method according to Supplementary note 27, wherein the updated external address / port information is included in an extended field of the NHRP registration packet and notified to the hub based on the update notification.
(Appendix 29) Based on the update notification, a dummy UDP (User Datagram Protocol) packet in which the updated external address port is set as the source address port is transmitted to the destination spoke to obtain the external address of the own device. The VPN construction method according to Appendix 27 or Appendix 28, which comprises notifying a port change.
(Appendix 30) When a NAT address conversion entry is generated using an arbitrary port number for which the purpose is not defined as a dummy port number and an IPsec (Internet Protocol security) packet for NAT traversal is transmitted, the source of the IPsec packet is transmitted. Is converted from the port number specified in the IPsec packet to the dummy port number and transmitted, and when the IPsec packet destined for the dummy port number is received, the destination port number of the received IPsec packet is converted into the IPsec packet. The method for constructing an IPSec according to any one of Appendix 23 to 29, which comprises converting to a specified port number and outputting.

1, 2 communication system 10 1st communication device 11 1st VPN device 12 1st LAN
20 Second communication device 21 Second VPN device 22 Second LAN
30 3rd communication device 31 3rd VPN device 40 1st relay device 41 1st gateway 50 2nd relay device 51 2nd gateway 60 Wide area network 61 1st private network 62 2nd private network 63 3rd Private network 65 Internet 70 Address information provider 71 STUN server 100, 200 Communication device 110 External address / port information acquisition means 120 Address resolution means 130 Tunnel generation means 210 Communication control unit 211 External address / port information acquisition unit 2111 STUN application 212 Address Solution 213 Tunnel generation unit 2131 Tunnel generation control unit 220 External address / port information storage unit 230 LAN interface unit 240 WAN interface unit

Claims (1)

For communication equipment
It is possible to access from the address space outside the relay device generated by the NAT address translation via a relay device that performs NAT (Network Address Translation) address translation of packets sent and received between networks in different address spaces. The external address / port information is acquired from an address information providing device having a function of returning the external address / port information which is the address information.
The external address / port information is included in the extended field of the NHRP (Next Hop Resolution Protocol) registration packet used in the DMVPN (Dynamic Multipoint Virtual Private Network) and transmitted to the hub of the DMVPN.
When the hub notifies that a virtual tunnel can be created between the spokes and the spokes in the inter-spoke communication via the hub, the external field of the NHRP resolution request packet used in the DMVPN is displayed. Send it to the spokes including the address and port information,
The external address / port information of the destination spoke is acquired from the extended field of the NHRP resolution response packet used in the DMVPN returned by the destination spoke that has received the NHRP resolution request packet.
Based on the acquired external address / port information of the destination spoke, the virtual tunnel is generated with the destination spoke.
A VPN construction program for executing processing
The external address / port information includes the NAT type of the relay device.
The NAT type of the relay device to which the destination spoke is connected is acquired from the external address / port information of the destination spoke included in the extended field of the NHRP resolution response packet returned by the destination spoke.
Performs tunnel generation preparation control according to the NAT type of the relay device to which the own device is connected and the NAT type of the relay device to which the destination spoke is connected.
VPN construction program to execute processing.

Images