NAT device access method based on TTL value and related device

Abstract

The application discloses a NAT device management method based on TTL value and related equipment, and relates to the technical field of NAT device management, which comprises the following steps: issuing TTL configuration instructions to each terminal located behind a NAT device and in compliance, and obtaining uplink data packets sent by each terminal to an external network; obtaining TTL values in the IP header of each uplink data packet, combining TTL values set by the operating system on each terminal, respectively identifying whether each uplink data packet is from a terminal located behind the NAT device and in compliance, and obtaining an identification result corresponding to each uplink data packet; and respectively operating each uplink data packet according to the identification result corresponding to each uplink data packet. The application overcomes the defects of dynamic control failure, user experience fragmentation and dependence on specific protocols or equipment in the prior art.

Description

Technical Field

[0001] This invention relates to the field of NAT device management technology, and in particular to a method for managing NAT devices based on TTL values ​​and related equipment. Background Technology

[0002] Current network access control technologies primarily rely on terminal device authentication, Internet Protocol address (IPA) whitelisting, or access control policies based on Media Access Control (MAC) addresses. In Network Address Translation (NAT) scenarios, because multiple terminals share the same public IPA address, traditional technologies have significant limitations: they cannot distinguish between different terminals located behind the same NAT device, resulting in a lack of dynamic terminal identification and control capabilities. Unauthenticated terminals may bypass control and directly access the network, expanding network exposure. Furthermore, existing solutions typically require terminals to actively perform authentication interactions, interrupting business continuity and resulting in a poor user experience. In addition, many solutions rely on NAT devices supporting specific extended protocols or on plaintext traffic characteristics, making them difficult to adapt to encrypted traffic environments and complex network deployments.

[0003] According to patent search analysis, the closest existing technical solutions include: Patent CN102761869A discloses an 802.1X authentication method and device, which works by authenticating access terminals using Scalable Authentication Protocol (SPA) and Local Area Network Protocol (LAN) protocols, combined with remote authentication dial-up user service server authorization of access permissions; Patent CN119011496A discloses a traffic-based terminal device management method and system, which works by analyzing traffic protocol characteristics through deep packet inspection, such as the user agent field of Hypertext Transfer Protocol (HTTP), to identify terminal types and implement policies; and Patent CN101557388A discloses a network address translation (NAT) traversal method based on Universal Plug and Play (UPP) and Session Traversal Applications (STA) protocols, which works by establishing a NAT port mapping table using UPP or STA protocols, combined with session tracking to achieve terminal identification.

[0004] The aforementioned existing technologies have the following drawbacks: First, dynamic terminal management fails. Under NAT devices, traditional technologies cannot detect unauthenticated terminal access in real time, leading to an expanded network exposure surface. Second, user experience is disrupted. Existing solutions require terminals to perform authentication interactions, interrupting business continuity and failing to distinguish client installation status. Third, they rely on specific protocols or devices. NAT devices need to support extended protocols such as general plug-and-play, or rely on plaintext traffic characteristics such as Hypertext Transfer Protocol header fields, making it difficult to adapt to encrypted traffic environments. Furthermore, deep packet inspection processing has high latency and cannot meet real-time requirements. Summary of the Invention

[0005] This invention aims to address the shortcomings of existing technologies by providing a method for managing NAT devices based on TTL values ​​and related equipment, as detailed below: 1) In a first aspect, the present invention provides a method for managing NAT devices based on TTL values, the specific technical solution of which is as follows: TTL configuration instructions are sent to each compliant terminal located behind the NAT device. The TTL configuration instructions are used to: modify the TTL field value of all outgoing IP packets sent by the compliant terminal located behind the NAT device to a preset flag value, which is greater than the TTL value set by the operating system on the terminal. Obtain the uplink data packets sent from each terminal to the external network; Obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, and obtain the identification result corresponding to each uplink data packet; Based on the identification results corresponding to each uplink data packet, operations are performed on each uplink data packet separately.

[0006] The beneficial effects of the NAT device management method based on TTL values ​​provided by this invention are as follows: By issuing TTL configuration commands to each compliant terminal located behind a NAT device, the compliant terminal modifies the TTL field value of all outgoing Internet Protocol (IP) packets to a preset flag value. This preset flag value is greater than the TTL value set by the terminal's operating system. This establishes identifiable traffic markings for compliant terminals without relying on NAT device functionality expansion or interrupting service traffic. By acquiring uplink packets sent to the external network from each terminal, extracting the TTL value of each uplink packet, and combining it with the TTL value set by the operating system on each terminal, it identifies whether each uplink packet originates from a compliant terminal located behind a NAT device. This identification result allows for accurate differentiation between compliant terminals and unauthenticated or unauthorized terminals when multiple terminals share the same public IP address, achieving dynamic terminal identification and control. Based on the identification result, each uplink packet is allowed, blocked, or redirected to the authentication portal. This ensures the continuity of compliant terminal services while automatically blocking unauthorized terminal access, avoiding manual intervention. Furthermore, it does not rely on specific protocols or plaintext traffic characteristics and supports encrypted traffic environments, thus overcoming the shortcomings of existing technologies such as dynamic control failure, fragmented user experience, and reliance on specific protocols or devices.

[0007] Based on the above scheme, the NAT device management method based on TTL value of the present invention can be further improved as follows.

[0008] Furthermore, the process of determining whether each terminal is behind a NAT device includes: obtaining the local private network IP address reported by each terminal, and obtaining the public network IP address of the peer end of the network connection established with each terminal; for each terminal, determining whether the local private network IP address of the terminal and the public network IP address of the peer end of the terminal are in the same network segment; if not, determining that the terminal is behind a NAT device.

[0009] The beneficial effects of adopting the above-mentioned further solution are as follows: By obtaining the local private network Internet Protocol (IP) address reported by each terminal and the public IP address of the peer network connection established with each terminal, it is determined whether the two are in the same network segment. If not, the terminal is determined to be behind a NAT device. This determination process does not require modification of the NAT device configuration, does not rely on the device supporting any extended protocols, and can be completed simply by comparing the terminal's self-reported address with the server's received address. It can accurately identify terminals behind NAT devices, thereby triggering cross-NAT device processing, providing accurate prerequisites for subsequently issuing TTL configuration commands to compliant terminals, avoiding unnecessary marking operations on terminals in non-NAT environments, and improving the applicability and deployment efficiency of the solution.

[0010] Furthermore, the identification result corresponding to each uplink data packet is obtained, including: for each terminal, determining the attenuation value corresponding to that terminal, the attenuation value being the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received; wherein, for compliant terminals, the initial TTL value is a preset flag value, and for unauthenticated or unauthorized terminals, the initial TTL value is the TTL value set by the terminal's operating system; for each uplink data packet, if the obtained TTL value is equal to the preset flag value minus the attenuation value corresponding to the terminal that sent the uplink data packet, then the uplink data packet is determined to originate from a compliant terminal located behind the NAT device, and the identification result corresponding to the uplink data packet is yes; if the obtained TTL value is equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to that terminal, then the uplink data packet is determined to originate from an unauthenticated or unauthorized terminal, and the identification result corresponding to the uplink data packet is no.

[0011] The beneficial effects of adopting the above-mentioned further scheme are: this identification process compensates for the hop count attenuation during data packet transmission by attenuation value, does not rely on NAT device functions or plaintext traffic characteristics, and can be completed using only inherent fields in the packet header. It can distinguish between compliant and illegal traffic from multiple terminals sharing the same public Internet Protocol address in real time and accurately, providing a clear basis for subsequent differentiated operations.

[0012] Furthermore, based on the identification result corresponding to each uplink data packet, operations are performed on each uplink data packet, including: allowing uplink data packets from compliant terminals, blocking traffic from unauthenticated or non-compliant terminals, or redirecting traffic to the authentication portal.

[0013] The beneficial effects of adopting the above-mentioned further solution are as follows: By performing differentiated operations on uplink data packets based on the identification results, uplink data packets from compliant terminals are allowed to pass through, ensuring that the business traffic of compliant terminals is forwarded to the external network without any interference, achieving seamless access control; traffic from unauthenticated or non-compliant terminals is blocked or redirected to the authentication portal, automatically preventing unauthorized terminals from accessing network resources or guiding them to complete compliance authentication. This differentiated processing method requires no manual intervention and does not rely on active authentication interaction from terminals. While ensuring the continuity of compliant terminal services, it effectively isolates illegal traffic, overcoming the shortcomings of traditional solutions such as forced service interruption and poor user experience, and improving the automation level and availability of network access control.

[0014] Furthermore, the process of verifying the compliance of terminals includes: for each terminal, receiving the terminal security check results reported by the terminal, including the running status of antivirus software, the installation status of operating system patches, and the integrity of policy files. When the terminal security check results all meet the preset security baseline, the terminal is determined to be a compliant terminal.

[0015] The beneficial effects of adopting the above-mentioned further solution are as follows: By receiving terminal security check results reported by each terminal, including the running status of antivirus software, the installation status of operating system patches, and the integrity of policy files, and comparing these three results with a preset security baseline, a terminal is determined to be compliant only if all three are met. This compliance determination process comprehensively evaluates terminals from three dimensions: antivirus software protection, system patch security, and policy file trustworthiness, ensuring that only terminals that meet the minimum security requirements can obtain compliant status and be further issued TTL configuration commands. Simultaneously, the compliance determination result serves as the benchmark for subsequent dynamic recovery. When any of the terminal's statuses no longer meets the preset security baseline, it will be removed from the compliant set, thereby ensuring that all terminals accessing the network are always in a secure and controllable state in real time, effectively preventing insecure terminals from posing a threat to the network.

[0016] Furthermore, it also includes: for each terminal, receiving terminal status change information reported in real time during operation; when the terminal status change information indicates that any one of the terminal's antivirus software running status, operating system patch installation status, or policy file integrity no longer meets the preset security baseline, issuing a TTL recovery instruction to the terminal; the TTL recovery instruction is used to instruct the terminal to restore the TTL value of all outgoing IP data packets to the TTL value set by the operating system on the terminal.

[0017] The beneficial effects of adopting the above-mentioned further solution are as follows: By receiving terminal status change information reported in real time during operation, when the terminal status change information indicates that any one of the following—antivirus software running status, operating system patch installation status, or policy file integrity—no longer meets the preset security baseline, a TTL recovery command is issued to the terminal, instructing the terminal to restore the TTL value of all outgoing Internet Protocol (IP) data packets to the TTL value set by the operating system. This process achieves real-time perception and automatic response to changes in terminal security status, without waiting for periodic reporting or manual intervention. Once a compliant terminal commits a security violation, its Time-to-Live (TTL) marker is immediately revoked, and the TTL value of subsequent uplink data packets received by the network side becomes the operating system's default value, thus identifying it as a violating terminal and executing blocking or redirection operations. This ensures that the access control policy remains synchronized with the real-time security status of the terminal, effectively preventing the abuse of compliance markers.

[0018] Furthermore, it also includes: continuously monitoring the TTL value in the IP header of each uplink data packet; when the TTL value corresponding to an uplink data packet whose previous identification result was yes changes from being equal to a preset flag value minus the attenuation value corresponding to the terminal to which the uplink data packet belongs to becoming equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, the identification result of the terminal is updated to no, and subsequent uplink data packets from the terminal are blocked or redirected to the authentication portal; wherein, the attenuation value corresponding to the terminal is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. For compliant terminals, the initial TTL value is the preset flag value, and for unauthenticated or non-compliant terminals, the initial TTL value is the TTL value set by the operating system of the terminal.

[0019] The beneficial effects of adopting the above-mentioned further scheme are as follows: By continuously monitoring the TTL value of each uplink data packet, when the TTL value corresponding to an uplink data packet whose previous identification result was "yes" changes from being equal to the preset flag value minus the attenuation value corresponding to the terminal to which the uplink data packet belongs to becoming equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, the identification result of the terminal is updated to "no", and subsequent uplink data packets from that terminal are blocked or redirected to the authentication portal. This process takes into account path attenuation. By comparing the expected value after attenuation, the loss of compliance flags can be accurately detected. It does not rely on the terminal actively reporting status changes, but passively discovers changes in TTL values ​​through real-time traffic analysis on the network side, automatically switches the identification result and immediately applies control measures, eliminating response time differences, avoiding the risk of unauthorized terminals continuing to access the network by taking advantage of the time window, and improving the real-time performance and reliability of access control.

[0020] 2) Secondly, the present invention also provides a NAT device management system based on TTL values, the specific technical solution of which is as follows: It includes a command issuance module, an acquisition module, an identification module, and an operation module; The instruction issuing module is used to issue TTL configuration instructions to each compliant terminal located behind the NAT device. The TTL configuration instructions are used to modify the TTL field value of all IP packets sent out by the compliant terminal behind the NAT device to a preset flag value, which is greater than the TTL value set by the operating system on the terminal. The acquisition module is used to: acquire uplink data packets sent by each terminal to the external network; The identification module is used to: obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, and obtain the identification result corresponding to each uplink data packet; The operation module is used to perform operations on each uplink data packet according to the identification result corresponding to each uplink data packet.

[0021] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to enable the electronic device to implement any of the above-mentioned NAT device management methods based on TTL values.

[0022] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned NAT device management methods based on TTL values.

[0023] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is a flowchart illustrating a method for managing NAT devices based on TTL values ​​according to an embodiment of the present invention. Figure 2 This is a network deployment diagram corresponding to the network address translation device management method based on time-to-live value in this embodiment of the invention; Figure 3 This is a schematic diagram illustrating the business interaction and data packet processing timing between the terminal and the access control server in an embodiment of the present invention; Figure 4 This is a schematic diagram of a NAT device management system based on TTL values ​​according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0025] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0026] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0027] like Figure 1 As shown in the figure, a method for managing NAT devices based on TTL values ​​according to an embodiment of the present invention includes the following steps: S1. Issue a TTL configuration command to each compliant terminal located behind the NAT device. The TTL configuration command is used to: modify the TTL field value of all outgoing IP packets sent by the compliant terminal behind the NAT device to a preset flag value. The preset flag value is greater than the TTL value set by the operating system on the terminal. The specific implementation process is as follows: S10. The server maintains multiple attribute fields for each terminal in the terminal information table, including the determination result of whether the terminal is behind a NAT device and the determination result of whether the terminal is a compliant terminal. The server traverses all records in the terminal information table. For each record, the server checks whether the flag field for "behind a NAT device" is marked as "yes," and simultaneously checks whether the flag field for "compliant terminal" is marked as "yes." Only when both conditions are met—that is, the terminal is both behind a NAT device and determined by the server to be a compliant terminal—is the server included in the target set for which TTL configuration commands need to be issued. For terminals that do not meet either condition, such as terminals behind a NAT device but not determined to be compliant, or terminals determined to be compliant but not behind a NAT device, the server does not issue TTL configuration commands to these terminals. The server (also known as the admission control server) is one of the execution subjects of the method of this invention. In this embodiment, the method of this invention is described using the server as an example.

[0028] S11. The server reads a preset flag value from the configuration parameters. In this embodiment, the preset flag value is set to 200. The server constructs a TTL configuration command message according to the application layer protocol format agreed upon between the server and the terminal. The message header contains a message type field, the value of which is set to a special identifier representing the TTL configuration command. The message payload contains an integer field to carry the preset flag value 200. The server may also attach a checksum field to the message for the terminal to verify whether the message has been corrupted during transmission. After the message is constructed, the server places it in the send queue, ready to send it to the corresponding terminal via the network connection.

[0029] S12. The server maintains an independent Transmission Control Protocol (TCP) connection for each selected terminal, established during the terminal's initial registration. The server retrieves the network connection handle for each terminal from the terminal information table and then sends the constructed TTL configuration command message through this connection. The server uses a reliable TCP connection to ensure the message arrives at the terminal intact. The server performs the sending operation independently for each terminal. If a network error occurs during transmission, the server will retry, for example, resending the same TTL configuration command message up to three times, until it receives an acknowledgment response from the terminal or exceeds the retry limit.

[0030] S13. The client program on the terminal continuously listens for messages sent by the server. When the client program receives a complete message from the network connection, it first parses the message header to identify the message type field. If the value of the message type field is the identifier of the TTL configuration command, the client program further extracts a preset flag value from the message payload. The client program stores the extracted preset flag value in a local memory variable and records the timestamp of receiving this preset flag value. After successfully parsing the command, the client program sends an acknowledgment message to the server, informing the server that the TTL configuration command has been correctly received.

[0031] S14. Before modifying the Time-to-Live (TTL) field, the client program needs to read the default TTL value set by the current operating system. The client program calls the network protocol stack parameter query interface provided by the operating system. In Windows systems, the client program can obtain this value by reading the registry key for the default TTL value, or by calling the application programming interface for retrieving Internet Protocol header options information. In Linux operating systems, the client program can obtain the default TTL value by reading relevant parameters in the system control file, such as reading a specific file in the virtual file system. The client program saves the TTL value set by the operating system locally for later verification of whether the preset flag value is indeed greater than this value.

[0032] S15. The client program compares the received preset flag value 200 with the TTL value set by the operating system read in the previous step. Assuming the TTL value set by the operating system is 128 (Windows system) or 64 (Linux system), the client program checks if 200 is greater than 128 or greater than 64. Since 200 is significantly greater than the common default TTL value, the verification passes. If, for some reason, the preset flag value is not greater than the TTL value set by the operating system, the client program will refuse to perform the modification operation and report an error message to the server. After successful verification, the client program sets the preset flag value 200 as the final target value for subsequent modification operations.

[0033] S16. The client program modifies the default behavior of the Time-to-Live (TTL) field through the network protocol stack programming interface provided by the operating system. At the underlying implementation level, the client program can complete the modification in two ways. The first way is to modify the global network parameters of the operating system, that is, to modify the default TTL value stored in the system kernel, changing the default value from 128 or 64 to 200. After the modification, every Internet Protocol (IP) data packet subsequently sent by all applications on the terminal, including the client program itself, will automatically use 200 as the value of the TTL field. The second way is to specify the TTL value separately through socket options when the client program sends data packets, without modifying the system's global settings. The client program chooses the first method to ensure that all outgoing data packets from the terminal, including those generated by the operating system itself, are marked with the preset mark value. The client program calls the system interface that requires administrator privileges to perform the modification operation. After successful modification, the client program records a status flag locally, indicating that the TTL configuration command has taken effect. Thereafter, as long as the terminal remains compliant, the TTL field of every IP data packet sent by the terminal will be set to 200.

[0034] The TTL configuration command is a structured command message sent by the server to the terminal, instructing the terminal to modify the Time-to-Live (TTL) field value in all Internet Protocol (IP) data packets it sends out. This command consists of two core components: an operation type identifier and a preset flag value. The operation type identifier informs the terminal that the current command is to modify the TTL field value, while the preset flag value specifies the exact number the terminal needs to change the TTL field to. The TTL configuration command is sent from the server to the terminal via the network connection in the form of a Transmission Control Protocol (TCP) message. After receiving the command, the terminal parses the preset flag value and adjusts its data packet sending behavior accordingly.

[0035] The preset flag value is a pre-agreed positive integer used to replace the default value of the Internet Protocol (IP) data packet time-to-live (TTL) field originally set by the terminal's operating system. The specific value of this preset flag is determined uniformly by the server and distributed to all compliant terminals. The preset flag value must be greater than the TTL value set by the terminal's operating system. For example, if the terminal's operating system's default TTL value is 64 or 128, the preset flag value can be set to 200. By using a preset flag value greater than the default value, the server can clearly distinguish data packets sent by compliant terminals from those sent by ordinary terminals whose TTL values ​​have not been modified, because the TTL field of data packets sent by compliant terminals always displays a significantly higher value than the usual value during network transmission.

[0036] The TTL value set by the operating system refers to the default time-to-live (TTL) value assigned by the operating system kernel to each outgoing Internet Protocol (IP) data packet during network protocol stack initialization. Different operating systems use different default TTL values. For example, Windows systems typically set the default TTL value to 128, Linux-based operating systems typically set it to 64, while some network device operating systems may set it to 255. The TTL value set by the operating system is stored in the network protocol stack parameters of the system kernel. If the application does not actively modify the TTL field when sending data packets, the kernel will automatically use this default value to fill in the TTL field of each sent data packet. Client programs on the terminal can read this default value from the operating system, modify it, or specify a TTL value individually for each data packet.

[0037] S2. Obtain the uplink data packets sent by each terminal to the external network. The specific implementation process is as follows: S20. The server needs to connect near the core switch in the network to acquire uplink data packets sent to the external network from all terminals. In the enterprise campus network topology, all uplink data packets from terminals inevitably pass through the core switch on their way to the NAT device and the external network. The server connects one of its network interfaces to an unused Ethernet port on the core switch via an Ethernet cable. This port will be configured to receive mirrored traffic. The server configures this network interface with an Internet Protocol (IP) address that does not conflict with the existing network, or it can be left unconfigured and used only for receiving data packets. The core switch port to which the server connects will serve as the destination port for the mirrored traffic.

[0038] S22. The network administrator logs into the core switch's command-line or graphical management interface and enters the switch's global configuration mode. The administrator selects the source ports that connect to all internal network traffic as the objects to be mirrored. Specifically, the administrator selects the ports on the core switch that are connected to the internal network aggregation layer switches; these ports carry all data traffic from the terminal subnets to the core layer. The administrator can also select ports on the core switch that are connected to NAT devices or egress routers, because all uplink packets will eventually be forwarded from these ports. The administrator enters the port mirroring configuration command, specifying the direction of the source port as the direction of transmission from the internal network to the external network (i.e., the uplink direction), and specifying the destination port as the port connected to the server. After configuration, the core switch begins to copy the uplink packets received by each source port and send them out from the destination port.

[0039] S23. The server enables packet capture on the network interface connected to the mirror port of the core switch. The server calls the low-level network programming interface provided by the operating system, such as the packet socket interface in Linux, and the raw socket interface or network driver interface specification in Windows. The server sets the network interface to promiscuous mode, which allows the network interface to receive all packets arriving at the port, not just those destined for the local machine. The server creates a receive buffer to temporarily store raw packets captured from the network. The server also sets a filter to capture only Internet Protocol version 4 (IP4) packets, ignoring other types of packets such as Address Resolution Protocol (ARP) packets, to reduce unnecessary data processing overhead.

[0040] S24. The server initiates a loop process, repeatedly calling the packet capture function within this loop. Each time the packet capture function is called, the server waits until a new packet arrives at the mirror port. When the core switch sends a packet through the mirror port, the server's network interface receives the packet and passes it to the operating system's network protocol stack. The server's packet capture function extracts the complete Ethernet frame from the network protocol stack; the Ethernet frame encapsulates the Internet Protocol (IP) data packet. The server strips the Ethernet frame header, retaining only the IP data packet portion. The server stores each received IP data packet, along with its timestamp, into a memory buffer, forming a packet queue. This process runs continuously, ensuring that all uplink packets from the core switch's mirror port are captured by the server.

[0041] S25. Since the server obtains all uplink data packets passing through the core switch, these packets may originate from multiple terminals behind the NAT device or from terminals in other network areas. The server needs to distinguish which terminal sent each uplink data packet. The server extracts the source Internet Protocol address (IPA) field from the IPA header of each uplink data packet. For terminals behind the NAT device, all terminals share the same public IPA address of the NAT device; therefore, the source IPA alone cannot distinguish different terminals. However, the server can combine other information for identification, such as the source port number of Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), and the Time-to-Live (TTL) field value of the data packet. In subsequent steps, the server uses the TTL field value to distinguish between compliant and non-compliant terminals. For uplink data packets with a TTL field value of the preset flag value 200, the server can associate them with the previously identified compliant terminals.

[0042] S26. During the reception of each uplink data packet, the server records the reception order, timestamp, length, and key fields in the packet header. The server organizes this information into a record and stores it in a circular buffer in chronological order of reception. The server sets a data packet processing threshold; when the number of packets accumulated in the buffer reaches a certain number or a certain time interval has elapsed, the server triggers the subsequent Time-to-Live (TTL) field value analysis process. The server also monitors for errors during packet capture, such as packet loss due to network interface buffer overflow. If packet loss occurs, the server adjusts the packet capture parameters, increasing the buffer size or optimizing the processing speed to ensure that every uplink data packet is acquired without losing critical information. Through these steps, the server completely acquires the uplink data packets sent from each terminal to the external network, providing a data foundation for subsequent TTL field value identification and access control decisions.

[0043] Uplink data packets refer to Internet Protocol (IP) data packets sent by a terminal from its internal network to the external network. When a terminal needs to access servers or internet resources on an external network, it encapsulates the data into IIP packets. The source address of the packet is either the terminal's local private network IIP address or a public IIP address translated by a NAT device, and the destination address is the IIP address of the external server. Uplink data packets are transmitted along a path from the terminal to the core switch, then to the NAT device, and finally to the external network. During transmission, uplink data packets pass through specific ports on the core switch, which connect to the NAT device or the external network. Obtaining uplink data packets is a prerequisite for network access control, as only by analyzing the uplink data packets sent by the terminal can its compliance be determined.

[0044] A mirror port is a special port operating mode configured on a network switch to copy traffic from one or more source ports and send it to a specified destination port. The mirror port itself is a physical port. When the switch receives data packets entering or leaving from the source port, its internal processing logic copies the content of these packets and sends the copied packets out through the mirror port without affecting the normal forwarding of the original packets. Devices connected to the mirror port can receive all network traffic passing through the source port without interfering with the original communication. Mirror ports are also often called monitoring ports or observation ports and are widely used in network traffic analysis, security monitoring, and intrusion detection scenarios.

[0045] Core switches are high-performance network switching devices deployed at the core layer of enterprise campus networks or data center networks. They are responsible for high-speed forwarding of data packets between different subnets and between internal and external networks. Core switches connect multiple access layer switches, server areas, NAT devices, and egress routers. All uplink data packets sent from terminals to the external network must be forwarded through the core switch. The core switch determines whether to forward the data packet to a NAT device or directly to the egress router based on the destination Internet Protocol address (IPA address). Core switches have multiple Gigabit or 10 Gigabit Ethernet ports and support advanced functions such as virtual LAN segmentation, access control lists, and port mirroring, making them ideal deployment locations for network traffic monitoring and access control.

[0046] The external network refers to the external network space as opposed to the internal network, typically including the internet and untrusted network areas outside the enterprise. In a network environment based on NAT devices, the external network is located on the public network side of the NAT device. All data packets sent from internal network terminals to the external network must undergo source address translation through the NAT device. When a terminal accesses the external network, the server on the external network can only see the public Internet Protocol (IP) address presented by the NAT device, and cannot directly see the terminal's local private IP address. Resources on the external network include web servers, mail servers, cloud service platforms, and external services of enterprise branch offices. One of the goals of network access control is to monitor and filter uplink data packets sent from terminals to the external network. For compliant terminals, normal access to external network resources is allowed; for unauthenticated or unauthorized terminals, their traffic to the external network is blocked or they are redirected to the authentication portal page.

[0047] S3. Obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, obtaining the identification result corresponding to each uplink data packet. Specifically, for each terminal, determine the attenuation value corresponding to that terminal. The attenuation value is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. Among them, for compliant terminals, the initial TTL value is a preset flag value; for unauthenticated or non-compliant terminals, the initial TTL value is the TTL value set by the operating system of that terminal. For each uplink data packet, if the obtained TTL value is equal to the preset flag value minus the attenuation value corresponding to the terminal that sent the uplink data packet, then it is determined that the uplink data packet comes from a compliant terminal located behind the NAT device, and the identification result corresponding to the uplink data packet is yes; if the obtained TTL value is equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to that terminal, then it is determined that the uplink data packet comes from an unauthenticated or non-compliant terminal, and the identification result corresponding to the uplink data packet is no. The specific implementation process is as follows: S30. The server maintains a series of uplink data packets captured from the mirror port of the core switch in a memory buffer. For each uplink data packet in the buffer, the server locates the beginning of the Internet Protocol (IP) header. The first byte of the IP header contains the version number and header length, the second byte contains the Differential Service Code Point (DSC), the third and fourth bytes contain the total length, the fifth byte contains the identifier, the sixth and seventh bytes contain the flags and fragment offset, and the eighth byte contains the Time to Live (TTL). The server directly reads the value of the eighth byte, which is the TTL value of the current uplink data packet. The server stores this value in a temporary variable for later comparison with a preset flag value and the TTL value set by the operating system.

[0048] S31. The server determines the attenuation value for each terminal. The server maintains an attenuation value field for each terminal in the terminal information table. For compliant terminals, when a terminal is first identified as compliant and a data packet with a preset flag value of 200 is received, the server calculates the attenuation value as follows: Attenuation value = Preset flag value - Actual received TTL value, and stores this attenuation value in the terminal information table. For unauthenticated or non-compliant terminals, when the server first receives their data packet, it calculates the attenuation value as follows: Attenuation value = Operating system TTL value - Actual received TTL value, based on the TTL value set by the operating system (assuming 128 or 64) and the received TTL value, and stores this value. When the server processes an uplink data packet, it first identifies the terminal that sent the packet, and then reads the corresponding attenuation value from the terminal information table. Simultaneously, the server also reads the TTL value set by the terminal's operating system.

[0049] For example, for a compliant terminal, the server sends it a preset tag value of 200, so the initial TTL value when the terminal sends a data packet is 200. The data packet arrives at the server after passing through three Layer 3 devices, with the TTL value decreasing by 1 for each device. The server actually receives a TTL value of 197, so the corresponding attenuation value for this terminal is 200 - 197 = 3. For another unauthenticated terminal, its operating system sets the TTL value to 64, and the server actually receives its data packet with a TTL value of 61, so the corresponding attenuation value for this terminal is 64 - 61 = 3. Subsequently, for subsequent uplink data packets from the compliant terminal, the server identifies compliant traffic by checking if the actual received TTL value equals 200 - 3 = 197; for subsequent uplink data packets from the unauthenticated terminal, the server identifies unauthentic traffic by checking if the actual received TTL value equals 64 - 3 = 61.

[0050] S32. The server reads the preset flag value of 200 from the configuration parameters. For the current uplink data packet, the server calculates the expected compliance TTL value = preset flag value - attenuation value corresponding to the terminal. The server compares the TTL value extracted from the uplink data packet with the expected compliance TTL value for equality. Since the attenuation value already takes into account the path hop count, the equality comparison can be used directly to accurately determine whether the data packet originates from a compliant terminal, without the need for additional fault tolerance.

[0051] S33. If the TTL value of the uplink data packet equals the expected compliant TTL value (i.e., the preset flag value minus the attenuation value corresponding to the terminal), the server determines that the uplink data packet comes from a compliant terminal located behind the NAT device. The server sets the identification result to "Yes". The server also records this determination result and the TTL value on which the determination is based. The server stores this identification result in association with other information of the uplink data packet for subsequent flow control operations. The server can also update the most recent active timestamp of the corresponding terminal in memory, indicating that the compliant terminal is still online and continues to send flagged traffic.

[0052] S34. If the TTL value of the uplink data packet is not equal to the expected compliant TTL value, the server further calculates the expected unauthenticated TTL value: TTL value set by the terminal's operating system - attenuation value corresponding to the terminal. The server compares the TTL value extracted from the uplink data packet with the expected unauthenticated TTL value for equality. If they are equal, the data packet is determined to originate from an unauthenticated terminal or a non-compliant terminal.

[0053] S35. If the TTL value of the uplink data packet equals the expected unauthenticated TTL value (i.e., the TTL value set by the operating system of the terminal sending the uplink data packet minus the corresponding attenuation value of the terminal), the server determines that the uplink data packet comes from an unauthenticated terminal or a non-compliant terminal. The server sets the identification result to "No". The server further distinguishes whether the data packet comes from an unauthenticated terminal or a non-compliant terminal. If there is no record of this terminal in the server's terminal information table, or if the terminal has never been identified as a compliant terminal, the server classifies it as an unauthenticated terminal. If there is a record of this terminal in the server's terminal information table and the terminal was previously identified as a compliant terminal, but the currently received data packet shows that the TTL value is no longer the preset mark value but has reverted to the TTL value set by the operating system, the server classifies it as a non-compliant terminal. The server records the identification result of "No" and the corresponding terminal classification information in the log.

[0054] S36. If the TTL value of an uplink data packet is neither equal to the expected compliant TTL value nor the expected unauthenticated TTL value, the server performs exception handling. This may occur if the network path through which the data packet passes contains a large number of routers, causing the TTL value to decrease excessively, or if the data packet originates from an unknown type of terminal. The server temporarily sets the identification result of the uplink data packet to "No" to ensure security, and simultaneously records a warning event containing information such as the source Internet Protocol address, TTL value, and reception timestamp of the uplink data packet for subsequent analysis by the network administrator. For all uplink data packets with an identification result of "No", the server will perform blocking or redirection operations in subsequent steps. The server independently executes the above judgment process for each received uplink data packet, generating a corresponding identification result for each uplink data packet.

[0055] The TTL value, or Time to Live value, is an 8-bit binary integer field in the header of an Internet Protocol (IP) data packet, used to limit the maximum number of hops a data packet can be forwarded in the network.

[0056] Uncertified terminals refer to terminal devices that have not completed or failed the server-side security check. Uncertified terminals may not have a client program installed at all, thus failing to report terminal security check results to the server; or they may have a client program installed but have not completed the registration process, so the server has not received any information from the terminal; or the terminal may have completed registration but the reported terminal security check results do not meet the preset security baseline, therefore it has not been determined as a compliant terminal by the server. Uplink data packets sent by uncertified terminals retain the original TTL value set by the operating system, such as 128 or 64, because these terminals have not received TTL configuration instructions, or have received instructions but are not authorized to perform TTL value modification operations.

[0057] In this context, a "non-compliant terminal" refers to a terminal device that was initially identified as compliant by the server but no longer meets the preset security baseline requirements during subsequent operation. The non-compliant terminal initially received a TTL configuration command from the server and modified the Time-to-Live (TTL) field value of all outgoing Internet Protocol (IP) packets to the preset flag value of 200. When any of the following changes occur, causing the terminal to no longer meet the preset security baseline: the antivirus software's running status, the operating system's patch installation status, or the integrity of the policy file, the server issues a TTL recovery command to the terminal. After executing the TTL recovery command, the non-compliant terminal restores the TTL value of all outgoing IP packets to the original TTL value set by the operating system. At this point, the TTL value of the uplink packets sent by the non-compliant terminal changes from the expected compliant TTL value (i.e., the preset flag value of 200 minus the terminal's corresponding attenuation value) back to the expected uncertified TTL value (i.e., the TTL value set by the operating system minus the terminal's corresponding attenuation value). The server, by detecting the change in TTL value, re-marks the previously compliant terminal as a non-compliant terminal.

[0058] S4. Based on the identification result corresponding to each uplink data packet, perform operations on each uplink data packet. Specifically, allow uplink data packets from compliant terminals, and block or redirect traffic from unauthenticated or unauthorized terminals to the authentication portal. The specific implementation process is as follows: S40. After identifying each uplink data packet, the server obtains an identification result value, which is either "yes" or "no". The server places uplink data packets with an identification result of "yes" into one queue and uplink data packets with an identification result of "no" into another queue. The server processes the data packets in the two queues respectively, allowing the data packets with an identification result of "yes" and deciding whether to block or redirect the data packets with an identification result of "no" to the authentication portal based on their traffic type.

[0059] S41. For uplink data packets whose identification result is "yes," it means that the data packet originates from a compliant terminal located behind a NAT device. The server does not modify or discard these data packets. The server releases these data packets from the packet capture buffer, allowing them to continue being forwarded in the core switch along the normal switching path. Specifically, the server does not add any rules to the core switch's access control list that block the source address or source port of the data packet, nor does it interfere with the normal forwarding process of the data packet in any way. These data packets retain their original Internet Protocol header and Transmission Control Protocol header content, and are transmitted normally along the path from the core switch to the NAT device and then to the external network. The allow operation ensures that uplink data packets from compliant terminals can reach the external network without delay or interruption, guaranteeing the business continuity of end users.

[0060] S42. For uplink data packets with a "No" identification result, the server first checks whether the data packet belongs to the Hypertext Transfer Protocol (HTTP) traffic. The server determines this by checking the Transmission Control Protocol (TCP) port number. If the destination port number of the data packet is 80, the server identifies it as an HTTP request. The server can also confirm this by deeply parsing the request method field in the data packet payload, for example, by checking whether the first few bytes of the data packet are HTTP method names such as GET, POST, PUT, and DELETE. For HTTP security protocol (HTTP) traffic with a destination port number of 443, since the encrypted payload cannot be parsed, the server cannot perform the redirection to the authentication portal operation, so it is directly classified as traffic requiring blocking. For non-web traffic such as Simple Mail Transfer Protocol (SMT) traffic, File Transfer Protocol (FLP) traffic, and Domain Name System (DNS) traffic, the server also classifies it as traffic requiring blocking.

[0061] S43. After the server captures a Hypertext Transfer Protocol (HTTP) request from an unauthenticated or unauthorized terminal, it constructs an HTTP response message. The status line of this response message is set to a 302 status code, indicating a temporary redirect. The server adds a location field to the header of the response message, setting its value to the complete Uniform Resource Locator (URL) of the authentication portal page, such as http: / / the authentication server's Internet Protocol address / portal. The server then sends this constructed HTTP response message back to the requesting terminal via a Transmission Control Protocol (TCP) connection. Upon receiving this response message, the browser on the terminal automatically closes the original request connection and initiates a new HTTP request to access the authentication portal page specified in the location field. The end user subsequently sees the authentication portal page in their browser, which contains instructions on installing client software, performing security checks, or logging in. After sending the redirect response, the server discards the original upstream data packets from the terminal and does not forward them to the original target website.

[0062] S44. For uplink data packets whose identification result is "No" and do not belong to the Hypertext Transfer Protocol (HTTP) request, the server performs a blocking operation. Specifically, for uplink data packets whose identification result is "No" but do not belong to HTTP traffic, the server directly performs a blocking operation. The server does not release these data packets back to the normal forwarding path of the core switch. The server adds a drop rule to the packet processing path in the kernel by calling the operating system's network filtering interface. This rule matches the four-tuple of the packet's source Internet Protocol address, source port number, destination Internet Protocol address, and destination port number. For all subsequent data packets from the same network connection, the operating system kernel will automatically drop them and will not pass them to the server for processing. The server can also send an Internet Control Message Protocol (ICP-TCP) destination unreachable message to the source terminal. The code field in the message indicates administrative prohibition, informing the source terminal that the connection has been rejected by the network policy. After receiving this error message, the terminal returns a connection failure error message to the application, and the user is therefore unable to access the target external network resources.

[0063] S45. The server independently executes the above judgment and operation process for each uplink data packet. When a terminal changes from a compliant state to a non-compliant state, the server stops allowing data packets from that terminal and instead blocks or redirects subsequent uplink data packets to the authentication portal. When an unauthenticated terminal completes client installation and passes security checks to be identified as a compliant terminal, the server receives the terminal security check result reported by the terminal and marks it as a compliant terminal, then issues a TTL configuration command to the terminal. Afterward, the TTL value of the uplink data packets sent by the terminal becomes the preset mark value 200. During the identification process of subsequent data packets, the server sets the identification result to "yes," thereby allowing the data packets. Through the above steps, the server implements a complete process of allowing uplink data packets from compliant terminals and blocking or redirecting traffic from unauthenticated or non-compliant terminals to the authentication portal.

[0064] In this context, "allowing" refers to the server's action of not imposing any interception or restriction on a specific uplink data packet, allowing it to continue forwarding to the external network along its original routing path. When the server determines that an uplink data packet originates from a compliant terminal located behind a NAT device, it performs a "allowing" operation on this packet. Allowing means the data packet can pass normally through the core switch, be forwarded to the NAT device, and then sent to the target server on the external network. The "allowing" operation does not modify any content of the data packet, nor does it delay the forwarding process, thus ensuring that the business traffic of compliant terminals is not affected in any way, achieving seamless access control.

[0065] Blocking refers to the server's action of dropping specific uplink data packets, preventing them from being forwarded to NAT devices and the external network. When the server determines that an uplink data packet originates from an unauthenticated or unauthorized terminal, it performs a blocking operation. The blocking operation is implemented by sending a drop command to the kernel's network traffic control module. Blocked data packets will not reach NAT devices or the external network, thus preventing unauthenticated or unauthorized terminals from successfully accessing external network resources. The blocking operation can also send an Internet Control Message Protocol (ICP) error message to the source terminal of the blocked data packet, notifying the source terminal that the connection has been refused, making the end user aware that network access is restricted.

[0066] The redirection to the authentication portal operation refers to the server-side behavior of redirecting Hypertext Transfer Protocol (HTTP) traffic from unauthenticated or unauthorized terminals to a specific authentication webpage. When the server detects an HTTP request from an unauthenticated or unauthorized terminal, it does not forward the request to the original target website. Instead, it constructs an HTTP redirection response containing a Uniform Resource Locator (URL) pointing to the authentication portal page. This redirection response is sent back to the requesting terminal, and the terminal's browser automatically redirects to the authentication portal page upon receiving it. The authentication portal page provides terminal authentication guidance, client software downloads, or security check instructions to guide end users through the compliance authentication process. The redirection to the authentication portal operation only applies to HTTP traffic. For other types of traffic, such as HTTPSecurity Protocol (HTTP) traffic or non-webpage traffic, the server can directly perform blocking operations.

[0067] The authentication portal is a web service entry point specifically for endpoint authentication and compliance checks. It is typically deployed within an internal network, providing functions such as user login, client software download, security check guidance, and endpoint registration. When an unauthenticated or non-compliant endpoint attempts to access the external network, the server redirects its Hypertext Transfer Protocol (HTTP) requests to the authentication portal's Uniform Resource Locator (URL). After opening the authentication portal page in a browser, the end user can follow the on-screen instructions to complete the endpoint authentication process, such as downloading and installing the client program, running security check tools, or logging in with a username and password. The authentication portal page can also display the specific reasons for the endpoint's non-compliance, such as antivirus software not being enabled, missing operating system patches, or corrupted policy files, and provide corresponding repair methods and download links. After the end user completes compliance rectification through the authentication portal, the endpoint is determined to be compliant by the server. Subsequently, it receives a TTL configuration command and modifies the Time-to-Live (TTL) field value of all outgoing Internet Protocol (IP) packets to a preset flag value, thereby gaining normal access to the external network.

[0068] Optionally, in the above technical solution, the process of determining whether each terminal is behind a NAT device includes: S010. Obtain the local private network IP address reported by each terminal, and obtain the public network IP address of the peer end of the network connection established with each terminal. The specific implementation process is as follows: S0100. After each terminal starts up, the client program running on the terminal reads the currently configured local private network IP address through the application programming interface provided by the operating system. The client program traverses all network interfaces on the local machine, filtering out non-loopback interfaces whose Internet Protocol (IP) addresses belong to the private address range as the local private network IP address. If the terminal has multiple network interfaces, the client program selects the local private network IP address of the network interface that is active and corresponds to the default route used to access the external network. The client program encapsulates the obtained local private network IP address in a registration message, which also contains information such as the terminal's device identifier and operating system type. The client program initiates a Transmission Control Protocol (TCP) connection to the server using the pre-configured server IP address and port number. After the connection is successfully established, the client program sends the registration message to the server through this network connection. After receiving the registration message, the server parses out the local private network IP address and associates this address with the peer information of the current network connection, storing it in a terminal information table. For each terminal, the server performs the above receiving process to obtain the local private network IP address reported by each terminal.

[0069] S0101. When a terminal initiates a Transmission Control Protocol (TCP) connection request to the server, the server's operating system kernel allocates a socket descriptor for this connection. The server extracts the Internet Protocol address (IP address) and port number of the peer entity from the socket descriptor by calling the operating system's socket application programming interface (API) functions, such as the function to obtain the peer's address in the Berkeley socket interface. This IIP address is the public IP address of the terminal after NAT mapping, i.e., the peer's public IP address. Upon receiving the registration message from the terminal and resolving the local private IP address, the server simultaneously calls the aforementioned socket function to obtain the public IP address of the peer in the current network connection. The server stores the obtained peer's public IP address along with the previously resolved local private IP address in the terminal information table and establishes a correspondence between the two. For each network connection initiated by a terminal, the server independently performs the above acquisition operation to obtain the peer's public IP address for each terminal. By possessing both the terminal's local private IP address and the public IP address of the peer with whom the network connection has been established, the server can determine in subsequent steps whether the terminal is behind a NAT device.

[0070] The local private IP address refers to the Internet Protocol (IP) address assigned to a terminal behind a NAT device within the network. This address belongs to a private address range, such as 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, or 192.168.0.0 to 192.168.255.255. The local private IP address is only valid within the internal network and cannot be directly routed or accessed on the public network. When a terminal accesses the external network through a NAT device, the NAT device translates the terminal's local private IP address into a public IP address, thereby enabling communication with the external network.

[0071] In this context, the peer's public IP address refers to the public Internet Protocol (IP) address of the terminal after Network Address Translation (NAT), as observed by the server that established a network connection with the terminal. When the terminal sends a data packet to the server through a NAT device, the NAT device replaces the source address of the data packet from the terminal's local private IP address with its own public IP address. The server extracts the source IP address from the received data packet, which is the peer's public IP address. This address represents the terminal's external appearance behind the NAT device; all terminals sharing the same NAT device appear to have the same peer's public IP address to the server.

[0072] In this context, a network connection refers to a Transmission Control Protocol (TCP) connection or User Datagram Protocol (UDP) session established between a terminal and a server for data exchange. In a TCP scenario, a network connection is established through a three-way handshake, containing a four-tuple of information: source Internet Protocol (IP) address, source port number, destination IP address, and destination port number. In a UDP scenario, a network connection manifests as a one-way or two-way datagram communication flow between the terminal and the server. The network connection provides the server with a channel to receive data from the terminal and send data to the terminal. The server can obtain the public IP address and port information of the peer from the socket interface corresponding to each network connection.

[0073] S011. For each terminal, determine whether the terminal's local private IP address and the peer's public IP address are in the same network segment. If not, determine that the terminal is behind a NAT device. The specific implementation process is as follows: S0110. For each terminal, the server reads the terminal's local private IP address and the peer's public IP address from the terminal information table. After completing step S010, the server's terminal information table stores the local private IP address reported by each terminal and the public IP address of the peer with which the network connection was established. The server retrieves records one by one from the terminal information table. For each record, the server obtains the string representation of the corresponding local private IP address and the string representation of the peer's public IP address, and converts these two addresses into 32-bit binary integers for bitwise comparison.

[0074] S0111. Since local private network IP addresses belong to private address ranges, they typically follow standard private address subnetting rules. The server uses the standard subnet mask 255.255.255.0 for network segment determination. The server also converts the subnet mask 255.255.255.0 into a 32-bit binary integer representation. The server can also flexibly choose the subnet mask according to the actual network configuration. For example, for networks using the 172.16.0.0 to 172.31.255.255 address range, the subnet mask 255.240.0.0 can be used; for networks using the 10.0.0.0 to 10.255.255.255 address range, the subnet mask 255.0.0.0 can be used. In this embodiment, the server defaults to using the subnet mask 255.255.255.0 for determination because most enterprise internal networks allocate a 24-bit network prefix private address space for each subnet.

[0075] S0112. The server performs a bitwise AND operation between the local private network IP address and the subnet mask to calculate the network address to which the local private network IP address belongs. Specifically, the server performs a logical AND operation on each bit of the 32-bit binary integer of the local private network IP address and the 32-bit binary integer of the subnet mask; that is, the result bit is 1 only if both bits are 1, otherwise the result bit is 0. The result obtained after the operation is the network address of the local private network IP address. The server saves the calculated network address of the local private network IP address as the first network address.

[0076] S0113. The server performs a bitwise AND operation between the peer's public IP address and the same subnet mask to calculate the network address of the peer's public IP address. The server then performs the same bitwise AND operation between the peer's public IP address (a 32-bit binary integer) and the subnet mask (a 32-bit binary integer), and the result is the network address of the peer's public IP address. The server saves this calculation result as the second network address.

[0077] S0114. The server compares the first network address and the second network address to see if they are completely equal. The server compares the binary integer values ​​of the first network address and the second network address bit by bit. If every bit of the binary value of the first network address is the same as the corresponding bit of the second network address, then the first network address is determined to be equal to the second network address, indicating that the local private network IP address and the peer's public network IP address are in the same network segment. If any bit of the first network address and the second network address is different, then they are determined to be unequal, indicating that the local private network IP address and the peer's public network IP address are in different network segments.

[0078] S0115. If the server determines that the local private IP address and the peer's public IP address are in the same network segment, this means that the local private IP address reported by the terminal and the peer's public IP address received by the server belong to the same network range. This indicates that the terminal has not passed through a NAT device and communicates directly with the server using its own Internet Protocol (IP) address. Therefore, the server determines that the terminal is not behind a NAT device. If the server determines that the local private IP address and the peer's public IP address are in different network segments, this means that the local private IP address reported by the terminal is a private address, while the public IP address actually received by the server is a public address or an address from a different subnet. The two belong to completely different address spaces. This clearly indicates that the data packets sent by the terminal passed through a NAT device before reaching the server. This device translated the terminal's private address into another IP address. Therefore, the server determines that the terminal is behind a NAT device. The server writes the determination result into the corresponding flag field in the terminal information table for subsequent decision-making on whether to issue a TTL configuration command to the terminal.

[0079] In Internet Protocol (IP) address space, a network segment refers to a contiguous range of addresses, determined by the network prefix and subnet mask. The subnet mask is a 32-bit binary number used to divide an IP address into a network portion and a host portion. IP addresses with the same network portion belong to the same network segment. For example, for the IP address 192.168.1.100, if the subnet mask is 255.255.255.0, then the network portion is 192.168.1, and this network segment includes all addresses from 192.168.1.0 to 192.168.1.255. To determine if two IP addresses are in the same network segment, perform a bitwise AND operation between each address and its subnet mask to obtain their respective network addresses, then compare the two network addresses. If they are identical, the two addresses belong to the same network segment; otherwise, they belong to different network segments.

[0080] A Network Address Translation (NAT) device is a network device deployed between an internal network and an external network. It translates the source address of data packets sent by terminals using private Internet Protocol (IP) addresses within the internal network to one or more public IP addresses. NAT allows multiple terminals to share the same public IP address to access the external network. When a data packet sent by a terminal passes through the NAT device, the NAT device modifies the source address field in the IP header of the packet, replacing the private address with the device's own public IP address, and maintains an address translation table to record the translation relationships. For data packets returning from the external network, the NAT device uses the address translation table to restore the destination address to the original terminal's private address. Due to the presence of the NAT device, servers on the external network can only see the public IP address of the NAT device and cannot directly see the private IP addresses of the internal terminals.

[0081] In this context, "terminal behind NAT device" means the terminal is deployed on the internal network side of the NAT device. The terminal's local private IP address cannot be directly routed on the public network. All Internet Protocol (IP) data packets sent by the terminal to the external network must pass through the NAT device during transmission. The NAT device replaces the source address of the data packet from the terminal's local private IP address with its own public IP address before forwarding the packet to the external network. From the perspective of the external server, network connections from different terminals all appear to originate from the same public IP address. The server cannot directly distinguish between different terminals based on the source address because all terminals share the public IP address presented by the NAT device. This "terminal behind NAT device" configuration renders traditional network access control methods based on IP addresses ineffective, as all data packets received by the server have the same source public IP address, making it impossible to determine which specific terminal sent the data packet.

[0082] Optionally, in the above technical solution, the process of verifying the compliance of the terminal includes: S012. For each terminal, receive the terminal security check results reported by the terminal. The terminal security check results include the running status of the antivirus software, the installation status of the operating system patches, and the integrity of the policy file. When the terminal security check results all meet the preset security baseline, the terminal is determined to be a compliant terminal. The specific implementation process is as follows: S0120. A persistent Transmission Control Protocol (TCP) connection is maintained between the server and each terminal. Upon startup, the client program on each terminal actively collects local security check information at fixed time intervals. The client program assembles the collected data—antivirus software running status, operating system patch installation status, and policy file integrity—into a complete terminal security check result message according to a pre-agreed data format. The client program sends this terminal security check result message to the server through the established server connection. Upon receiving the message, the server parses the message header fields to identify the message type as a security check result report, and then extracts the values ​​of the antivirus software running status field, the operating system patch installation status field, and the policy file integrity field from the message body. The server associates these three status values ​​with the terminal's device identifier and temporarily stores them in the server's memory buffer for further processing.

[0083] S0121. During initialization, the server loads a preset security baseline from a configuration file or reads security baseline rules pre-set by the network administrator from the database. The qualified conditions for the preset security baseline regarding the antivirus software's running status include: the antivirus software's real-time protection function must be enabled; the antivirus software's main process must be running; and the antivirus software's virus database version number must not be lower than the specified minimum version number. The qualified conditions for the preset security baseline regarding the operating system's patch installation status include: the operating system must have installed a specified number of critical security patches, and the patch installation date must not be earlier than a specified number of days after the patch release. The qualified condition for the preset security baseline regarding the integrity of the policy file is: the hash value of the policy file reported by the terminal must be equal to the standard hash value stored locally on the server. The server loads the read preset security baseline conditions into memory, preparing for item-by-item comparison.

[0084] S0122. The server compares the antivirus software's running status reported by the terminal with the corresponding qualification conditions in the preset security baseline. Specifically, the server extracts the specific content of the antivirus software's running status from the terminal security check results reported by the terminal, such as the antivirus software's name, main process identifier, real-time protection switch status, and virus database version number. The server compares the antivirus software's real-time protection switch status with the enabled status required by the preset security baseline; if they match, this step passes. The server compares the antivirus software's virus database version number with the minimum version number specified in the preset security baseline using string or numeric comparison; if the reported version number is not lower than the minimum version number, this step passes. Only when both the real-time protection status and the virus database version are qualified does the server determine that the antivirus software's running status meets the preset security baseline; otherwise, it is determined to be non-compliant.

[0085] S0123. The server compares the operating system patch installation status reported by the terminal with the corresponding qualification conditions in the preset security baseline. Specifically, the server extracts the list of installed patches included in the operating system patch installation status from the terminal security check results reported by the terminal. The server iterates through the list of critical patches that must be installed in the preset security baseline. For each patch identifier in the list, the server checks whether the patch identifier exists in the list of installed patches reported by the terminal. If all the critical patches required by the preset security baseline appear in the list reported by the terminal, the server determines that the operating system patch installation status meets the preset security baseline. If any critical patch required by the preset security baseline is not in the list reported by the terminal, the server determines that the operating system patch installation status does not meet the preset security baseline.

[0086] S0124. The server compares the policy file integrity result reported by the terminal with the corresponding qualification conditions in the preset security baseline. Specifically, the server extracts the hash value contained in the policy file integrity field from the terminal security check result reported by the terminal. The server searches for the standard policy file hash value corresponding to the terminal in local storage. This standard hash value is calculated and saved by the server when the policy file is distributed. The server compares the hash value reported by the terminal with the standard hash value in local storage byte by byte. If the two hash values ​​are exactly the same, the server determines that the policy file integrity meets the preset security baseline. If the two hash values ​​differ in any way, the server determines that the policy file integrity does not meet the preset security baseline.

[0087] S0125. The server performs a logical AND operation on the comparison results of the antivirus software's running status, the operating system patch installation status, and the policy file integrity. Only when all three comparison results meet the preset security baseline is the server considered a compliant terminal. If any one or more of the three comparison results fail to meet the preset security baseline, the server determines that the terminal is not compliant. The server writes the determination result into the corresponding compliance flag field in the terminal information table. For terminals determined to be compliant, the server will issue a TTL configuration command to the terminal in subsequent processes, enabling the terminal to modify the TTL field value of all outgoing Internet Protocol (IP) packets. For terminals not determined to be compliant, the server does not issue a TTL configuration command, and the terminal cannot obtain network access permissions based on the TTL flag.

[0088] The endpoint security check result refers to the summary data report generated by the client program on the endpoint after collecting and detecting the local security status. This report contains specific status information of the endpoint across multiple security dimensions, reflecting whether the endpoint meets the security requirements for network access. The endpoint security check result is presented in structured data format, such as key-value pair format or Extensible Markup Language format, with each security check item corresponding to a specific status value. The endpoint sends the check result to the server via the network connection, and the server uses this information to determine whether the endpoint meets preset security standards.

[0089] The antivirus software's running status refers to whether the antivirus software installed on the terminal is in normal working mode. This includes whether the antivirus software's main process is running in the operating system, whether the antivirus software's real-time protection function is enabled, whether the antivirus software's virus database version is up-to-date, and whether the antivirus software is active. The client program obtains the antivirus software's running status by calling the process query interface and service status query interface provided by the operating system. If the antivirus software's main process exists and the real-time protection function is enabled, the antivirus software's running status is determined to be normal; if the antivirus software process does not exist or the real-time protection function is manually disabled by the user, the antivirus software's running status is determined to be abnormal.

[0090] Operating system patch installation status refers to the completeness of security updates and critical patches installed on the operating system running on the terminal. Operating system vendors regularly release patches to fix known security vulnerabilities and system defects; terminals need to install these patches promptly to ensure system security. Operating system patch installation status includes whether the system has installed a specific patch number, the date of the most recent patch installation, and whether any critical patches are missing. Client programs retrieve a list of currently installed patches by calling update query interfaces provided by the operating system, such as the background smart transfer service interface in Windows or reading patch installation records from the system registry. This list is then compared with a preset list of patches that need to be installed to determine the operating system patch installation status.

[0091] Policy file integrity refers to the state of the security policy configuration file stored on the terminal, ensuring it is unaltered, undamaged, and its content is complete and consistent. The security policy file is either distributed by the server or written during initial terminal installation. It contains the security rules the terminal must adhere to, such as the range of allowed network addresses, a list of prohibited applications, and the configuration of required security features. Policy file integrity is checked by hashing the policy file. The client program reads the entire binary content of the policy file, calculates its hash value using a secure hash algorithm, and then compares the calculated hash value with a standard hash value pre-stored on the terminal or obtained from the server. If the two hash values ​​are identical, the policy file content has not been modified, and the integrity verification passes. If the hash values ​​differ, the policy file may have been tampered with by malware or manually modified by the user, and the integrity verification fails.

[0092] The preset security baseline refers to a set of minimum security standards predefined by the server to measure whether a terminal meets the conditions for network access. The preset security baseline includes specific qualification conditions for multiple security checks, such as antivirus software running status, operating system patch installation status, and policy file integrity. For example, the qualification condition for antivirus software running status is that the antivirus software's real-time protection function must be enabled and the virus database version must be no lower than a specified date; the qualification condition for operating system patch installation status is that all security patches marked as critical have been installed; and the qualification condition for policy file integrity is that the hash value of the policy file is completely consistent with the standard hash value stored on the server. The preset security baseline is configured by the network administrator according to the organization's security policy and stored on the server. After receiving the terminal's check results, the server compares each check item with the corresponding condition in the preset security baseline one by one.

[0093] In this context, a compliant terminal refers to a terminal that, after passing a security test conducted by the server, is confirmed to meet all security requirements in the preset security baseline. A terminal is considered compliant only if it simultaneously meets the following conditions: the antivirus software's reported running status conforms to the antivirus software requirements in the preset security baseline; the operating system patch installation status reported by the terminal conforms to the patch requirements in the preset security baseline; and the policy file integrity verification result reported by the terminal passes. Only when all these conditions are met can a terminal be marked as compliant by the server. Compliant terminals have the right to communicate normally on the network. The server will issue TTL configuration commands to compliant terminals, enabling them to obtain network access by modifying the TTL field value. If a terminal no longer meets any of the conditions in subsequent operation, it will no longer be considered a compliant terminal.

[0094] Optionally, the above technical solution also includes: S5. For each terminal, receive the terminal status change information reported in real time during operation. When the terminal status change information indicates that any one of the following—the antivirus software running status, the operating system patch installation status, or the policy file integrity—no longer meets the preset security baseline, issue a TTL recovery command to the terminal. The TTL recovery command is used to instruct the terminal to restore the TTL value of all outgoing IP data packets to the TTL value set by the operating system on the terminal. The specific implementation process is as follows: S50. After receiving the TTL configuration command, each terminal identified as compliant by the server has its client program continuously monitoring its security status. The client program registers a callback function for antivirus software status changes through the operating system's event notification interface. When the antivirus software's real-time protection function is enabled or disabled, the operating system triggers the callback function to notify the client program. The client program also registers a system update notification interface, allowing it to be notified promptly when the operating system installs new patches or uninstalls patches. The client program also uses a file system monitoring interface to continuously monitor the directory containing the policy file. If the policy file is modified, deleted, or replaced, the client program immediately detects the integrity change. When any of these changes occur, the client program collects the specific status after the change and generates a terminal status change information message. The client program sends the terminal status change information to the server through the established Transmission Control Protocol (TCP) connection. The server reads the message from the connection, parses the type field in the message header to identify it as a terminal status change message, and then extracts the changed antivirus software running status, operating system patch installation status, and policy file integrity values ​​from the message payload.

[0095] S51. The server reads the latest values ​​of the antivirus software running status field, the operating system patch installation status field, and the policy file integrity field from the terminal status change information. The server compares the latest value of the antivirus software running status with the qualified conditions defined in the preset security baseline, such as determining whether the real-time protection function is enabled. The server compares the latest value of the operating system patch installation status with the list of critical patches that must be installed in the preset security baseline to check for any missing patches. The server compares the latest value of the policy file integrity with the hash value of the standard policy file stored locally to determine whether the integrity has passed verification. The server records the results of the three checks as either compliant or non-compliant.

[0096] S52. The server checks three comparison results. If the antivirus software's running status, operating system patch installation status, and policy file integrity all meet the preset security baseline, the server determines that the terminal remains compliant and no additional action is required; the server continues to wait for subsequent terminal status changes. If any of the three comparison results fails to meet the preset security baseline—for example, the antivirus software's real-time protection function is disabled, a critical patch is uninstalled, or the policy file's hash value is inconsistent with the standard value—the server determines that the terminal no longer meets the preset security baseline and a recovery process needs to be triggered.

[0097] S53. After determining that the terminal no longer meets the preset security baseline, the server begins constructing a TTL recovery instruction message. The server constructs the message according to the application layer protocol format agreed upon between the server and the terminal. The message header contains a message type field, the value of which is set to a special identifier representing the TTL recovery instruction, which is different from the identifier of the TTL configuration instruction. The payload of the TTL recovery instruction does not need to carry a preset flag value because the terminal has already stored the TTL value set by the operating system locally. The server can attach a checksum field to the message for the terminal to verify whether the message has been corrupted during transmission. After the message is constructed, the server puts it into the send queue, ready to send it to the corresponding terminal through the established transmission control protocol connection.

[0098] S54. The server retrieves the network connection handle for the terminal from the terminal information table. This connection is established during the terminal's initial registration and is maintained continuously. The server sends the constructed TTL recovery command message through this connection. The server uses a reliable transmission control protocol for transmission to ensure the message arrives at the terminal intact. If a network error occurs during transmission, the server will retry, for example, retransmitting the same TTL recovery command message up to three times. Simultaneously with sending the TTL recovery command, the server records an event in its local log, including the terminal's device identifier, the reason for triggering the recovery, and the sending timestamp.

[0099] S55. The client program on the terminal continuously listens for messages from the server. When the client program receives a complete message from the network connection, it first parses the message header to identify the message type field. If the value of the message type field is an identifier for a TTL recovery instruction, the client program confirms that this is a command requesting the recovery of a TTL value. The client program does not need to extract any numerical parameters from the message payload, because the target value to be recovered is the TTL value set by the terminal's local operating system. After successfully parsing the instruction, the client program sends an acknowledgment message to the server, informing the server that the TTL recovery instruction has been correctly received.

[0100] S56. Restore the TTL value of all outgoing Internet Protocol (IP) packets to the TTL value set by the operating system. The client program calls the network protocol stack programming interface provided by the operating system to modify the default value of the Time-to-Live (TTL) field. The client program resets the system-wide TTL default value, previously modified to the preset flag value of 200 via the TTL configuration command, to the original default value of the operating system. For example, it resets it to 128 for Windows and 64 for Linux. The client program completes the restoration operation by calling the same system interface as the modification and passing in the original default value. After the restoration operation is successful, the TTL field value of all subsequent outgoing IP packets from the terminal, including packets from the client program itself and packets generated by the operating system, will be restored to the original operating system setting of 128 or 64, instead of the previous 200. The client program updates the status flag locally to indicate that the TTL restoration command has taken effect. Afterward, the TTL value of uplink packets sent by this terminal will no longer be the preset flag value of 200. During subsequent packet identification, the server will set the identification result of uplink packets from this terminal to "No" and perform blocking operations or redirection operations to the authentication portal.

[0101] Terminal status change information refers to the status update notification message sent to the server by the client program on the terminal after it actively detects a change in the local security status. This information includes three security check results: the latest antivirus software running status, the operating system patch installation status, and the integrity of the policy file. Each result is clearly marked as either meeting or not meeting the preset security baseline. When the terminal's antivirus software's real-time protection function is accidentally disabled by the user, when the operating system automatically installs a new security patch, or when the policy file is modified by a third-party program, the client program immediately collects the changed status, assembles it into terminal status change information, and sends it to the server. By receiving this information, the server can perceive the dynamic changes in the security status of each terminal in real time, without waiting for the terminal's periodic security check results to be reported.

[0102] The TTL recovery command is a structured command message sent by the server to the terminal, instructing the terminal to restore the Time-to-Live (TTL) field value in all outgoing Internet Protocol (IP) packets to the default TTL value set by the terminal's operating system. The TTL recovery command includes an operation type identifier, which differs from the operation type identifier in the TTL configuration command, and informs the terminal that the current command is a command to restore the TTL value. The TTL recovery command does not carry a preset flag value because the target value to be restored is the TTL value set by the terminal's locally known operating system. When the server detects that the terminal no longer meets the preset security baseline, it sends the TTL recovery command to the terminal through the established network connection. Upon receiving the command, the terminal immediately executes the recovery operation, thereby revoking the Time-to-Live flag previously set via the TTL configuration command.

[0103] Optionally, the above technical solution also includes: S6. Continuously monitor the TTL value in the IP header of each uplink data packet. When the TTL value corresponding to an uplink data packet whose previous identification result was "yes" changes from being equal to the preset flag value minus the attenuation value corresponding to the terminal to which the uplink data packet belongs to becoming equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, update the identification result of the terminal to "no", and perform blocking operation or redirection operation to the authentication portal for subsequent uplink data packets from the terminal. The attenuation value corresponding to the terminal is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. For compliant terminals, the initial TTL value is the preset flag value; for unauthenticated or non-compliant terminals, the initial TTL value is the TTL value set by the operating system of the terminal. The specific implementation process is as follows: S60. The server runs an infinitely looping processing thread in the background, continuously retrieving new uplink data packets from the data packet receive buffer. For each retrieved uplink data packet, the server locates the eighth byte of the Internet Protocol header and reads the TTL value from that byte. The server associates the data packet with the specific terminal device using the source port number of the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) in the data packet, combined with the data packet arrival time sequence and NAT device mapping table information. After determining the terminal that sent the data packet, the server reads the corresponding attenuation value and the TTL value set by the operating system from the terminal information table. The server calculates the expected compliant TTL value = preset flag value 200 - attenuation value, and calculates the expected unauthenticated TTL value = the TTL value set by the terminal's operating system - attenuation value. The extracted TTL value is compared with both to determine whether it is a compliant or unauthenticated flag. Simultaneously, the server maintains a state record for each terminal in memory, including the terminal's current identification result, the most recently observed TTL value, and the attenuation value.

[0104] S61. The server detects that the TTL value of an uplink data packet has changed from the expected compliant TTL value to the expected unauthenticated TTL value. During continuous monitoring, the server records the TTL value extracted from the most recent uplink data packet received from each terminal, along with the corresponding attenuation value. Assume that terminal A has always been identified as a compliant terminal by the server, and the TTL values ​​of uplink data packets previously received from terminal A by the server were all expected compliant TTL values ​​(e.g., a preset flag value of 200 minus terminal A's attenuation value). Now, the server receives a new uplink data packet from terminal A, and the extracted TTL value is equal to the TTL value set by the terminal's operating system (e.g., 64) minus terminal A's attenuation value. The server compares this new TTL value with the previously recorded expected compliant TTL value and finds that they are not equal, and the new TTL value is equal to the expected unauthenticated TTL value. The server queries the terminal information table to find the TTL value and attenuation value set by the operating system of terminal A. It confirms that the new TTL value is equal to the TTL value set by the operating system minus the attenuation value. Therefore, it detects that the TTL value has changed from the compliance mark to the uncertified mark.

[0105] S62. The server verifies whether the terminal was previously marked as having a "yes" identification result. Upon detecting a change in the TTL value, the server immediately queries the current identification result status of the terminal stored in memory. The server reads the identification result field of terminal A from the terminal information table. If the value of this field is "yes," it means that the server had previously identified terminal A as a compliant terminal located behind a NAT device. Combined with the fact that the TTL value changed from the expected compliant TTL value to the expected unauthenticated TTL value, the server confirms that terminal A was indeed in a compliant state before, but the data packets it sends no longer carry the preset flag value. If the identification result field value of terminal A was originally "no," the server does not need to perform additional status updates because the terminal has already been identified as an unauthenticated or non-compliant terminal.

[0106] S63. The server updates the terminal's identification result to "No". After determining that terminal A's previous identification result was "Yes", and detecting that its TTL value has changed from the expected compliant TTL value (preset marker value minus attenuation value) to the expected unauthenticated TTL value (operating system-set TTL value minus attenuation value), the server performs an update operation on the identification result. The server changes the identification result field of terminal A in the terminal information table from "Yes" to "No". The server also records the timestamp of the status change and the reason for the change, such as recording "TTL value changed from expected compliant value to expected unauthenticated value". The server can also write an event record to the log system, including the terminal's device identifier, public internet protocol address, TTL value before the change, TTL value after the change, and the change time. After the identification result is updated to "No", the server will treat terminal A as a non-compliant terminal in subsequent processing.

[0107] S64. The server blocks or redirects subsequent uplink data packets from this terminal to the authentication portal. After updating the identification result, the server no longer allows any subsequent uplink data packets from terminal A. When the server receives a new data packet from terminal A, it first queries the terminal information table for the identification result of terminal A. Finding that the value is already "no", it directly enters the processing branch for the "no" identification result. The server determines the traffic type of each subsequent uplink data packet. If the data packet is a Hypertext Transfer Protocol (HTTP) request and the destination port is 80, the server redirects to the authentication portal, returning a HTTP 302 redirect response to terminal A, directing terminal A's browser to the authentication portal page. For other types of traffic from terminal A, such as HTTP, SMTP, FTP, or DNS traffic, the server directly blocks these data packets, discarding them and no longer forwarding them to the external network.

[0108] S65. The server continuously monitors subsequent data packets from the terminal to prevent repeated status changes. After updating the identification result of terminal A to "no," the server does not stop monitoring the data packets sent by terminal A. The server continues to receive and analyze every uplink data packet from terminal A. If, at some later time, the server extracts a TTL value from a data packet received by terminal A that equals the preset flag value minus the terminal's attenuation value, this may mean that terminal A has reinstalled the client program or manually restored the TTL value. In this case, the server will not automatically change the identification result back to "yes," because terminal A must first complete the security detection process again and be re-identified as a compliant terminal by the server before the server will issue a TTL configuration command to it again. Only after receiving a terminal security check result from terminal A that conforms to the preset security baseline will the server re-mark terminal A as a compliant terminal and issue a TTL configuration command. Before this, the server continuously performs blocking operations or redirects subsequent uplink data packets from terminal A to the authentication portal to ensure that unauthorized terminals cannot obtain network access permissions. Through the above steps, the server enables real-time detection of changes in terminal status and dynamic adjustment of access control policies.

[0109] In this context, "subsequent uplink packets" refer to uplink packets sent from the same terminal that have not yet been processed by the server after the server detects a change in the TTL value of a terminal. When the server finds that the TTL value of a new packet sent by a terminal whose previous identification result was "yes" is no longer the expected compliant TTL value (i.e., the preset flag value of 200 minus the terminal's corresponding attenuation value), but has become the expected unauthenticated TTL value (i.e., the TTL value set by the terminal's operating system minus the terminal's corresponding attenuation value), the server updates the identification result of that terminal to "no." For every uplink packet sent by this terminal after the identification result is updated, the server treats it as a subsequent uplink packet and performs blocking or redirection operations to the authentication portal, without allowing it to pass. The concept of subsequent uplink packets emphasizes the temporal order, meaning that all packets received by the server after the state change point are subject to the new processing strategy.

[0110] In another embodiment, combined with Figure 2 and Figure 3 The technical solution of the present invention will continue to be described, specifically including the following steps: S101. System initialization, which includes the following steps: S1010, Deploy an access control server in bypass mode on the core switch of the enterprise campus network. For example... Figure 2As shown, the enterprise campus network deploys various business servers, core switches, access switches, NAT devices, and multiple terminals, including controlled terminal A, controlled terminal B, controlled terminal C, and controlled terminal D. The access control server is an independent physical server or virtual machine, and its network interface is connected to an idle Ethernet port of the core switch via an Ethernet cable. This port will be configured as a mirror port to receive network traffic copied from the core switch.

[0111] S1011. Configure port mirroring on the core switch. The network administrator logs into the core switch's configuration interface, sets the port through which all uplink traffic (i.e., all uplink data packets) connecting to internal network terminals passes as the source port, and sets the port connected to the admission control server as the destination port. After configuration, the core switch copies all uplink data packets sent from internal network terminals to the external network and sends them to the admission control server from the destination port, mirroring all uplink traffic to the controller. The admission control server obtains all uplink data packets sent from terminals to the external network through this mirrored port without affecting the normal forwarding path of the original data packets. Figure 2 It also shows examples of the local private network Internet Protocol (IP) addresses of various terminals: the source IP address of the data packets of controlled terminal A is 10.40.4.4 (i.e., ... Figure 2 The data packet source IP is 10.40.4.4, and the data packet source Internet Protocol address of the controlled terminal B is 192.168.2.2 (i.e., Figure 2 The data packet source IP is 192.168.2.2, while the data packet source Internet Protocol address of the controlled terminal C is 192.168.2.3 (i.e., ...). Figure 2 The data packet source IP is 192.168.2.3, and the data packet source Internet Protocol address of the controlled terminal D is 10.40.4.3 and 10.40.4.3 (i.e., Figure 2 The source IP address of the data packet is 10.40.4.3.

[0112] S1012. Install the user-mode client program (i.e., ...) on each terminal device. Figure 3 (The "client" in the original text). This client program runs with normal user privileges and does not require modification of the operating system kernel. The client program runs automatically after the operating system starts, or is manually started after the user logs in.

[0113] S1013. Upon startup, the client program registers with the access control server and establishes a secure connection. The client program reads the pre-configured Internet Protocol (IP) address and port number of the access control server and initiates a Transmission Control Protocol (TCP) connection request to the access control server. After the access control server accepts the connection, a reliable, bidirectional TCP connection is established between the client program and the access control server. The client program sends a registration message to the access control server through this connection. The registration message contains the terminal's device identifier, operating system type, and the local private network IP address required in subsequent steps.

[0114] S102. Network Address Translation Environment Detection, which includes the following steps: S1020. When a terminal logs into the enterprise network, the client program on the terminal reports its local private network Internet Protocol (IP) address to the access control server. For example... Figure 3 As shown, the client program (i.e. Figure 3 The "client" in the text refers to a personal computer terminal (i.e.) Figure 3 It runs on the "PC" in the text. The client program (i.e. Figure 3 The text "client" in the document immediately reports local network information packets to the access control server (i.e., when network changes occur) when the network changes. Figure 3 (The "server" in the context). Specifically, the client program obtains the Internet Protocol (IP) address configured for the network interface currently used by the local machine by calling the operating system's application programming interface (API). This address is typically an address within a private address range. The client program then encapsulates the obtained local private network IP address in a message and sends it to the admission control server through an established Transmission Control Protocol (TCP) connection.

[0115] S1021. The admission control server obtains the peer's Internet Protocol (IP) address through the socket interface. When the admission control server receives a message from the client program, it calls the socket application programming interface function provided by the operating system to extract the peer entity's IP address from the Transmission Control Protocol (TCP) socket that received the message. This address is the public IP address of the terminal after NAT mapping.

[0116] S1022. The access control server compares the local private network Internet Protocol address reported by the client with the peer Internet Protocol address obtained by the server to see if they are in the same network segment. For example... Figure 3As shown, when the access control server determines that the Internet Protocol address in the client's packet does not match the Internet Protocol address in the network connection, it determines that the terminal is under a NAT device. Specifically, the access control server uses the subnet mask to perform a bitwise AND operation on the two addresses to obtain two network addresses. If the two network addresses are exactly the same, they are determined to be in the same network segment; if the two network addresses are different, they are determined to be in different network segments.

[0117] S1023. If the two addresses are not in the same network segment, the admission control server determines that the terminal is behind a NAT device and triggers the cross-NAT device processing procedure. The admission control server sets the "behind a NAT device" flag for the terminal to "yes" in the terminal information table and continues to execute the subsequent TTL configuration command issuance steps. If the two addresses are in the same network segment, the admission control server determines that the terminal is not behind a NAT device and performs subsequent management and control according to the normal access procedure.

[0118] S103, Time-of-Life Marker Issuance and Dynamic Recovery, specifically includes the following steps: S1030. For terminals determined to be behind a NAT device and verified as compliant through security checks, the access control server sends a TTL configuration command to the client. For example... Figure 3 As shown, the client program reports the terminal security check results to the access control server. If the access control server determines that the terminal meets all network access requirements, it immediately notifies the client program to modify the TTL value to 200. Specifically, after completing the compliance verification of the terminal, the access control server constructs a TTL configuration command message containing a preset flag value. In this embodiment, the preset flag value is set to 200. The access control server sends the TTL configuration command to the client program on the terminal through the established transmission control protocol connection.

[0119] S1031. After receiving the TTL configuration command, the client modifies the Time-to-Live (TTL) field of all outgoing Internet Protocol (IP) packets in its operating system to the preset flag value of 200. The client program calls the network protocol stack programming interface provided by the operating system to modify the system-wide default TTL parameter. After the modification is completed, the TTL field value of every IP packet sent out by all applications on the terminal is set to 200. For example... Figure 3 As shown, the data packets sent by the modified terminal have been marked with a TTL value of 200 (i.e., ...). Figure 3Traffic marked with "TTL=200" is mirrored to the admission control server. By setting the Time-to-Live (TTL) value to a value greater than the default TTL value for common operating systems, the client explicitly marks its own traffic. The default TTL values ​​for common operating systems are: 128 for Windows and 64 for Linux-based operating systems. Figure 3 The text indicates that the default TTL value before the modification was 64 (i.e., ...). Figure 3 (in "TTL=64").

[0120] S1032. If the terminal detects that the security policy has been violated or no longer meets compliance requirements during subsequent operation, the client program will immediately restore the TTL value to the TTL value set by the operating system and remove the mark. Specifically, the client program continuously monitors the terminal's antivirus software running status, operating system patch installation status, and policy file integrity. When any of the above no longer meets the preset security baseline, the client program proactively restores the system-wide default time-to-live parameter from 200 to the original default value of the operating system, for example, 128 for Windows and 64 for Linux. The client program can also perform the restoration operation by receiving a TTL restoration command from the access control server. After restoration is complete, the TTL value of all subsequent Internet Protocol (IP) packets sent by the terminal will become the default value set by the operating system.

[0121] S104. Data stream detection and recognition, specifically including the following steps: S1040, after mirroring via the core switch, the admission control server receives uplink data packets from all terminals in real time. The admission control server enables packet capture on the network interface connected to the mirror port, continuously reading each data packet passing through the mirror port from that interface. For example... Figure 3 As shown, the data packets from the terminal accessing the network have been marked with a TTL value of 200, and the traffic is mirrored to the access control server.

[0122] S1041. The admission control server extracts the Time-to-Live (TTL) field value from the Internet Protocol (IP) header of each uplink data packet. The server locates the eighth byte of the IP header and reads the value of that byte as the TTL value.

[0123] S1042. The admission control server makes a judgment based on the extracted TTL value and the attenuation value corresponding to the terminal: when the TTL value is equal to the preset marking value 200 minus the attenuation value corresponding to the terminal, it indicates that the data packet comes from a compliant terminal; when the TTL value is equal to the default value of the terminal's operating system (e.g., 128 or 64) minus the attenuation value, it is regarded as an unmarked flow or a violation flow.

[0124] S1043. Based on the time-to-live (TTL) result, the access control server immediately identifies which data packets belong to the marked flow, thus initially filtering traffic that meets the access conditions. By comparing the TTL of data packets with the expected value, the legitimacy of the terminal can be determined, thereby realizing network access control.

[0125] S105. Strategy Application and Differentiation Processing, specifically including the following steps: S1050, the admission control server continuously monitors every uplink data packet flowing through the server, identifying tagged and untagged flows. For example... Figure 3 As shown, if the access control server determines that the traffic has been tagged, it will process it accordingly according to the tagging rules. If the destination Internet Protocol address meets the requirements, the traffic is allowed; otherwise, the network is disconnected. The access control server maintains a policy library in memory, which contains differentiated processing rules for different identification results.

[0126] S1051. Once a data packet is identified as belonging to a labeled flow, the admission control server performs differentiated processing on the flow to which the data packet belongs based on the rules associated in the policy library. For example, it may allow terminal A's labeled flow to access all external networks, while only allowing the labeled flow of controlled terminal B to access specific internal networks, or it may implement rate limiting on access. For data packets with an unlabeled time-to-live (TTL) value, i.e., a TTL value equal to the operating system's default value minus the terminal's corresponding attenuation value, the admission control server directly blocks the packet according to the security policy or redirects it to the authentication portal. Figure 2 As shown, the access control server can send network blocking packets to unauthorized connections. Figure 3 As shown, network connection requests that do not meet the requirements are blocked or redirected. Meanwhile, if the access control server determines that the traffic is untagged, it will implement appropriate controls based on the compliance of the source Internet Protocol address, following the traditional approach.

[0127] S1052. Throughout the entire process, although all terminals share the same public Internet Protocol address behind the NAT device, the TTL value received by the server for compliant terminals is the preset TTL value minus the attenuation value, because they are marked with a time-to-live (TTL) value of 200. Other terminals use the default TTL value of the operating system, and the TTL value received by the server for them is the default TTL value of the operating system minus the attenuation value. The access control server can accurately distinguish traffic from different terminals and perform fine-grained access control.

[0128] In this embodiment of the invention, both the client program and the access control server are implemented in user space, without relying on any specific operating system kernel functionality. The client program only needs to utilize basic socket communication and common application programming interfaces such as Internet Protocol header field modification to complete the time-to-live (TTL) marking and status reporting functions. The access control server utilizes the operating system's packet capture and network filtering interfaces to implement packet reception and policy execution. Therefore, this invention has cross-platform capabilities and can be deployed on mainstream operating systems such as Windows and Linux. Since no modifications are required to the forwarding logic of existing NAT devices or core switches, only enabling mirror ports on the core switch is needed, resulting in low deployment costs and risks, and making it easy to promote and apply in actual enterprise networks.

[0129] This embodiment achieves precise access control for terminals located behind NAT devices by deploying an access control server next to the core switch and combining it with a TTL value marking mechanism. Compared to traditional control methods based on Internet Protocol addresses, this solution does not require changes to the network topology or network address translation configuration, has strong compatibility, and can implement fine-grained differentiated strategies, demonstrating significant innovation and practical feasibility.

[0130] This invention configures the Time-to-Live (TTL) field of all outgoing Internet Protocol (IP) data packets by sending a TTL configuration command to compliant terminals located behind a NAT device. This command modifies the TTL field to a preset value greater than the TTL set by the terminal's operating system. Then, it acquires uplink data packets sent from each terminal to the external network, extracts the TTL value from the IP header of each packet, and combines this value with the TTL value set by the terminal's operating system to identify whether each uplink data packet originates from a compliant terminal behind the NAT device. Finally, based on the identification results, it performs either a allow operation, a block operation, or a redirection to the authentication portal for each uplink data packet. This invention does not rely on NAT device functionality extensions, does not interrupt compliant terminal services, and is compatible with encrypted traffic, achieving dynamic, seamless, and cross-protocol network access control.

[0131] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0132] like Figure 4 As shown, a NAT device management system 200 based on TTL value according to an embodiment of the present invention includes an instruction issuing module 201, an acquisition module 203, an identification module 204 and an operation module 205; The instruction issuing module 201 is used to: issue a TTL configuration instruction to each compliant terminal located behind the NAT device. The TTL configuration instruction is used to: cause the compliant terminal located behind the NAT device to modify the TTL field value of all outgoing IP packets to a preset flag value, which is greater than the TTL value set by the operating system on the terminal. The acquisition module 202 is used to: acquire uplink data packets sent by each terminal to the external network; The identification module 203 is used to: obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, and obtain the identification result corresponding to each uplink data packet; The operation module 204 is used to perform operations on each uplink data packet according to the identification result corresponding to each uplink data packet.

[0133] Optionally, the above technical solution further includes a judgment module, which is used for: Obtain the local private network IP address reported by each terminal, and obtain the public network IP address of the peer of the network connection established with each terminal; For each terminal, determine whether the terminal's local private IP address and the peer's public IP address are in the same network segment. If not, determine that the terminal is behind a NAT device.

[0134] Optionally, in the above technical solution, the identification module 203 is specifically used to: for each terminal, determine the attenuation value corresponding to that terminal, the attenuation value being the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received; wherein, for compliant terminals, the initial TTL value is a preset flag value, and for unauthenticated or unauthorized terminals, the initial TTL value is the TTL value set by the operating system of that terminal; for each uplink data packet, if the obtained TTL value is equal to the preset flag value minus the attenuation value corresponding to the terminal that sent the uplink data packet, then it is determined that the uplink data packet comes from a compliant terminal located behind the NAT device, and the identification result corresponding to the uplink data packet is yes; if the obtained TTL value is equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to that terminal, then it is determined that the uplink data packet comes from an unauthenticated or unauthorized terminal, and the identification result corresponding to the uplink data packet is no.

[0135] Optionally, in the above technical solution, the operation module 204 is specifically used to: perform a release operation on uplink data packets from compliant terminals, and perform a blocking operation or a redirection operation to the authentication portal on traffic from unauthenticated terminals or non-compliant terminals.

[0136] Optionally, the above technical solution also includes a compliance assessment module, which is used to: for each terminal, receive the terminal security check results reported by the terminal, including the antivirus software running status, the operating system patch installation status, and the integrity of the policy file; when the terminal security check results all meet the preset security baseline, the terminal is determined to be a compliant terminal.

[0137] Optionally, the above technical solution also includes a change module, which is used for: For each terminal, the terminal status change information reported in real time during operation is received. When the terminal status change information indicates that any one of the terminal's antivirus software running status, operating system patch installation status, or policy file integrity no longer meets the preset security baseline, a TTL recovery instruction is issued to the terminal. The TTL recovery instruction is used to instruct the terminal to restore the TTL value of all outgoing IP data packets to the TTL value set by the operating system on the terminal.

[0138] Optionally, the above technical solution also includes a real-time monitoring module. The real-time monitoring module is used to: continuously monitor the TTL value in the IP header of each uplink data packet; when the TTL value corresponding to an uplink data packet whose previous identification result was yes changes from being equal to a preset flag value minus the attenuation value corresponding to the terminal to which the uplink data packet belongs to becoming equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, the identification result of the terminal is updated to no, and subsequent uplink data packets from the terminal are blocked or redirected to the authentication portal; wherein, the attenuation value corresponding to the terminal is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. For compliant terminals, the initial TTL value is a preset flag value; for unauthenticated terminals or non-compliant terminals, the initial TTL value is the TTL value set by the operating system of the terminal.

[0139] It should be noted that the beneficial effects of the TTL-based NAT device management system 200 provided in the above embodiments are the same as those of the TTL-based NAT device management method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0140] The TTL-based NAT device management system of the present invention can be a computer program (including program code) running on a computer device. For example, the TTL-based NAT device management system of the present invention is an application software that can be used to execute the corresponding steps in the TTL-based NAT device management method of the present invention.

[0141] In some embodiments, the TTL-based NAT device management system of the present invention can be implemented in a combination of hardware and software. As an example, the TTL-based NAT device management system of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the TTL-based NAT device management method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0142] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0143] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned NAT device management methods based on TTL values. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the NAT device management method based on TTL values ​​shown in any embodiment of the present invention by calling the computer program.

[0144] In one alternative embodiment, an electronic device is provided, such as Figure 5 As shown, Figure 5The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0145] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0146] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0147] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0148] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0149] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0150] It should be noted that, Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0151] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described NAT device management methods based on TTL values.

[0152] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0153] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform any of the above-described NAT device management methods based on TTL values.

[0154] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0155] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0156] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0157] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0158] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0159] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0160] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0161] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for managing NAT devices based on TTL values, characterized in that, include: A TTL configuration instruction is issued to each compliant terminal located behind the NAT device. The TTL configuration instruction is used to: cause the compliant terminal located behind the NAT device to modify the TTL field value of all outgoing IP packets to a preset flag value, which is greater than the TTL value set by the operating system on the terminal. Obtain the uplink data packets sent from each terminal to the external network; Obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, and obtain the identification result corresponding to each uplink data packet; Based on the identification results corresponding to each uplink data packet, operations are performed on each uplink data packet separately.

2. The method for managing NAT devices based on TTL values ​​according to claim 1, characterized in that, The process of determining whether each terminal is behind a NAT device includes: Obtain the local private network IP address reported by each terminal, and obtain the public network IP address of the peer of the network connection established with each terminal; For each terminal, it is determined whether the local private IP address of the terminal and the public IP address of the peer of the terminal are in the same network segment. If not, it is determined that the terminal is behind a NAT device.

3. The method for managing NAT devices based on TTL values ​​according to claim 2, characterized in that, The recognition results for each uplink data packet are obtained, including: For each terminal, a corresponding attenuation value is determined. The attenuation value is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. For compliant terminals, the initial TTL value is the preset flag value. For unauthenticated or non-compliant terminals, the initial TTL value is the TTL value set by the terminal's operating system. For each uplink data packet, if the obtained TTL value is equal to the preset flag value minus the attenuation value corresponding to the terminal that sent the uplink data packet, then the uplink data packet is determined to come from a compliant terminal located behind the NAT device, and the identification result corresponding to the uplink data packet is yes; if the obtained TTL value is equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, then the uplink data packet is determined to come from an unauthenticated terminal or a non-compliant terminal, and the identification result corresponding to the uplink data packet is no.

4. The method for managing NAT devices based on TTL values ​​according to claim 3, characterized in that, Based on the identification result corresponding to each uplink data packet, operations are performed on each uplink data packet, including: allowing uplink data packets from compliant terminals, blocking traffic from unauthenticated or non-compliant terminals, or redirecting traffic to the authentication portal.

5. The method for managing NAT devices based on TTL values ​​according to claim 1, characterized in that, The process of verifying the compliance of the terminal includes: For each terminal, the terminal security check results reported by the terminal are received. The terminal security check results include the running status of the antivirus software, the installation status of the operating system patches, and the integrity of the policy file. When the terminal security check results all meet the preset security baseline, the terminal is determined to be a compliant terminal.

6. The method for managing NAT devices based on TTL values ​​according to claim 5, characterized in that, Also includes: For each terminal, the terminal status change information reported in real time during operation is received. When the terminal status change information indicates that any one of the terminal's antivirus software running status, operating system patch installation status, or policy file integrity no longer meets the preset security baseline, a TTL recovery instruction is issued to the terminal. The TTL recovery instruction is used to instruct the terminal to restore the TTL value of all outgoing IP data packets to the TTL value set by the operating system on the terminal.

7. The method for managing NAT devices based on TTL values ​​according to claim 1, characterized in that, Also includes: The system continuously monitors the TTL value in the IP header of each uplink data packet. When the TTL value corresponding to an uplink data packet whose previous identification result was "yes" changes from being equal to the preset flag value minus the attenuation value corresponding to the terminal to which the uplink data packet belongs to becoming equal to the TTL value set by the operating system of the terminal that sent the uplink data packet minus the attenuation value corresponding to the terminal, the identification result of the terminal is updated to "no", and subsequent uplink data packets from the terminal are blocked or redirected to the authentication portal. The attenuation value corresponding to the terminal is the difference between the initial TTL value of the uplink data packet sent by the terminal and the TTL value when the data packet is received. For compliant terminals, the initial TTL value is the preset flag value; for unauthenticated or non-compliant terminals, the initial TTL value is the TTL value set by the operating system of the terminal.

8. A NAT device management system based on TTL values, characterized in that, It includes a command issuance module, an acquisition module, an identification module, and an operation module; The instruction issuing module is used to: issue a TTL configuration instruction to each compliant terminal located behind the NAT device. The TTL configuration instruction is used to: cause the compliant terminal located behind the NAT device to modify the TTL field value of all outgoing IP packets to a preset flag value, the preset flag value being greater than the TTL value set by the operating system on the terminal. The acquisition module is used to: acquire uplink data packets sent by each terminal to the external network; The identification module is used to: obtain the TTL value in the IP header of each uplink data packet, and combine it with the TTL value set by the operating system on each terminal to identify whether each uplink data packet comes from a compliant terminal located behind the NAT device, and obtain the identification result corresponding to each uplink data packet; The operation module is used to perform operations on each uplink data packet according to the identification result corresponding to each uplink data packet.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a NAT device management method based on a TTL value as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements a NAT device management method based on a TTL value as described in any one of claims 1 to 7.

Images