Communication visualization device under proxy server, communication visualization method, and communication visualization program

The communication visualization device identifies access destinations by linking service names with flow data on the data plane, overcoming proxy server masking and maintaining performance.

JP2025168708AActive Publication Date: 2025-11-12FURUKAWA NETWORK SOLUTION CO LTD +1
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024073364
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-04-30
Publication Date
2025-11-12
Estimated Expiration
2044-04-30

AI Technical Summary

Technical Problem

In environments with proxy servers, existing visualization technologies using sFlow fail to identify the access destination accurately due to proxy server IP addresses masking the true communication sources, and performance is limited by routing through the control plane.

Method used

A communication visualization device that detects the domain name of the access destination, creates a TCP session table linking service names with flow data, and manages this information on the data plane to maintain performance.

Benefits of technology

Enables accurate visualization of communication destinations and reduces processing load by managing visualization information on the data plane, thus maintaining communication performance.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025168708000001_ABST
    Figure 2025168708000001_ABST
Patent Text Reader

Abstract

To allow the visualization of communication to be achieved even in an environment where a terminal communicates via a proxy server, by associating a name of a service of a connection destination of the terminal with flow data.SOLUTION: A detection unit 210 detects a domain name of a connection destination of a terminal by peeping in CONNECT method sent by the terminal. A determination unit 220 determines whether or not a name of a service of the connection destination of the terminal is an object of visualization based on the detected domain name. If the name of the service of the connection destination of the terminal is the object of visualization, a TCP session table creation unit 230 creates a TCP session table so as to include the name of the service of the connection destination of the terminal. An association unit 240 associates flow data collected by flow data collection means such as sFlow with the TCP session table stored in a TCP session table storage unit 350.SELECTED DRAWING: Figure 4
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a device for visualizing a communication status in an environment where a proxy server exists. [Background technology]

[0002] In recent years, it has become common for people to access the Internet from various locations, such as companies and schools, and use a variety of services. Accordingly, technologies that visualize communication status are becoming more widespread from the perspective of security and network maintenance and management. One such technology is sFlow, standardized in RFC3176. sFlow makes it possible to collect communication data on a flow-by-flow basis. Visualization tools using sFlow already exist and are contributing to network operations. The data relating to communication collected on a flow-by-flow basis is called "flow data." [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7178522 Summary of the Invention [Problem to be solved by the invention]

[0004] In many cases, visualization using sFlow involves obtaining domain information from the destination IP address of the flow data collected by sFlow, identifying the access destination based on that domain information, and then using this information for visualization. In environments where a company or school has a proxy server, the destination IP address of the flow data is the proxy server. This creates the problem of not being able to identify the access destination.

[0005] Furthermore, when flow data is obtained using sFlow after going through a proxy server, the destination information can be identified, but the IP addresses of all communication sources are those of the proxy server, so there is an issue of not knowing who is accessing the network.

[0006] In terms of performance, if a router substitutes for the proxy server function, two sessions must be terminated once: one between the terminal and the router, and the other between the router and the cloud service, and communication must be conducted via the control plane. As a result, the performance of the control plane limits the overall communication performance.

[0007] In other words, routers achieve high-speed forwarding by using a process dedicated to forwarding (i.e., the data plane), but by communicating via the control plane, they are unable to achieve sufficient performance.

[0008] Also, once an HTTPS session is terminated, management of certificates and other information is required, which requires more processing.

[0009] The present invention aims to visualize communication status by making it possible to identify the access destination of flow data collected by sFlow without degrading communication performance, even in an environment where a proxy server is present. [Means for solving the problem]

[0010] The inventors discovered that by storing the service name (e.g., the name of an application program) obtained from the domain information included in the CONNECT method together with the TCP session table, the service name can be linked to the flow data collected by sFlow, and this led to the completion of the present invention.

[0011] (1) The communication visualization device of the present invention is a communication visualization device that is placed between a terminal and a proxy server in an environment in which the terminal communicates via the proxy server, and includes: a detection unit that spies on the communication between the terminal and the proxy server and detects the domain name of the destination that the terminal is attempting to access; a TCP session table creation unit that uses the domain name obtained by spying on the communication between the terminal and the proxy server to create a TCP session table that includes the name of a service provided by the destination that the terminal is attempting to access; and a linking unit that links the name of the service to communication flow data that includes at least the source IP address and the destination IP address, collected by a flow data collection means, by referring to the TCP session table.

[0012] (2) The associating unit may associate flow data having a common source IP address, source port number, destination IP address, and destination port number with the TCP session table.

[0013] (3) The communication visualization device according to the present invention may register the TCP session table created by the TCP session table creating unit in the data plane.

[0014] (4) The communication visualization device of the present invention may further include a determination unit that determines, based on the domain name detected by the detection unit, whether the service provided by the connection destination that the terminal is attempting to access is subject to visualization, and if the service is subject to visualization, the TCP session table creation unit may create a TCP session table.

[0015] (5) The communication visualization method of the present invention is executed by a computer, and includes the steps of: detecting a domain name of a destination that the terminal is attempting to access by spying on the communication between a terminal and a proxy server; creating a TCP session table using the domain name obtained by spying on the communication between the terminal and the proxy server to create a TCP session table including the name of a service provided by the destination that the terminal is attempting to access; and associating the name of the service with communication flow data, including at least a source IP address and a destination IP address, collected by a flow data collection means by referring to the TCP session table.

[0016] (6) A communication visualization program according to the present invention causes a computer to function as a communication visualization device. [Effects of the Invention]

[0017] According to the present invention, even in a proxy environment, it is possible to associate the name of a service with the flow data collected by sFlow. This makes it possible to visualize communications even in a proxy environment. Furthermore, by managing the information required for visualization on the data plane, it is possible to reduce the increase in processing load caused by visualization. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a diagram illustrating an environment on which an embodiment of the present invention is based. [Figure 2] FIG. 10 is a diagram showing a sequence when LBO of the conventional technology is not performed. [Figure 3] FIG. 1 is a diagram showing a sequence for performing LBO according to the prior art. [Figure 4] 1 is a diagram illustrating functional blocks of a communication visualization device according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating an example of a visualization target domain information table according to the embodiment of the present invention. [Figure 6]FIG. 10 is a diagram illustrating an example of a TCP session table that is created when domain information is the target of visualization and LBO is not performed in an embodiment of the present invention. [Figure 7] FIG. 10 is a diagram illustrating an example of a TCP session table that is created when domain information is the target of visualization and LBO is performed in an embodiment of the present invention. [Figure 8] FIG. 2 is a diagram showing flow data obtained by sFlow and a TCP session table according to an embodiment of the present invention. [Figure 9] FIG. 10 is a diagram illustrating a process of a linking unit according to the embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0019] The applicant of the present application has already disclosed in Patent Document 1 a technique in which a router monitors communications between a terminal and a proxy server. In an embodiment of the present invention, the technology of Patent Document 1 is applied, and the router is configured to refer to the CONNECT method sent by the terminal and identify the access destination based on the domain information included in the CONNECT method.

[0020] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing an environment that is the premise of Patent Document 1 and an embodiment of the present invention. The area represented by the number 100 corresponds to a school or a company. A terminal 10 is connected to the external Internet 40 via a router 20 and a proxy server 30. At the end of the Internet 40 is connected SaaS (Software as a Service) 50, which provides various services via the Internet.

[0021] The DNS (Domain Name System) server 60 is a server used to obtain an IP address from a domain name. The router 20 can use the DNS server 60 without going through the proxy server 30. When LBO (local breakout) is performed, the router 20 connects to the Internet 40 bypassing the proxy server 30, so communication with SaaS 50 follows the route indicated by the dotted line in Figure 1.

[0022] FIG. 2 is a diagram showing a sequence in Patent Document 1 when LBO is not performed. In step S201, a TCP three-way handshake procedure is used to establish a TCP session between the terminal 10 and the proxy server 30. The router 20 spies on the communication between the terminal 10 and the proxy server 30 and acquires TCP parameters.

[0023] Specifically, these TCP parameters are the IP address of terminal 10, the port number of terminal 10, the IP address of proxy server 30, and the port number of proxy server 30. Router 20 then creates a TCP session table using the acquired TCP parameters. Therefore, the created TCP session table has items for the IP address of terminal 10, the port number of terminal 10, the IP address of proxy server 30, and the port number of proxy server 30.

[0024] After step S201, the terminal 10 sends an HTTP CONNECT method to the proxy server 30 with "aaa.com" as the Host. In step S202, the router 20 spies on this communication and detects that the host is "aaa.com." The router 20 compares the detected "aaa.com" with a visualization target domain information table (not shown). The visualization target domain information table is a table held by the router 20, and is a table that collects domain names that are targets for visualization. The visualization target domain information table also contains information on whether or not to perform LBO for each domain. Here, it is assumed that LBO is not to be performed for "aaa.com." Therefore, the router 20 decides not to perform LBO.

[0025] In step S203, the proxy server 30 converts the domain name into an IP address using a DNS server. In step S204, the proxy server 30 establishes a TCP session with the SaaS 50.

[0026] In step S205, the proxy server 30 sends a CONNECT Establish to the terminal 10. In step S206, the proxy server 30 converts the TCP session between the terminal 10 and the proxy server 30 and the TCP session between the proxy server 30 and the SaaS 50 and communicates between them.

[0027] In step S201 above, the router 20 spies on the communication between the terminal 10 and the proxy server 30, acquires TCP parameters, and creates a TCP session table. This TCP session table has the following items: the IP address of the terminal 10, the port number of the terminal 10, the IP address of the proxy server 30, and the port number of the proxy server 30.

[0028] 3 is a diagram showing a sequence for performing LBO in Patent Document 1. The terminal 10, router 20, DNS server 60, proxy server 30, and SaaS 50 are the same as those in FIG. In step S301, a TCP session is established between the terminal 10 and the proxy server 30 using a TCP three-way handshake procedure. The router 20 spies on the communication between the terminal 10 and the proxy server 30 and acquires TCP parameters. At this time, similar to step S201, the router 20 creates a TCP session table using the acquired TCP parameters. At this time, the created TCP session table has items for the IP address of the terminal 10, the port number of the terminal 10, the IP address of the proxy server 30, and the port number of the proxy server 30.

[0029] After step S301, the terminal 10 sends an HTTP CONNECT method to the proxy server 30 with the Host set to "microsoft365.com". In step S302, the router 20 snoops on this communication and detects that the host is "microsoft365.com." The router 20 compares the detected "microsoft365.com" with the visualization target domain information table described above. The visualization target domain information table also contains information on whether or not to perform LBO for each domain. Here, it is assumed that LBO is to be performed for "microsoft365.com." As a result, the router 20 decides to perform LBO.

[0030] In step S303, the router 20 uses the DNS server 60 to convert the domain name into an IP address. In step S304, the router 20 may register the obtained IP address as an LBO route.

[0031] In step S305, the router 20 transmits a synchronization packet of the TCP handshake procedure to the SaaS 50. In step S306, the router 20 establishes a TCP session with SaaS 50. At this time, the router 20 also adds and records the TCP parameters of the session between the router 20 and SaaS 50 in the TCP session table created in S301.

[0032] Specifically, the IP address of the router 20, the port number of the router 20, the IP address of SaaS 50, and the port number of SaaS 50 are added to the TCP session table created in step S301 and entered. Then, the created TCP session table is registered in the data plane of the router 20 as a conversion table between the two sessions (one is the session between the terminal 10 and the proxy server 30, and the other is the session between the router 20 and SaaS 50).

[0033] In step S307, the router 20 sends a CONNECT Establish to the terminal 10. In step S308, the router 20 converts the TCP session between the terminal 10 and the proxy server 30 and the TCP session between the router 20 and the SaaS 50, and transmits the converted session to the breakout destination.

[0034] FIG. 4 is a functional block diagram of the communication visualization device 200 according to this embodiment of the present invention. The communication visualization device 200 includes a control unit 205 and a storage unit 206. Specifically, the control unit 205 is realized by the control unit of the router 20, and the storage unit 206 is realized by the storage unit of the router 20. In other words, the communication visualization device 200 of this embodiment is a part of the router 20.

[0035] The control unit 205 includes a detection unit 210, a determination unit 220, a TCP session table creation unit 230, and a linking unit 240. The storage unit 206 includes a visualization target domain information table 300 and a TCP session table storage unit 350. The sequence of the communication system including the router 20 incorporating the communication visualization device 200 of this embodiment is the same as that shown in Figures 2 and 3. However, the processing content in the router 20 differs from that of the prior art.

[0036] Each functional block of the control unit 205 shown in FIG. 4 is realized by the CPU of the router 20 executing a program stored in a storage unit of the router 20.

[0037] The detection unit 210 monitors the communication between the terminal 10 and the proxy server 30 to detect the domain name of the connection destination. Specifically, the CONNECT method sent by the terminal 10 includes domain information indicating where the terminal 10 is attempting to access, and the detection unit 210 monitors the CONNECT method to detect the domain information. In step S202 or S302, the detection unit 210 detects the domain name of the connection destination.

[0038] The determination unit 220 compares the domain information detected by the detection unit 210 with a visualization target domain information table 300 that collects domain information of visualization targets, and determines whether or not the domain information detected by the detection unit 210 is a target for visualization. In step S202 or S302, the determination unit 220 determines whether or not the detected domain information is a target for visualization. 5 is a diagram showing an example of the visualization target domain information table 300. Domain information to be visualized and names of services (hereinafter, the names of application programs as one form of services will be abbreviated and referred to as application names) are stored.

[0039] If the determination result by the determination unit 220 is a target for visualization, the TCP session table creation unit 230 also records the application name in the TCP session table created by the prior art.

[0040] FIG. 6 is a diagram showing an example of a TCP session table created by TCP session table creating unit 230 when LBO is not performed and the determination result by determining unit 220 is to be visualized. The TCP session table from the IP address of the terminal to the port number of the proxy server in Fig. 6 is also created in the prior art, specifically in step S201 in Fig. 2. A feature of this embodiment is that an item for recording the application name is provided. This application name can be recorded at the timing of step S202 in FIG.

[0041] In the case of two sessions in which the same terminal communicates at different times via the same proxy server, the terminal's IP address, the proxy server's IP address, and the proxy server's port number are the same, but the terminal's port number is different for each session. Therefore, it can be said that the information in the TCP session table, from the IP address of the terminal to the port number of the proxy server, is unique to the session (if it is a different session, it will take a different value).

[0042] FIG. 7 is a diagram showing an example of a TCP session table created by TCP session table creating unit 230 when LBO is performed and the determination result by determining unit 220 is to be visualized. The TCP session table from the IP address of the terminal to the port number of the SaaS in Fig. 7 is also created in the prior art, specifically in step S306 in Fig. 3. Registering the TCP session table of Figure 7 in the data plane of router 20 as a conversion table between two sessions (one is a session between terminal 10 and proxy server 30, and the other is a session between router 20 and SaaS 50) is the same as in the prior art.

[0043] A feature of this embodiment is that an item for recording the application name is provided. The application name can be recorded at any timing after step S302 in FIG. In this case as well, the information in the TCP session table from the IP address of the terminal to the port number of the proxy server is unique for each session.

[0044] A TCP session table is created each time communication is performed, and the created TCP session table is stored in TCP session table storage unit 350.

[0045] The linking unit 240 uses a TCP session table to link the flow data collected by sFlow with the name of the application accessed by that flow. This linking process is performed after communication is performed, using the flow data collected by sFlow and the TCP session table stored in the TCP session table storage unit 350. FIG. 8 is a diagram showing information (flow data) obtained by sFlow and a TCP session table. The flow data 600 collected by sFlow includes information from the source IP address to the destination port number, along with the traffic volume, as shown in Fig. 8. However, this flow data 600 lacks information indicating which application program was accessed in this session. Therefore, the TCP session table 700 created by the router 20 is referenced.

[0046] 9 is a diagram showing the processing of the linking unit 240. The record 800 obtained by sFlow includes a plurality of records. Also, the TCP session table storage unit 350 stores a plurality of records 900.

[0047] The information enclosed by the dotted line, from the source IP address to the destination port number, is unique to each session. Therefore, if the information enclosed by the dotted line is the same, the record obtained by sFlow and the TCP session table are both about the same session. Therefore, the linking unit 240 performs processing to link records having the same information in the portion surrounded by the dotted line. Through the above process, the flow data and the application name can be linked.

[0048] In this embodiment, an example has been described in which the communication visualization method of the present invention is executed in a router, but the communication visualization method of the present invention may also be executed in a computer such as a server existing on the cloud.

[0049] In this embodiment, sFlow has been used as a means for collecting flow data, but other means for collecting flow data, such as NetFlow, SNMP, or IPFIX, may also be used.

[0050] The TCP session table may be registered in the data plane even when LBO as shown in Figure 2 is not performed. When either the terminal 10 or the SaaS 50 ends TCP communication, it may send data such as RST or FIN that triggers the release of the TCP session. The router 20 detects this session release trigger data and synchronizes it with the release of the created TCP session table, thereby preventing the use of unnecessary resources (memory), and thereby reducing the hardware performance required for the router 20. [Explanation of symbols]

[0051] 10 devices 20 Router 30 Proxy Server 40 Internet 50 SaaS 60 DNS servers 200 Communication visualization device 205 Control Unit 206 Memory section 210 Detector 220 Judgment section 230 TCP session table creation unit 240 Binding Section 300 Visualization target domain information table 350 TCP session table storage 400 TCP session table created when LBO is not performed TCP session table created when 500 LBO is performed 600 Information obtained by sFlow 700 TCP Session Table 800 records obtained by sFlow 900 Record stored in TCP session table store

Claims

1. A communication visualization device disposed between a terminal and a proxy server in an environment in which the terminal communicates with the proxy server, comprising: a detection unit that monitors communications between the terminal and the proxy server and detects a domain name of a destination that the terminal is attempting to access; a TCP session table creation unit that uses a domain name obtained by spying on the communication between the terminal and the proxy server to create a TCP session table including the name of a service provided by a destination that the terminal is attempting to access; a linking unit that links the name of the service to communication flow data, including at least a source IP address and a destination IP address, collected by the flow data collecting means by referring to the TCP session table; A communication visualization device equipped with the above.

2. The communication visualization device according to claim 1 , wherein the linking unit links flow data having a common source IP address, source port number, destination IP address, and destination port number with the TCP session table.

3. The communication visualization device according to claim 1 , wherein the TCP session table created by the TCP session table creating unit is registered in a data plane.

4. a determination unit that determines whether a service provided by a destination that the terminal is attempting to access is a target for visualization, based on the domain name detected by the detection unit; The communication visualization device according to claim 1 , wherein the TCP session table creation unit creates a TCP session table when the service is a target for visualization.

5. a detection step of detecting a domain name of a destination that the terminal is attempting to access by observing communication between the terminal and the proxy server; a TCP session table creation step of creating a TCP session table including the name of a service provided by a destination that the terminal is attempting to access, using a domain name obtained by snooping on the communication between the terminal and the proxy server; a linking step of linking the name of the service to communication flow data, including at least a source IP address and a destination IP address, collected by the flow data collecting means by referring to the TCP session table; A computer-implemented communication visualization method.

6. A communication visualization program for causing a computer to function as the communication visualization device according to any one of claims 1 to 4.

Citation Information

Patent Citations

  • Relay device and local breakout transfer method

    JP7178522B2