JP5535757B2 - Client device and program - Google Patents

Description

  The present invention relates to a tunneling technique in a communication network.

  Firewall devices (including NAT devices) are generally installed between private networks such as corporate networks and home networks and external networks such as the Internet to ensure communication security. is there.

  In such a firewall device, a protocol for permitting communication is set according to a network management policy. For example, in many cases, HTTP / HTTPS communication related to a request from a client device in a private network is allowed. ing.

  Therefore, in order to perform communications such as IP phone calls and video conferencing between a client device in a private network and an external device, the target communication is performed using a protocol header that allows communication such as HTTP. A tunneling technique is used in which a tunnel, which is a virtual communication path, is formed by encapsulating these packets, and communication for a purpose such as an IP phone or video conference is performed through the tunnel.

  In general, in the tunneling technology, communication is performed by forming a tunnel between a client device having a tunneling function and a tunnel server device installed in an external network.

  Here, there is a library system as shown in FIG. 1 as one of conventional techniques for making a client device (PC or the like) compatible with tunneling. In this method, software for performing tunneling processing is provided as a library, and an application corresponding to the tunneling library is provided.

  In addition, as another conventional technique for making a client device tunnel-capable, as shown in FIG. 2, a virtual network interface is provided on the OS, and an IP address is assigned to the virtual network interface. There is also a method of making the part that communicates via the tunneling via tunneling. In this method, the virtual network interface operates as if it exists on a remote network where the tunneling server exists. In addition, there exists patent document 1 as one of the prior art documents relevant to this application.

JP 2008-187686 A

  However, in the above-described library method in the prior art, it is necessary to modify the application to be used. Further, the method of providing a virtual network interface may cause problems in terms of address consumption and security. More details are as follows.

  When tunneling is realized by the library method, it is necessary to modify the application for the socket API portion of the application. In addition, when trying to simulate a socket API such as TCP, it is necessary to perform protocol processing on the library side, and compatibility problems with the protocol processing originally possessed by the application may affect the operation of the application. There was sex. In addition, when attempting to remodel an application to support tunneling, if there is no source code, such as when an object such as a library created by a third party is used, the remodeling is difficult in the first place.

  In addition, in the method of creating a virtual network interface and tunneling by routing packets, basically all packets communicate with each other, which may cause a security problem. Furthermore, there has been a problem that the occurrence rate of troubles such as complication of routing setting between a plurality of interfaces due to the creation of a virtual network interface or a communication failure resulting from the complexity increases. In general, since a global address is assigned to a virtual interface because it is responsible for external communication, a valuable global address is assigned to one client in an environment where the address space is limited as in IPv4. There is also a problem of occupying one.

  By the way, when transmitting data through the tunnel, a control packet and a packet with a header for distinguishing the data packet are transmitted through the tunnel, and on the receiving side, the packet type is determined from the header and reception processing is performed. There are conventional techniques. In such a conventional technique, when a received packet is damaged, the packet is skipped to the next header, and reception processing is performed on the next packet.

  However, in such a conventional technique, in order to be able to identify the next header in arbitrary data, the header must be sized to a certain size, resulting in a large communication overhead. There was a problem of becoming.

  Also, when performing communication using tunneling, the function of the firewall device may cause a forced disconnection when there is no communication for a long time, or the signal will not communicate even if the disconnection state does not occur. The so-called tunnel may be clogged. In order to avoid such a situation, transmission / reception of a survival confirmation request / survival confirmation request response is generally performed at regular time intervals between the client apparatus and the tunnel server apparatus.

  However, in such a communication confirmation technology, if the transmission interval of the survival confirmation request is short, useless packets other than the original communication packet increase, and a tunnel server device in which traffic of many clients including non-communication clients concentrates. In the network, the processing load increases, and there is a risk of performance degradation. Conversely, if the transmission interval is lengthened, the clogged state cannot be detected for a long time, causing a problem that communication is interrupted for a long time. That is, it has been difficult to satisfy the conflicting conditions of reducing the processing load and shortening the abnormal state detection time at the same time by adjusting the transmission cycle of the survival confirmation request.

  The present invention has been made in view of the above-described problems, and an object of the present invention is to provide a technique that enables a client device to have a tunneling function without almost modifying an application.

  Another object of the present invention is to provide a technique for realizing efficient communication by shortening a header attached to a packet. Furthermore, another object of the present invention is to provide a survival confirmation technique that makes it possible to satisfy the conflicting conditions of reducing the processing burden and shortening the abnormal state detection time.

  In order to solve the above-described problem, the present invention provides a client device that performs data communication with a communication partner device via a tunnel established between the tunnel server device and the tunnel server device. The tunnel function means for constructing the tunnel and transmitting / receiving packets via the tunnel, the data communication means for performing data transmission / reception via a communication network, and monitoring the packets passing through the data communication means, A packet control means for passing the packet to the tunnel function means when it is determined that the packet is a packet output from an application unit included in the client device based on the communication information of the packet; Means for transmitting the packet received from the packet control means to the tunnel; Configured as a client device, characterized in that via transmitted toward the communication counterpart apparatus.

  In the client device, the packet control means receives a packet received via the tunnel from the tunnel function means, and sends the packet to the application unit via the data communication means.

  The packet received by the tunnel function means via the tunnel has a header, and the tunnel function means determines whether or not the packet is damaged based on the information of the header, When it is determined that the packet is damaged, it is possible to provide a damage processing means for disconnecting the tunnel and then reconstructing the tunnel with the tunnel server device.

  The tunnel function means receives a server address and a server port number, which are the address and port number of the tunnel server device, from the tunnel server device, and corresponds the server address and server port number to the application unit. When a packet including the client port number as an outgoing port number is received from the packet control unit in association with a client port number, the source address in the packet is referred to by referring to the storage unit May be converted into the server address, the source port number in the packet is converted into the server port number, and the converted packet may be transmitted via the tunnel.

  Further, when the tunnel function means receives a packet including the server address as a destination address and the server port number as a destination port number via the tunnel, by referring to the storage means, The destination address in the packet is converted into the address of the client device, the destination port number in the packet is converted into the client port number, and the converted packet is sent to the application unit via the packet control means You may comprise.

  Further, each time the tunnel server device receives a packet from the client device, the tunnel server device holds the reception time of the packet as a final reception time in the storage unit, and when transmitting a data packet, the transmission time of the data packet The elapsed time from the last reception time may be calculated and the elapsed time may be included in the data packet and transmitted as the server-side elapsed time. In this case, the tunnel function means sends the packet to the tunnel server device. Each time transmission is performed, the transmission time of the packet is held in the storage unit as the final transmission time, and when the data packet is received from the tunnel server device, the elapsed time of the reception time of the data packet from the final transmission time The time is calculated as the client side elapsed time, and the server side time obtained from the data packet is calculated. Time, on the basis of the said client-side elapsed time, may be configured to determine whether to transmit a presence confirmation request to the tunnel server.

  In the above configuration, when the client side elapsed time is equal to or longer than a predetermined time, the tunnel function means transmits a survival confirmation request when the server side elapsed time is larger than the client side elapsed time. If the client-side elapsed time is less than the predetermined time, the server-side elapsed time is greater than or equal to a predetermined number of average transmission intervals calculated from the packet transmission time. A request may be sent.

  The predetermined time is, for example, twice the round trip time between the client device and the tunnel server device, and the predetermined number is four, for example.

  Further, the tunnel function means is configured to transmit a survival confirmation request when a predetermined timer time has elapsed without receiving a packet after receiving a data packet from the tunnel server device. Also good.

  According to the present invention, a client device can be provided with a tunneling function with almost no application modification. Further, according to the present invention, the packet skipping process is not required, so the header attached to the packet can be shortened, and efficient communication can be realized. Furthermore, according to the present invention, it is possible to provide a survival confirmation technique that makes it possible to satisfy the conflicting conditions of reducing the processing burden and shortening the abnormal state detection time.

It is a figure which shows the conventional tunneling system. It is a figure which shows the conventional tunneling system. It is a system configuration figure in an embodiment of the invention. It is a functional lineblock diagram of client apparatus 1 in a 1st embodiment. It is the figure which expressed the function of the client apparatus 1 in 1st Embodiment with the protocol stack. It is a functional lineblock diagram of tunnel server device 1 in a 1st embodiment. It is a sequence chart in a 1st embodiment. It is a flowchart at the time of packet transmission of the client apparatus 1 in 1st Embodiment. It is a flowchart at the time of packet reception of the client apparatus 1 in 1st Embodiment. It is a flowchart at the time of packet reception of the tunnel server apparatus 2 in 1st Embodiment. It is a figure which shows the concept of the process at the time of damaged data reception. It is a function block diagram of the tunnel function part 12 of the client apparatus 1 in 2nd Embodiment. It is a function block diagram of the tunnel server apparatus 2 in 2nd Embodiment. It is a figure which shows the example of a table stored in the table information storage part 124 of the client apparatus 1 in 2nd Embodiment. It is a figure which shows the example of a table stored in the table information storage part 23 of the tunnel server apparatus 2 in 2nd Embodiment. It is a figure for demonstrating the example of tunneling communication in 2nd Embodiment. It is a sequence chart in a 2nd embodiment. It is a flowchart of the tunnel connection process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the process at the time of tunnel connection of the tunnel server apparatus 2 in 2nd Embodiment. It is a flowchart of the port map request | requirement process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the process at the time of the port map request | requirement of the tunnel server apparatus 2 in 2nd Embodiment. It is a flowchart of the port map cancellation | release request | requirement process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the port map cancellation request processing of the tunnel server device 2 in the second embodiment. It is a flowchart of the packet transmission process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the packet reception process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the packet transmission process of the tunnel server apparatus 2 in 2nd Embodiment. It is a flowchart of the packet reception process of the tunnel server apparatus 2 in 2nd Embodiment. It is a flowchart of the tunnel cutting | disconnection process of the client apparatus 1 in 2nd Embodiment. It is a flowchart of the tunnel reconnection process of the client apparatus 1 in 2nd Embodiment. It is a function block diagram of the tunnel function part 12 of the client apparatus 1 in 3rd Embodiment. It is a functional block diagram of the tunnel server apparatus 2 in 3rd Embodiment. It is a figure for demonstrating the outline | summary of the process in 3rd Embodiment. It is a flowchart which shows the process at the time of the control packet reception of the client apparatus 1 in 3rd Embodiment. It is a flowchart of the process at the time of packet transmission of the client apparatus 1 in 3rd Embodiment. It is a figure which shows the example of an IP packet. It is a flowchart of the process at the time of the data packet reception of the client apparatus 1 in 3rd Embodiment. It is an example of a survival confirmation operation | movement sequence in 3rd Embodiment. It is an example of a survival confirmation operation | movement sequence in 3rd Embodiment.

  Embodiments of the present invention will be described below with reference to the drawings.

<First Embodiment>
(System configuration)
FIG. 3 shows the overall configuration of the system in the first embodiment. As shown in FIG. 3, the system according to the present embodiment includes a firewall device 4 installed at the boundary between the Internet 5 and a private network 6 such as a corporate network, a client device 1 under the firewall device 4, and a tunnel. A server apparatus 2 and a communication partner apparatus 3 that communicates with the client apparatus 1 are included. In the present embodiment, the tunnel server device 2 and the communication partner device 3 are connected to the Internet 5.

  The client device 1 is a computer (PC, portable terminal, etc.) provided with a general OS (operating system), an application that performs communication for a purpose such as an IP phone or video conference, and a tunnel processing function according to the present invention.

  The tunnel server device 2 is a device having a function of receiving a request from the client device 1 to form a tunnel with the client device 1 and performing communication with the client device 1 via the tunnel. The firewall device 4 is a firewall device 4 that allows communication of the tunnel. In the present embodiment, any type of tunnel protocol may be used as long as communication by the firewall device 4 is permitted.

  The communication partner device 3 in the present embodiment is, for example, a SIP server or other application server, and communicates with the client device 1. Of course, the communication partner device 3 may be another client device provided in the same or another private network.

  FIG. 4 shows a functional configuration diagram of the client device 1. As shown in FIG. 4, the client device 1 includes a data communication unit 11, a tunnel function unit 12, and an application unit 13. The data communication unit 11 includes a packet capturing / releasing unit 14 (may be referred to as a packet control unit).

  The data communication unit 11 is a functional unit for performing data communication via a communication network. The data output from the application unit 13 is converted into an IP packet, and the reverse process is performed. The IP packet is input and output. Includes network interface functions. The function of the packet capturing / releasing unit 14 included in the data communication unit 11 will be described later.

  The application unit 13 is a functional unit corresponding to an application for providing a target communication service (for example, video conference communication). For example, a function for performing control communication such as SIP and a function for performing media communication such as audio / video. Etc.

  The tunnel function unit 12 corresponds to a tunneling client application corresponding to a tunnel server, and includes a tunnel processing unit 121 and a damaged data processing unit 122. The tunnel processing unit 121 is a function unit that transmits a packet (IP packet) received from the packet capture / release unit 14 via a tunnel, and a function unit that receives a packet via a tunnel. More specifically, the tunnel processing unit 121 encapsulates the received packet by using, for example, an HTTP header, and transmits the encapsulated packet via the data communication unit 11 or is encapsulated by the tunnel header. When a received packet is received, the encapsulation of the tunnel header is removed, the contents packet is taken out, and the packet is output. In this specification, expressions such as “send via a tunnel” and “receive via a tunnel” actually mean performing encapsulation / decapsulation as described above. ing.

  Furthermore, in the present embodiment, tunnel processing unit 121 generates a packet with a header including an identifier indicating the type of packet (control packet, data packet type, etc.) to be sent to the tunnel, and the packet length. And has a function of sending the packet with the header to the tunnel.

  The damaged data processing unit 122 checks whether or not the packet received from the tunnel is damaged. If the packet is damaged, the damaged data processing unit 122 has a damaged data processing function such as temporarily disconnecting the tunnel connection and reconnecting the tunnel. doing.

  The packet capturing / discharging unit 14 monitors packets flowing through the data communication unit 11 and, for example, a specific IP address and port number specified by the tunnel function unit 12 or a specific port number (these are referred to as communication information). When a packet having “Yes” is detected, the packet is acquired (captured) and passed to the tunnel function unit 12.

  In the present embodiment, a packet transmitted from the application unit 13 is captured by the packet capture / release unit 14 and passed to the tunnel function unit 12. Further, the packet capturing / releasing unit 14 receives the packet decapsulated by the tunnel function unit 12, and transmits (discharges) the packet to the application unit 13.

  Note that packets other than the packet having the specified specific communication information are transferred to the application unit 13 or sent to the outside by the function of the data communication unit 11 depending on the type and destination of the packet.

  FIG. 5 is a diagram representing the configuration shown in FIG. 4 as a stack image of software (program module). In FIG. 5, in order to make the correspondence with FIG. 4 easier to understand, the reference numerals attached to the corresponding functional units in FIG. 4 are given. As can be seen from the description position in FIG. 5, the packet capturing / discharging unit 14 can be realized by a device driver. The tunnel client program and the device driver are programs that cause the computer to function as the tunnel function unit 12 and the packet capture / release unit 14.

  FIG. 6 shows a functional configuration diagram of the tunnel server device 2. As shown in FIG. 6, the tunnel server device 2 in the present embodiment includes a tunnel processing unit 21 and a damaged data processing unit 22. The tunnel processing unit 21 is a functional unit that performs tunnel server processing corresponding to the tunnel processing unit 121 in the client device 1. Further, the damaged data processing unit 22 is a functional unit that detects a damaged data of a received packet and performs a tunnel disconnection process or the like in the same manner as the damaged data processing unit 122 in the client device 1.

  Each of the client device 1 and the tunnel server device 2 according to the present embodiment can be realized by causing a computer having a CPU, a storage device, and the like to execute programs for realizing the above functions. The program may be installed in a computer from a recording medium such as a portable memory, or may be downloaded from a server on the network.

  By configuring the client device 1 as described above, processing related to tunneling is hidden from the application unit 13. That is, the application unit 13 can realize tunneling while performing normal communication processing similar to the case without the tunneling function unit without being conscious of tunneling.

(About system operation)
Next, an outline of the operation of the system according to the present embodiment will be described with reference to the sequence chart of FIG.

  First, the tunnel function unit 12 in the client device 1 transmits a tunnel connection request to the tunnel server device 2 to perform tunnel setting (tunnel connection) (step 1). In other words, the tunnel server device 2 and the tunnel function unit 12 of the client device 1 make settings necessary for tunnel communication. Note that the tunnel function unit 12 may perform tunnel connection based on a request from the application unit 13, for example.

  Thereafter, a packet is transmitted from the application unit 13. More specifically, the data output from the application unit 13 is converted into an IP packet by the data communication unit 11. Here, for the sake of convenience, the packet is transmitted from the application unit 13 (step 2). .

  The packet is delivered to the tunnel function unit 12 via the packet capture / release unit 14, and the tunnel function unit 12 adds an identifier indicating the packet type and packet length information as a header, and includes a header. The packet is sent through the tunnel (step 3).

  The sent header-attached packet is received by the tunnel server device 2 via the tunnel. In the tunnel server device 2, a packet corruption check is performed. If there is no damage, the packet from which the header is removed is transmitted to the communication partner apparatus 3.

  Also, the tunnel server device 2 that has received the packet transmitted from the communication partner device 3 (step 5) adds a header (identifier and length) to the packet, and transmits the packet with the header via the tunnel (step 6). .

  The tunnel function unit 12 in the client device 1 receives a packet with a header via a tunnel and performs a damage check. If there is no damage, the packet from which the header has been removed is passed to the application unit 13 via the packet capture / release unit 14 (step 7).

  When the tunnel server device 2 or the client device 1 detects the packet corruption, the tunnel is disconnected (step 8), and the tunnel is reconnected immediately (step 9). Packet communication is performed in the same manner as described above.

  Next, main processes will be described in detail with reference to each flowchart.

  First, the operation of the client device 1 when data is transmitted from the application unit 13 will be described with reference to the flowchart of FIG.

  The data transmitted from the application unit 13 is converted into a packet to which communication information is added in the data communication unit 11. Then, the packet capturing unit / release unit 14 checks whether or not the communication information in the packet matches the designated communication information (step 11). As an example, more specifically, the designated communication information is stored in a memory or the like like a socket management table managed by the OS, and the packet capture unit / release unit 14 has an origination address. It is the address of the client device 1, and a match confirmation is made as to whether or not the protocol type and port number correspond to the socket owned by the application unit 13.

  When the communication information of the monitored packet matches the designated communication information, the packet capturing unit / release unit 14 captures the packet and passes the captured packet to the tunnel function unit 12. The tunnel function unit 12 generates a packet with a header in which a header including an identifier (ID) and length information is added to the packet received from the packet capture / release unit 14, and transmits the packet with the header via the tunnel. (Step 12).

  In step 11, if the communication information in the packet does not match the specified communication information, the packet will be forwarded to the appropriate destination.

  Next, the operation when the tunnel function unit 12 in the client apparatus 1 receives a header-attached packet via a tunnel will be described with reference to the flowchart of FIG.

  For example, the tunnel function unit 12 checks whether the header identifier matches a predetermined value, whether the length information matches the actual packet length, etc. It is determined whether or not (step 21). If it is determined that the packet is not damaged, the packet function unit 12 sends (releases) the packet with the header removed to the application unit 13 side via the packet capture / release unit 14 (step 22).

  If it is determined in step 21 that the packet is damaged, the packet function unit 12 temporarily disconnects the tunnel connection (step 23), and transmits a connection request to the tunnel server again, thereby establishing a tunnel connection. Is resumed (step 24).

  Next, the operation when the tunnel server device 2 receives a packet with a header via a tunnel will be described with reference to the flowchart of FIG.

  The tunnel server device 2 determines whether or not the packet is damaged, similarly to the tunnel function unit 12 of the client device 1 (step 31). If the packet is not damaged, the packet with the header removed is sent to the network (step 32). In step 31, when the packet corruption is detected, the tunnel connection is disconnected. At this time, the tunnel function unit 12 of the client device 1 detects that the tunnel is disconnected and performs reconnection processing.

  FIG. 11 shows a conceptual diagram of processing when a damaged packet is received in the tunnel server device 2 or the client device 1. As shown in FIG. 11, if no damage is detected in a packet transmitted via a tunnel, a packet from which the header is removed is sent out. If damage is detected, the tunnel is reconnected after disconnection. A packet with a header is transmitted.

  This processing is based on the fact that the possibility that a packet is corrupted is very low. As described above, since the disconnection / reconnection is performed when the packet is damaged, the process of skipping the packet and detecting the next header as in the conventional case is not necessary. The length can be made much shorter than before. As a result, communication overhead can be reduced as compared to the conventional case.

<Second Embodiment>
Next, a second embodiment of the present invention will be described. In the second embodiment, port mapping is performed.

(System configuration)
The overall system configuration in the present embodiment is the same as the system configuration in the first embodiment shown in FIG. In the following, the description will mainly focus on differences from the first embodiment.

  FIG. 12 shows a functional configuration diagram of the tunnel function unit 12 of the client device 1 in the present embodiment. As shown in FIG. 12, in addition to the damaged data processing unit 122 and the tunnel processing unit 121, the tunnel function unit 12 according to the present embodiment performs address / port acquisition processing, management, and conversion processing. Section 123 and table information storage section 124.

  FIG. 13 shows a functional configuration diagram of tunnel server device 2 in the present embodiment. As shown in FIG. 13, in addition to the damaged data processing unit 22 and the tunnel processing unit 21, the tunnel server device 2 according to the present embodiment performs address / port processing for performing processing relating to management / payout of address / port information. Section 24 and table information storage section 23.

  FIG. 14 shows an example of a table stored in the table information storage unit 124 of the client device 1. As shown in FIG. 14, the table information storage unit 124 of the client device 1 stores the client connection management table that records the tunnel connection, the session ID, and the server address of the client device 1 in association with each other, the session ID, and the mapped port. A client port map table that records a protocol type, a server port number, and a client port number in association with each other and a client address table that records a client address are stored. Of course, the address of the client device 1 is stored in the storage means such as the table information storage unit 124 of the client device 1.

  FIG. 15 shows an example of a table stored in the table information storage unit 23 of the tunnel server device 2. As shown in FIG. 15, the table information storage unit 23 of the tunnel server device 2 stores a server connection management table, a server port map table, and a server free port list.

  The server connection management table records the tunnel connection identifier and the session ID in association with each other. The server port map table records the session ID, the protocol type of the mapped port, and the port number. The server free port list records free port numbers in the tunnel server device 2 for each protocol type.

(System operation)
First, an example of tunneling communication according to the present embodiment will be described with reference to FIG. In this example, it is assumed that addresses as shown in FIG. 16 are assigned to each device. FIG. 16 also shows information in a header (communication information) of a packet transmitted / received via a tunnel. In the example of FIG. 16, the table information storage unit 124 in the tunnel function unit 12 of the client device 1 contains the address (12.23.45.78) and port number (1235) of the tunnel server device 1, and the application unit 13 They are stored in association with the client port number (5534), which is the port number to be used, and the address (10.10.9.8) of the client device 1.

  First, when an upstream packet is transmitted from the application unit 13, the packet capture / release unit 14 matches the source address (SRC_ADDR: 10.10.9.8) with the address (10.10.9.8) of the client device 1, and the protocol type ( PROTOCOL: UDP) and port number (SRC_PORT: 5534) are confirmed to exist in the client port map table, and the uplink packet is passed to the tunnel function unit 12. In the tunnel function unit 12, the table information storage unit 124 is searched based on the outgoing port number (SRC_PORT: 5534) of the upstream packet, the outgoing address (SRC_ADDR: 12.23.45.78) corresponding to the outgoing port number, and the outgoing port number (SRC_PORT: 1235) is acquired and the source address and source port number in the upstream packet are converted into the acquired source address (SRC_ADDR: 12.23.45.78) and source port number (SRC_PORT: 1235). Then, the tunnel function unit 12 sends the converted upstream packet through the tunnel.

  The tunnel server device 2 that has received the uplink packet via the tunnel sends the uplink packet to the communication partner device 3.

  Since the address and port number of the tunnel server device 2 are set as the source address and source port number in the upstream packet, the communication partner device 3 that has received the upstream packet sends the packet from the tunnel server device 2. It is recognized that

  Thereafter, the communication partner device 3 transmits a downlink packet in which the destination address and the destination port number are set to those of the tunnel server device 2. The tunnel server device 2 that has received the downlink packet sends the downlink packet to the client device 1 via the tunnel.

  The tunnel function unit 12 of the client device 1 that has received the downlink packet from the tunnel refers to the table information storage unit 124 to obtain the destination address and the destination port number in the downlink packet as the address of the client device 1 (10.10.9.8). And the port number (5534), and the converted packet is sent to the application unit 13 via the packet capture / release unit 14.

  Next, a processing sequence in the present embodiment will be described with reference to FIG. First, the outline of the process will be described along this sequence.

  First, when the application unit 13 makes an initialization request to the tunnel function unit 12 (step 41), the tunnel function unit 12 performs an initialization process and transmits a tunnel connection request to the tunnel server device 2. By doing so, a tunnel is set (step 42). In this initialization process, for example, a process of clearing all entries in the client port map table and the client connection management table is performed.

  The tunnel server device 2 that has received the tunnel connection request connects the tunnel. Here, the tunnel server device 2 records the connection identifier and the session ID in the server connection management table shown in FIG. .

  Then, the tunnel server device 2 returns a tunnel connection response including the address of the tunnel server device 2 and the session ID to the tunnel function unit 12 of the client device 1, and the tunnel function unit 12 performs an initial response to the application unit 13. Returns a response to the conversion result.

  From the above processing, a tunnel is set, and subsequent communication between the tunnel server device 2 and the client device 1 is performed via the tunnel.

  Thereafter, the application unit 13 transmits a port map request to the tunnel function unit 12 (step 45), and the tunnel function unit 12 transmits a port map request to the tunnel server device 2 (step 46). This port map request includes the protocol type used by the application unit 13. Since a port map release request can also be made, in FIG. 17, it is described as a port request in the sense of including both.

  The tunnel server device 2 pays out one port number from the vacant port numbers, includes it in the port request result, and transmits it to the tunnel function unit 12 of the client device 1 (step 47). The tunnel function unit 12 that has received the port number stores the port number in the table information storage unit 124 and returns a port request result response to the application unit 13 (step 48).

  Thereafter, the packet communication as described with reference to FIG. 16 is performed (steps 49 to 54). Also in the second embodiment, a header (identifier + length) is attached to a packet transmitted / received via a tunnel, as in the first embodiment. Similarly, a damage check is performed.

  If damage is detected, the tunnel is disconnected (step 55), and tunnel reconnection is performed (step 56). The session ID is added to the tunnel connection request at this time, and the session ID is included in the response from the tunnel server device 2 (step 57). As a result, a session with the same session ID as before the tunnel disconnection can be continued after the tunnel disconnection.

  Next, with reference to each flowchart, main processes in the processes shown in the sequence will be described in more detail.

  FIG. 18 shows tunnel connection processing in the client device 1. As shown in FIG. 18, the tunnel function unit 12 of the client device 1 connects to the tunnel server device 1 (step 71), and then receives the server address and session ID from the tunnel server device 1 (step 72). Then, the tunnel function unit 12 adds an entry to the client connection management table and the client port map table (step 73).

  FIG. 19 shows processing at the time of tunnel connection in the tunnel server device 2. As shown in FIG. 19, the tunnel server device 2 that has received the tunnel connection request first checks whether or not a session ID is added to the tunnel connection request (step 81).

If there is no session ID, the tunnel server device 2 generates a session ID from the pseudo random number (step 82), and returns a normal completion response, a server address, and a session ID to the client device 1 via the tunnel (step 86).
In step 81, when the session ID is included in the tunnel connection request, the tunnel server device 2 checks whether the session ID exists in the server connection management table, and returns an error if it does not exist (step 84). ). If it exists, the connection identifier of the entry corresponding to the session ID in the server connection management table is updated, and the process proceeds to Step 86.

  FIG. 20 shows port map request processing on the client device 1 side, and FIG. 21 shows processing at the time of port map request in the tunnel server device 2.

  As shown in FIG. 20, in the port map request process on the client device 1, the tunnel function unit 12 first sends a port map request and the requested protocol type via the tunnel based on the request from the application unit 13. Transmit to the tunnel server device 2 (step 91).

  When the normal end response is returned, the tunnel function unit 12 acquires the session ID from the client connection management table (step 94), and stores the session ID, protocol type, server port number, client port number in the client port map table. Is added (step 95).

  Next, with reference to FIG. 21, a process related to the port map request on the tunnel server apparatus 2 side will be described.

  The tunnel server device 2 that has received the port map request acquires an entry (protocol type, port number) of the protocol type corresponding to the request from the server free port list, and deletes the entry from the list (steps 101 and 103). ). Then, an entry (protocol type, port number, session ID) is added to the server port map table (step 104), and a normal completion response and the issued port number are transmitted to the client device 1 via the tunnel (step 105). . If there is no protocol type entry corresponding to the request, an error is returned (step 102).

  In the present embodiment, port map release processing is performed when communication using a port map is completed. FIG. 22 shows port map release processing on the client device 1 side, and FIG. 23 shows port map release processing on the tunnel server device 2 side.

  First, the port map release processing on the client device 1 side will be described with reference to FIG. Upon receiving the port map release request from the application unit 13, the tunnel function unit 12 checks whether the release target port number corresponding to the application unit 13 exists in the client port map table, and returns an error if it does not exist. (Steps 111 and 112).

  When the port number to be released exists, the tunnel function unit 12 transmits the port map release request, the protocol type to be released, and the port number to be released (server port number) to the tunnel server device 2 via the tunnel (step 113).

  Thereafter, if a normal end response is returned, the tunnel function unit 12 acquires the session ID from the client connection management table (step 115), and deletes the entry corresponding to the session ID from the client port map table (step 116). ).

  Next, with reference to FIG. 23, processing related to a port map release request on the tunnel server device 2 side will be described.

  The tunnel server device 2 that has received the port map release request checks whether or not the combination of the protocol type and the port number related to the request exists in the server port map table, and if not, returns an error (step 121, 122) If it exists, the process proceeds to step 123. In step 123, the tunnel server device 2 deletes the entry to be canceled from the server port map table (step 123), adds an entry to the free port list (step 124), and completes the normal completion via the tunnel to the client device 1. (Step 125).

  FIG. 24 shows processing at the time of packet transmission in the client device 1, and FIG. 25 shows processing at the time of packet reception in the client device.

  First, with reference to FIG. 24, processing at the time of packet transmission will be described. The packet capture / release unit 14 monitors each packet flowing through the data communication unit 11 and checks whether or not the communication information in the packet matches the designated communication information (step 131). In the present embodiment, when the source address is the address of the client device 1 and the protocol type and the port number are the protocol type and client port number existing in the client port map table, the packet is passed to the tunnel function unit 13 ( The packet capturing / releasing unit 14 passes the packet to the tunnel function unit 12 when it is determined that the communication information of the packet matches the above condition.

  As described with reference to FIG. 16, the tunnel function unit 12 rewrites the source address of the packet to the server address and rewrites the source port number to the server port number (step 132). Then, the tunnel function unit 12 generates a header-attached packet to which a header including an identifier and length information is added, and sends the header-attached packet via the tunnel (step 133).

  Next, the operation when the tunnel function unit 12 in the client apparatus 1 receives a packet with a header via a tunnel will be described with reference to the flowchart of FIG.

  First, the tunnel function unit 12 that has received the packet determines whether or not it is a disconnection notification (step 141). If it is a disconnection notification, tunnel disconnection processing is performed (step 142).

  If it is not a disconnection notification, the tunnel function unit 12 determines whether or not the packet is damaged as in the first embodiment (step 143). If it is determined that the packet is not damaged, the packet function unit 12 removes the header from the packet (step 144), rewrites the destination address to the local address, rewrites the destination port number to the local port number, and captures the rewritten packet. -It sends out to the application part 13 side through the discharge part 14 (step 145).

  If it is determined in step 143 that the packet is damaged, the packet function unit 12 performs tunnel reconnection processing (step 146).

  FIG. 26 shows processing when the tunnel server device 2 transmits a packet received from the communication partner device 3 to the tunnel, and FIG. 27 shows processing when the tunnel server device 2 receives a packet from the tunnel.

  The tunnel server device 2 refers to the destination port number of the packet received from the communication partner device 3, and first searches the server port map table for a session ID corresponding to the port number (server port number) (step 151). If there is not, the packet is discarded (step 152), and if it is, the session ID is acquired (step 153). Then, a connection identifier corresponding to the session ID is acquired, a header (identifier + length) is attached to the packet, and a packet with a header is transmitted via a tunnel set in association with the connection identifier (step 154). .

  Next, with reference to FIG. 27, processing when the tunnel server device 2 receives a packet from a tunnel will be described.

  The tunnel server device 2 checks whether or not the received packet is a disconnection notification (step 161). If it is a disconnection notification, the corresponding entry in the server connection management table and the port map table is cleared and the tunnel connection is disconnected. (Steps 165 and 163).

  If the received packet is not a disconnection notification, it is determined whether the packet is damaged as in the tunnel function unit of the client device. If the packet is not damaged, the packet with the header removed is sent to the network (steps 162 and 164). In step 162, when packet corruption is detected, the tunnel connection is disconnected (step 163).

  At this time, the tunnel function unit 12 of the client device 1 detects that the tunnel is disconnected and performs reconnection processing.

  Next, tunnel disconnection processing based on an instruction from the application unit 13 on the client device 1 side will be described with reference to FIG.

  The tunnel function unit 12 that has received the tunnel disconnection request from the application unit 13 transmits a disconnection notification to the tunnel server device 2 (step 171), and disconnects the connection with the tunnel server device 1 (step 172). The tunnel function unit 12 acquires the session ID from the client connection management table (step 173), and clears the entries in the client port map table and the client connection management table using the session ID as a key (step 174).

  Next, with reference to FIG. 29, a tunnel reconnection process (such as when a packet is damaged) on the client apparatus 1 side will be described.

  First, the tunnel function unit 12 temporarily disconnects from the tunnel server device 2 (step 181). The tunnel function unit 12 then connects to the tunnel server device 182 (step 182), and transmits the session ID of the tunnel connection that was connected before disconnection to the tunnel server device 2 (step 183). The server address and session ID are received (step 184). If there is an unintended tunnel disconnection, such as when there is packet corruption on the server side, the process starts from step 182.

  The tunnel function unit 12 checks whether or not the transmitted session ID is the same as the received session ID (step 185), and if it is the same, the process here ends. That is, in this case, tunnel communication is performed with the session ID before disconnection.

  If the transmitted session ID and the received session ID are not the same in step 185, the table entry of the old session ID is cleared and an entry with the new session ID is added (steps 186 and 187). After that, tunnel communication is performed with the new session ID.

  That is, in the present embodiment, in the case of disconnection and reconnection, the state of port mapping already performed is held using the session ID.

<Third Embodiment>
Next, a third embodiment will be described. The overall system configuration in the present embodiment is the same as the system configuration in the first embodiment shown in FIG. The client device 1 and the tunnel server device 2 are assumed to include the functions described in the first and second embodiments. The following description will focus on differences from the first and second embodiments.

  FIG. 30 is a functional configuration diagram of the tunnel function unit 12 of the client device 1 in the present embodiment. As shown in FIG. 30, the tunnel function unit 12 of the client device 1 in the present embodiment includes a survival confirmation processing unit 125 and a time information storage unit 126 in addition to the configuration in the second embodiment.

  The survival confirmation processing unit 125 has a function for performing processing related to survival confirmation described later, and a timer 1 for timing determination (same as conventional) for transmitting a survival confirmation request (similar to the prior art) as a timer for the process (for example, about 30 seconds) ), A reception interruption detection timer 2 (for example, about 1 second) and a disconnection detection time measurement timer 3 (for example, about 3 seconds). The time information storage unit 126 stores time information such as RTT, final transmission time, average transmission interval, and request transmission time, which will be described later, and also stores reception prediction flag information.

  FIG. 31 shows a functional configuration diagram of tunnel server device 2 in the present embodiment. As shown in FIG. 31, in addition to the configuration in the second embodiment, the tunnel server device 2 in the present embodiment includes a survival confirmation processing unit 25 and a time information storage unit 26 that perform processing for survival confirmation. Have The time information storage unit 26 stores the last reception time described later.

  Next, processing in the present embodiment will be described with reference to FIG. 32 and each flowchart as appropriate. Communication between the tunnel server device 2 and the client device 1 (tunnel function unit 12) in FIG. 32 is communication via a tunnel.

  First, the tunnel function unit 12 of the client device 1 performs an initialization process. In the initialization process, the RTT value is set to 0, and the current time is set to the final transmission time. Then, the timer 1 is started and the reception prediction flag is cleared (for example, set to 0). The reception prediction flag is a flag for detecting interruption of reception of the data packet, and is set when the data packet is received. When the timer 2 expires with the flag set, the existence confirmation is confirmed. A request is sent.

  When the tunnel function unit 12 transmits a control packet (a packet other than a data packet including data transmitted from the application unit 13) such as a port map request, the transmission time is recorded as a “request transmission time”. .

  In particular, when a survival confirmation request is transmitted as a control packet, the transmission time is recorded as a “request transmission time”, and a timer 3 for detecting the expiration of the survival confirmation request response waiting time (that is, disconnection). Start. When the timer 3 times out, the current tunnel connection is disconnected and tunnel reconnection is executed.

  When the tunnel function unit 12 receives a response to the control packet, the tunnel function unit 12 determines an RTT (Round Trip Time) that is a time for which the packet travels between the tunnel server device 2 and the client device 1 based on the reception time. Then, it is stored in the time information storage unit 126.

  FIG. 33 is a diagram showing in more detail the processing of the tunnel function unit 12 when receiving a control packet. With reference to FIG. 33, the process when receiving the control packet will be described more specifically.

  As shown in FIG. 33, when a survival confirmation request response is received in the control packet, the timer 1 is started (if already started, it is stopped and restarted), and the timer 3 is stopped. (Step 191). Thereafter, the process proceeds to step 192. In the case of a control packet other than the survival confirmation request response, the process starts from step 192.

  In step 192, the tunnel function unit 12 clears the reception prediction flag and stops the timer 2. Then, the current time-request transmission time is calculated, and it is set as a response time, and it is checked whether the response time is greater than the current RTT value. If not, the process is terminated. Is stored in the time information storage unit 126. That is, by this processing, the maximum RTT in the session is recorded.

  Returning to FIG. 32, each time the client device 1 transmits a packet (all types of packets including control packet packets), the transmission time of the packet is stored in the time information storage unit 126 as the “last transmission time”. Based on the “final transmission time”, an “average transmission interval” is calculated and stored in the time information storage unit 126.

  More specifically, as shown in the flowchart of FIG. 34, the tunnel function unit 12 first sets the current time-final transmission time as the transmission interval. Then, the average transmission interval stored in the time information storage unit 126 is acquired, and α × transmission interval + (1−α) × average transmission interval is calculated using the average transmission interval, and this is calculated as a new average. It is stored in the time information storage unit 126 as a transmission interval. α is a constant between 0 and 1, and is determined in advance.

  Then, the tunnel function unit 12 stores the current time in the time information storage unit 126 as “final transmission time”.

  Returning to FIG. 32, every time a packet (all types of packets including control packet packets) is received from the client device 1, the tunnel server device 2 stores the reception time in the time information storage unit 26 as the “last reception time”. In addition, when a data packet (IP packet of data that is not a control packet) is transmitted, the elapsed time from the “last reception time” of the transmission time of the data packet is checked in a predetermined area of the IP packet header (in this embodiment, Overwrite (sum field) and send. FIG. 35 shows the configuration of an IP packet including a checksum field.

  The processing when the tunnel function unit 12 of the client device 1 receives the data packet from the tunnel server device 1 is as shown in FIG.

  As shown in FIG. 36, when the tunnel function unit 12 receives a data packet, first, a reception prediction flag is set (step 211), and the timer 2 is started (step 212).

  Further, the tunnel function unit 12 calculates an elapsed time (current time−final transmission time) from the “last transmission time” at the time of receiving the packet (“current time”), and the elapsed time is 2 × RTT or more. In some cases, a survival confirmation request is transmitted to the tunnel server apparatus 1 only when the “checksum field” is larger than (“current time” − “last transmission time”) (steps 213, 214, and 215).

  When the elapsed time is less than 2 × RTT, a survival confirmation request is transmitted only when the “checksum field” is larger than “average transmission interval” × 4 (steps 213, 216, and 215).

  That is, when the elapsed time from the time when the previous packet was transmitted from the client device 1 (final transmission time) to the time when the current data packet was received is somewhat longer than the RTT (in this embodiment, 2 of RTT). It is possible to predict the possibility that the time interval of packets transmitted from the client device, which should play the role of survival confirmation, is long.

  Therefore, in this case, the elapsed time (checksum field) on the server side is compared with the elapsed time on the client side. If the elapsed time on the server side is shorter, the packet sent from the client device 1 is Therefore, the existence confirmation request is not sent out because it can be determined that it has played the role of existence confirmation. On the other hand, when the elapsed time on the server side is longer, it can be assumed that the packet transmitted last from the client device 1 has not normally reached the tunnel server, so the packet transmitted last time does not play the role of survival confirmation. It is assumed that a survival confirmation request is sent.

  On the other hand, when the elapsed time from the time when the previous packet was transmitted from the client device 1 (last transmission time) to the time when the data packet was received is somewhat shorter than the RTT (in this embodiment, less than twice the RTT) ) It can be assumed that a data packet corresponding to a previous transmission packet is received instead of a data packet corresponding to the previously transmitted packet.

  Therefore, in this case, it is checked whether or not the elapsed time on the server side is somewhat longer than the average transmission interval (in this embodiment, whether or not it is longer than the average transmission interval × 4). If the elapsed time on the server side is not somewhat longer than the average transmission interval, the server that transmitted the data packet received by the client apparatus 1 has confirmed that the survival confirmation has been established in the previously received packet. Since it can be determined, the survival confirmation request is not transmitted.

  On the other hand, if the elapsed time on the server side is somewhat longer than the average transmission interval, the server transmits a packet that plays a role of survival confirmation from the client apparatus 1 after the survival confirmation by the previously received packet. Since it is possible to estimate that there is not, a survival confirmation request is sent.

  On the other hand, in parallel with the above check, after starting the timer 2 when receiving the data packet, the client device 1 transmits a survival confirmation request when the time of the timer 2 has elapsed without receiving the packet. That is, when a reception interruption is detected, a survival confirmation request is transmitted.

  Further, the client device 1 uses the timer 1 to send out a survival confirmation request at regular time intervals whenever the timer 1 expires.

  FIG. 37 is a diagram illustrating an example of a survival confirmation operation concept. The example shown in FIG. 37 is an example in the case where transmission / reception of data packets has not been performed at all. In this case, a survival confirmation request is periodically transmitted every time the timer 1 times out.

  FIG. 38 is a diagram illustrating another example of the survival confirmation operation concept. In the example shown in FIG. 38, as described above, the client device 1 is delivered with a data packet including the elapsed time from the last reception time in the tunnel server device 2 in the checksum column. Then, by the above-described logic, it is determined whether or not the survival confirmation request needs to be transmitted by performing an abnormality determination from the RTT and the average transmission interval value for each packet. Further, the interruption of data packet reception is checked by the timer 2 that is activated when the data packet is received, and when a reception interruption is detected, a survival confirmation request is transmitted each time.

  When data is transmitted and received without interruption by this method, since the transmitted / received data itself plays a role of survival confirmation, a survival confirmation request is not made, whereas an abnormality is detected by the logic shown in FIG. Or, when the interruption of data is detected by the timer 2, since it is decided to send a survival confirmation request, compared to the prior art, while reducing the burden of sending the survival confirmation request itself, during data communication, Abnormalities can be detected in a relatively short time, and efficient data communication becomes possible.

<Summary of Embodiments and Effects>
In the embodiment of the present invention, the application unit 13 captures a packet to be transmitted / received using a normal communication library by the packet capturing / discharging unit 14 provided immediately before the network interface, and transmits the packet using a tunnel. On the contrary, the packet sent from the tunnel is discharged from the packet capture / release unit 14 and delivered to the application unit 13 via the OS protocol stack.

  Corresponding to corrupted data, if the corrupted data is found at the stage where the header is shortened and the packet is received from the tunnel, it is assumed that the tunnel processing has failed in the first place, and the tunnel is disconnected and reconnected. As a result, the process of skipping damaged data is omitted.

  In the embodiment of the present invention, the tunnel function unit 12 acquires the address of the tunnel server device 2 prior to the start of use of the tunnel. The application unit 13 declares and reserves in advance the port number that it uses for communication with the tunnel function unit 12, and at the same time, the tunnel function unit 12 assigns a corresponding port number to the tunnel server device 2 side. The tunnel function unit 12 receives the port number.

  As a result, only the packet of the declared port is transmitted / received through the tunnel, and the IP address and port number are converted at the time of transmission / reception. In tunnel connection, in preparation for reconnection, the tunnel server issues a session ID, and when reconnection occurs, the session mapping is presented to take over the port mapping state.

  Further, in the embodiment of the present invention, in addition to the survival confirmation request for confirming whether the tunnel connection operates normally, the response time of the control packet other than the data packet and the data packet is efficiently used. A survival confirmation request is made. Specifically, when the tunnel function unit 12 receives a data packet from the tunnel server device 2, the elapsed time from the last transmission time is checked, and if it is 2 × RTT or more, the checksum field > If the current time-the last transmission time, a survival confirmation request is transmitted. If it is less than 2 x RTT, a survival confirmation request is transmitted if "checksum field"> average transmission interval x 4. Furthermore, when the data packet is received, the above-described timer 2 is started, and a survival confirmation request is also transmitted when the time of the timer 2 elapses because the data packet is interrupted.

  By using the technique described in the present embodiment, it is possible to provide an efficient and stable (and secure) communication path with less modification of applications and the like. More specifically, it is as follows.

  In order to realize the tunnel function, a packet capturing / discharging unit 14 is provided immediately before the network interface. As a result, the application unit 13 can use the protocol stack provided by the OS as it is, so that the modification is unnecessary or small. This is particularly useful when you need to use existing software or libraries provided in object form. Further, since the protocol stack provided by the OS is used as it is, protocol processing by itself is not required, there is no instability due to the difference in specifications with the protocol stack of the OS, and the tunnel function unit 13 is implemented. Small scale is enough.

  In correspondence with damaged data, by shortening the header, the overhead required for each packet transmission can be omitted, and as a result, the transmission efficiency can be improved. In particular, as a tunnel connection, when the connection is encrypted and is not decrypted by the intermediate node as in HTTPS, the tunnel data is not normally damaged, and the effect of shortening the header is further increased. Furthermore, when there is an upper limit on the MTU (Message Transfer Unit) size of the transmission path, it is easy to exceed it due to the overhead for tunneling. However, in the technique according to this embodiment, the header length is short, so the same. Larger packets can be transmitted within the MTU.

  In the port mapping method described in the second embodiment, only a packet of a specific port designated in advance by the application unit 13 or the like is transmitted. As a result, only the minimum necessary ports used by the application unit 13 are opened to the outside, minimizing the risk of intrusion and attack from the outside, or information leakage from the inside by a Trojan horse or the like. be able to.

  In addition, by performing address / port conversion, the IP address assigned to the tunnel server can be divided into ports by multiple tunnel clients, saving IPv4 global IP addresses that are worried about exhaustion. Can be used. In addition, since communication can be performed while routing is simple as compared with a conventional technique in which a plurality of virtual network adapters exist, troubles due to routing can be prevented in advance.

  Further, according to the technique described as the third embodiment, in the case of no communication, the survival confirmation request can be realized at the same interval as when a simple survival confirmation request is sent. In addition, when communication is performed using data packets, in addition to being able to detect response deterioration for each data packet, a survival confirmation request should be sent when regular data packet reception is interrupted. Therefore, it is possible to detect an abnormality during communication in a short time.

  In addition, if the data packet is an IP packet, it must be recalculated by rewriting the port at the time of reception, and by using the checksum column of the IP packet whose transmission is meaningless, a survival confirmation request packet that is appropriately transmitted can be obtained. Except for this, there is no communication overhead according to the present embodiment.

  The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.

DESCRIPTION OF SYMBOLS 1 Client apparatus 2 Tunnel server apparatus 3 Communication partner apparatus 4 Fire fall apparatus 5 Internet 6 Private network 11 Data communication part 12 Tunnel function part 13 Application part 14 Packet capture and discharge part 21 Tunnel processing part 22 Damaged data processing part 23 Table information storage Unit 24 address / port processing unit 25 existence confirmation processing unit 26 time information storage unit 121 tunnel processing unit 122 damaged data processing unit 123 address / port processing unit 124 table information storage unit 125 existence confirmation processing unit 126 time information storage unit

Claims (9)

A client device that performs data communication with a communication partner device via a tunnel established with a tunnel server device,
Tunnel function means for constructing the tunnel with the tunnel server device and transmitting and receiving packets via the tunnel;
Data communication means for transmitting and receiving data via a communication network;
The packet passing through the data communication means is monitored, and when it is determined that the packet is a packet output from the application unit included in the client device based on the communication information of the packet, the packet is transferred to the tunnel function. A packet control means for passing to the means,
The tunnel function means is a client device that transmits the packet received from the packet control means to the communication counterpart device via the tunnel ,
The tunnel function means is
A server address and a server port number which are the address and port number of the tunnel server device are received from the tunnel server device, and the server address and the server port number are stored in association with the client port number corresponding to the application unit. Stored in the means,
When a packet including the client port number as an outgoing port number is received from the packet control means, the outgoing address in the packet is converted into the server address by referring to the storage means, and the outgoing port in the packet A client device , wherein a number is converted into the server port number, and the converted packet is transmitted via the tunnel .   The said packet control means receives the packet received via the said tunnel from the said tunnel function means, and sends out the said packet to the said application part via the said data communication means. Client device. The packet received by the tunnel function means via the tunnel has a header,
The tunnel function means is
Based on the information of the header, it is determined whether or not the packet is damaged. When it is determined that the packet is damaged, the tunnel is disconnected, and thereafter, between the tunnel server device and the tunnel server device. The client apparatus according to claim 1, further comprising a damage processing unit that reconstructs a tunnel. The tunnel function means is
When the packet including the server address as the destination address and the server port number as the destination port number is received via the tunnel, the destination address in the packet is determined by referring to the storage unit. The device address is converted to a device address, the destination port number in the packet is converted to the client port number, and the converted packet is sent to the application unit via the packet control means. 4. The client device according to any one of 1 to 3 . A client device that performs data communication with a communication partner device via a tunnel established with a tunnel server device,
Tunnel function means for constructing the tunnel with the tunnel server device and transmitting and receiving packets via the tunnel;
Data communication means for transmitting and receiving data via a communication network;
The packet passing through the data communication means is monitored, and when it is determined that the packet is a packet output from the application unit included in the client device based on the communication information of the packet, the packet is transferred to the tunnel function. A packet control means for passing to the means,
The tunnel function means is a client device that transmits the packet received from the packet control means to the communication counterpart device via the tunnel,
Each time the tunnel server device receives a packet from the client device, the tunnel server device stores the reception time of the packet as a final reception time in a storage unit, and when transmitting a data packet, the transmission time of the data packet Calculate the elapsed time from the last reception time, send the elapsed time included in the data packet as the server side elapsed time,
The tunnel function means is
Each time a packet is transmitted to the tunnel server device, the transmission time of the packet is held in the storage means as the final transmission time,
When the data packet is received from the tunnel server device, the elapsed time from the last transmission time of the reception time of the data packet is calculated as the client-side elapsed time,
A client device, wherein whether or not to transmit a survival confirmation request to the tunnel server device is determined based on the server-side elapsed time acquired from the data packet and the client-side elapsed time. The tunnel function means is
When the client side elapsed time is equal to or longer than a predetermined time, if the server side elapsed time is greater than the client side elapsed time, a survival confirmation request is transmitted,
When the client side elapsed time is less than the predetermined time, the server side elapsed time is not less than a predetermined number of times the average transmission interval calculated from the packet transmission time, and a survival confirmation request is issued. The client apparatus according to claim 5 , wherein the client apparatus transmits the client apparatus. 7. The client device according to claim 6 , wherein the predetermined time is a time twice as long as a round trip time between the client device and the tunnel server device, and the predetermined number is four. The tunnel function means transmits a survival confirmation request when a predetermined timer time has elapsed without receiving a packet after receiving a data packet from the tunnel server device. The client device according to any one of 5 to 7 . A program for causing a computer to function as tunnel function means and packet control means in the client device according to any one of claims 1 to 8 .

Images