A terminal access control method and device in an industry private network environment

Abstract

The application relates to the computer technical field and discloses a terminal access control method and device in an industry private network environment. A client signature injection process is driven by a network proxy module to intercept data packets, signature processing is performed on outbound TCP data packets, a signature injection function is called to inject signature data containing an AgentID, an encrypted secure random number and a checksum into a TCP experimental option field; a server XDP signature verification process adopts a kernel-level access control system to intercept and verify the signature before data packets arrive at a network protocol stack, signature verification is determined layer by layer; a source IP address after NAT is put into an access pool, signature verification is performed on TCP traffic to realize fine access control. The application can realize microsecond-level high-performance processing capability, provide lightweight and expandable encrypted signatures, realize fine and real-time access control on a single terminal in a NAT environment, minimize deployment invasiveness and provide high safety and reliability guarantee.

Description

Technical Field

[0001] This application relates to the field of computer technology and discloses a terminal access control method and device in an industry private network environment. Background Technology

[0002] With the rapid development of information technology, industry private networks, as a crucial infrastructure supporting core business operations, are receiving increasing attention for their security and reliability. These networks are typically deployed in critical sectors such as government, finance, energy, and transportation, undertaking core functions such as data transmission, remote control, and system interconnection. Therefore, they impose extremely high security requirements on access control for terminal devices. Terminal access control, as the first line of defense for network security, aims to authenticate and assess the security of terminal devices accessing the network, ensuring that only devices conforming to security policies can access private network resources, thereby effectively preventing security threats such as unauthorized access, data breaches, and network attacks.

[0003] Terminal access control in NAT environments is a crucial technical direction for the security management of industry private networks. Due to the common practical needs of industry private networks, such as limited IP address resources and multiple users sharing internet access, NAT technology is widely deployed to solve the address reuse problem. However, NAT technology causes the terminal's real IP address to be replaced with the gateway address. Traditional source IP-based access control mechanisms struggle to accurately identify terminal identities in NAT environments, easily leading to coarse-grained control and inability to precisely track specific terminals. Therefore, how to achieve fine-grained, real-time access control for individual terminals in NAT environments has become a key technical challenge in the security construction of industry private networks. Summary of the Invention

[0004] Existing terminal access control schemes suffer from several shortcomings: First, they exhibit poor performance. Verification operations typically occur at the application layer or are analyzed after mirroring traffic, resulting in high processing latency and making it difficult to meet the high throughput and low latency requirements of 10 Gigabit or 100 Gigabit private network environments. Second, they are highly intrusive in deployment. Existing solutions often require modifications to the network topology, such as deploying mirroring devices or implementing policy routing, or relying on specific fields for verification. However, the TTL value is easily affected by network hop count, and watermark data is easily discarded during transmission, limiting the applicability of the solution. Third, they have weak security protection capabilities. Terminal identification information is susceptible to forgery or replay attacks, lacks an encrypted signature verification mechanism, and the verification point is located late, resulting in a long attack window before the data packet reaches the verification point. Finally, they suffer from poor system compatibility. Existing solutions struggle to seamlessly integrate with multiple access control systems such as 802.1X and Portal. In NAT environments, the granularity of terminal identification is relatively coarse, failing to meet the stringent requirements of high security, high reliability, and low latency for industry private networks.

[0005] The purpose of this invention is to provide a terminal access control method and device in an industry private network environment, which can effectively solve the problems of low performance, strong deployment intrusion, weak security and poor compatibility in the background technology.

[0006] According to a first aspect of the present invention, the present invention claims protection for a terminal access control method in an industry private network environment, characterized by comprising the following steps: S1, driven by the network proxy module, intercepts all data packets and determines the direction of the data packets. It performs signature processing on outbound TCP data packets and calls the signature injection function to complete the injection of signature data. S2, Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted secure random number, and a calculated checksum. The checksum is calculated from the predetermined number of bytes of AgentID and the encrypted secure random number. The fastSignature variant algorithm is used to add XOR operation and salting obfuscation. S3, using the TCP experimental options field to carry signature data, construct new TCP Options and insert them in front of the original TCPOptions, filter NOP and EOL padding, retain other legal options and use NOP padding to the predetermined alignment requirements, update the total length of the IP header and the TCP Data Offset field and recalculate the checksum; S4 employs a kernel-level network access control system based on eBPF / XDP. Data packets are intercepted and filtered before reaching the network protocol stack, and are judged layer by layer according to priority. Signature verification is reported to the user space through perf event and supports dynamic hot updates through the HTTP interface. S5 adds the source IP address behind the NAT to the admission pool and performs signature verification on TCP traffic to achieve admission control after NAT traversal.

[0007] Furthermore, in S1, the network proxy module captures all data packets flowing through the network card through the traffic interception module, distinguishes between inbound and outbound traffic using the direction identification field of the data packets, and only performs signature processing logic on TCP data packets marked as outbound. In S2, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. A predetermined number of bytes of it is taken as part of the signature to ensure that each terminal has a unique signature feature. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made, effectively preventing replay attacks.

[0008] Furthermore, in S3, the predetermined option value is the TCP experimental option field. When constructing a new option, the signature data is inserted before the original TCP Options, the original NOP padding and EOL terminator are filtered out, and other legal options such as MSS and WindowScale are retained to ensure protocol compatibility. The option field is filled with NOP padding to meet the predetermined alignment requirements to satisfy the TCP protocol specification. The IP header total length field is updated to reflect the length of the newly added Options. The TCP Data Offset field is updated to indicate the total length of the TCP header after including Options. The IP checksum and TCP checksum are recalculated to ensure data integrity. When the system in S4 starts up, it first loads the configuration file to read the admission policy parameters, then compiles and loads the BPF program and attaches the XDP program to the specified network card, initializes the BPF Map for rule storage, and starts the event listening thread and HTTP management interface to provide runtime management capabilities.

[0009] Furthermore, the priority determination of the data packet after entering the XDP entry function in S4 includes: Packets with broadcast MAC addresses are allowed to pass, and rules are matched in descending order of priority. If the source MAC is in the registered list, the packet is allowed; if the destination IP is in the whitelist, the packet is allowed; if the source IP is in the trusted list, the packet is allowed; if the source IP is not in the admission pool, the packet is discarded; and if the ACL rule is matched, it is processed according to the configured ALLOW or DENY action. The priority-based TCP protocol signature verification in S4 includes: parsing the TCP Options field to find custom options with predetermined option values, extracting signature data and calculating a checksum using the same fastSignature variant algorithm as the client, comparing the calculated checksum with the checksum carried in the signature data, returning a signature pass result if the verification passes and allowing the data packet to pass if the verification fails, and returning a signature discard result and directly discarding the data packet if the verification fails.

[0010] Furthermore, the priority-based event reporting mechanism in S4 includes: Each rule matching result is reported to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing source IP, destination IP, protocol type, and matching result information, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis. The runtime management mechanism in S4 includes: It provides dynamic configuration capabilities through the HTTP interface, supporting the refreshing of the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list without restarting the program, so as to realize the real-time effect and hot update of policies. The processing mechanism in the NAT environment of S5 includes: The source IP address after NAT translation is added to the admission pool. The admission pool only serves as a basic list of trusted IPs and does not perform strict pre-control. The actual admission control is implemented through TCP signature verification. If the signature verification is successful, the traffic is allowed to pass; if the signature verification fails, the traffic is discarded. This achieves accurate identification and admission control of individual terminals in the NAT environment.

[0011] According to a second aspect of the present invention, the present invention claims protection for a terminal access control device in an industry private network environment, comprising: The client subsystem and the service subsystem include: The client subsystem includes a traffic interception module, a direction determination module, a condition determination module, and a signature injection module; The traffic interception module is used to capture all data packets flowing through the network card; the direction determination module is used to determine the inbound or outbound direction of the data packets; the condition determination module is used to determine the gateway authorization, online connection and signature switch status; and the signature injection module is used to inject signature data into outbound TCP data packets. The server subsystem includes an XDP entry function module, a rule matching module, a signature verification module, and an event reporting module. The XDP entry function module is used to intercept data packets before they reach the network protocol stack. The rule matching module is used to determine whether data packets are allowed to enter based on priority. The signature verification module is used to verify the signature data carried in the TCP Options field. The event reporting module is used to report the matching results to the user-space process.

[0012] Furthermore, the signature injection module in the client subsystem is specifically used for: Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted security random number, and a calculated checksum. The signature data is carried in the TCP experimental options field. A new TCP Options is constructed and inserted in front of the original TCP Options. NOP and EOL padding are filtered out. Other legal options are retained and NOP padding is used to fill the predetermined alignment requirements. The total length of the IP header and the TCP Data Offset field are updated and the checksum is recalculated. The rule matching module in the service subsystem makes decisions in the following order according to priority: Allow broadcast MAC, rule matching, whitelist matching, admission pool check, ACL rule matching, DHCP traffic allowance, non-TCP protocol allowance, and TCP protocol signature verification.

[0013] Furthermore, the signature verification module in the service terminal system is specifically used for: Parse the TCP Options field to find custom options with predefined option values, extract signature data and calculate a checksum using the same fastSignature variant algorithm as the client, compare the calculated checksum with the checksum carried in the signature data, and if the verification passes, allow the data packet; otherwise, discard the data packet. The service subsystem also includes a NAT processing module, which adds the source IP address after NAT translation to the admission pool and performs signature verification only on TCP traffic to achieve fine-grained admission control after NAT traversal.

[0014] Furthermore, the service subsystem also includes a policy management module and an HTTP management interface module. The policy management module is used to maintain the whitelist, admission pool, ACL rule list and source IP trusted list. The HTTP management interface module is used to provide dynamic configuration capabilities, supporting refreshing the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list. In the signature injection module, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made.

[0015] Furthermore, in the rule matching module, if the source MAC is in the registered list, the destination IP is in the whitelist, the source IP is in the trusted list, the source IP is discarded if it is not in the admission pool, and the matched ACL rule is processed according to the configured ALLOW or DENY action. The client subsystem also includes a secure storage module for securely storing AgentID keys and generating encrypted random numbers; The event reporting module in the service subsystem reports the matching results to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing source IP, destination IP, protocol type, and matching result information, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. High-performance processing capability: By moving the signature verification point forward to the kernel XDP layer, data packets are intercepted and verified before reaching the network protocol stack, reducing the processing latency from the application layer to the microsecond level, meeting the high throughput requirements of high-speed private network environments, and the processing time of a single data packet reaches the microsecond level. 2. Lightweight and scalable cryptographic signature: The signature data is carried using the Options field of the TCP protocol standard. The signature length has extremely low overhead and does not affect TCP protocol compatibility. The signature algorithm adopts a variant of fastSignature to add XOR operation and salting obfuscation, which effectively enhances the anti-forgery ability. 3. Fine-grained access control in NAT environment: By embedding encrypted signatures in the outbound TCP traffic of the client and performing real-time signature verification at the XDP layer on the server, even if the terminal IP address is replaced after NAT translation, the terminal identity can still be accurately identified through the AgentID in the signature, realizing fine-grained and real-time access control for individual terminals, and refining the control granularity from the traditional IP level to the terminal level. 4. Minimizes deployment invasiveness: No need to modify the existing network topology, does not rely on mirror devices or policy routing, the signature is transmitted through the standard TCP protocol field, it is fully compatible with existing network devices, and supports seamless integration with various access channels such as 802.1X and Portal; 5. High security and reliability: Signature verification is completed before the data packet reaches the protocol stack, which greatly shortens the attack window. The signature data includes a random number and a checksum, which effectively prevents replay attacks and forgery attacks. The four-layer access control architecture, combined with whitelists, access pools, ACLs and signature verification, provides multi-layer security protection and meets the strict requirements of industry private networks for high security, high reliability and low latency. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the process of a terminal access control method in an industry private network environment, as claimed in an embodiment of the present invention. Figure 2 A structural block diagram of a terminal access control device in an industry private network environment, as claimed in an embodiment of the present invention; Figure 3 This is a TCP Options signature format and a comparison diagram before and after injection of a terminal access control method in an industry private network environment, as claimed in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] The terms "first," "second," and "third" in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications in the embodiments of this application, such as up, down, left, right, front, back, etc., are only used to explain the relative positional relationships and movements between components in a specific orientation as shown in the accompanying drawings. If the specific orientation changes, the directional indications will change accordingly. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] References to embodiments herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] According to a first embodiment of the present invention, the present invention claims protection for a terminal access control method in an industry private network environment, referring to... Figure 1 This includes the following steps: S1, driven by the network proxy module, intercepts all data packets and determines the direction of the data packets. It performs signature processing on outbound TCP data packets and calls the signature injection function to complete the injection of signature data. S2, Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted secure random number, and a calculated checksum. The checksum is calculated from the predetermined number of bytes of AgentID and the encrypted secure random number. The fastSignature variant algorithm is used to add XOR operation and salting obfuscation. S3, using the TCP experimental options field to carry signature data, construct new TCP Options and insert them in front of the original TCPOptions, filter NOP and EOL padding, retain other legal options and use NOP padding to the predetermined alignment requirements, update the total length of the IP header and the TCP Data Offset field and recalculate the checksum; S4 employs a kernel-level network access control system based on eBPF / XDP. Data packets are intercepted and filtered before reaching the network protocol stack, and are judged layer by layer according to priority. Signature verification is reported to the user space through perf event and supports dynamic hot updates through the HTTP interface. S5 adds the source IP address behind the NAT to the admission pool and performs signature verification on TCP traffic to achieve admission control after NAT traversal.

[0022] In this embodiment, the network proxy module in S1 captures all data packets flowing through the network interface card (NIC) through the traffic interception module. It distinguishes between inbound and outbound traffic using the direction identifier field of the data packets, and only performs signature processing logic on TCP packets marked as outbound (direction==1). The traffic interception module is implemented based on the Linux kernel Netfilter framework, capturing data packets by registering the NF_INET_PRE_ROUTING and NF_INET_POST_ROUTING hook functions. The direction determination module parses the source and destination MAC addresses of the data packets and determines the direction based on routing table information. The condition determination module maintains three status flags: a gateway authorization flag, a connection online flag, and a signature switch flag. Signature injection is only allowed when all three are true.

[0023] The total length of the signature data in S2 is 12 bytes, with the following structure: offsets 0-5 are the last 6 bytes of the AgentID, offsets 6-9 are 4 bytes of encrypted secure random number (generated by crypto / rand), and offsets 10-11 are 2 bytes of checksum. The checksum uses a variant of the fastSignature algorithm (an improved version of Fletcher-16), which adds XOR operation and salting obfuscation to the standard summation. Specifically, the first 10 bytes of data are summed in 16-bit increments, XORed, and a preset salt value (secretly kept internal) is added for perturbation, ultimately generating a 16-bit checksum. The AgentID is issued after the client and backend server complete identity authentication and is a globally unique identifier.

[0024] In S3, the TCP Options format is: Kind=0xE4 (1 byte), Length=0x0E (1 byte, decimal 14), Value=12 bytes of signature data. The injection logic is as follows: Construct a new option and insert it before the original TCP Options; traverse the original options, filtering out NOP (0x01) and EOL (0x00) padding characters; retain valid options such as MSS, Window Scale, and SACK; use NOP to pad to 4-byte boundary alignment; update the total length field of the IP header (add 14 bytes); update the TCP DataOffset field (add in 4-byte units); recalculate the IP checksum and TCP checksum.

[0025] In S4, the system startup process is as follows: load the JSON format configuration file to read the admission policy parameters; compile the eBPF source code using clang and load it into the kernel; attach the XDP program to the specified network card; initialize the BPF Map (including mac_list, ipv4_white_list, src_ip_list, pool, acl_list, etc.); and start the perf event listening thread and the HTTP management interface.

[0026] The decision order of the XDP entry function xdp_prog is as follows: Allow broadcast MAC (ff:ff:ff:ff:ff:ff).

[0027] Call `match_by_rule` to perform rule matching (priority from high to low): The source MAC address is in mac_list → PASS; The destination IP is in the ipv4_white_list → PASS; The source IP is in src_ip_list → PASS; Source IP not in the pool → DROP; Match acl_list (up to 64 quintuple rules), and process the match according to the action (ALLOW / DENY).

[0028] Allow DHCP traffic (UDP ports 67 / 68).

[0029] Non-TCP protocols are directly rejected.

[0030] The TCP protocol enters signature verification: Parse TCP Options, find the Kind=0xE4 option; extract the 12-byte signature; calculate the checksum for the first 10 bytes (the last 6 bytes of AgentID + 4 bytes of random number) using the same fastSignature variant; compare it with the 2-byte checksum in the signature; if they are equal, return SIGN_PASS (XDP_PASS), otherwise return SIGN_DROP (XDP_DROP).

[0031] Event reporting: Each matching result is reported to the user space via perf event. The user space process constructs a Packet object (containing source IP, destination IP, protocol, matching result, etc.) and stores it in TrafficMap, which is then periodically persisted to the backend.

[0032] Hot update: The HTTP interface (RESTful) supports dynamically refreshing ACLs, adding / deleting MAC addresses, managing admission pools, and updating trusted lists without requiring a restart.

[0033] In S5, the source IP address range after NAT translation is pre-added to the admission pool. The admission pool only serves as a basic list of trusted IPs and does not perform strict pre-control; the actual admission control relies on TCP signature verification. Even if multiple terminals share the same NAT IP, the AgentID in the signature can still be accurately distinguished, thereby achieving fine-grained control after penetration.

[0034] This embodiment also provides several alternative solutions: Signature carrier alternative: In addition to TCP Options (Kind=0xE4), a 12-byte signature can be carried in IP Options (option number 30) or the IPv6 Destination Options extension header (option type 0xE4). The client modifies the IP header IHL or adds the IPv6 extension header, and the server-side XDP program parses accordingly.

[0035] Signature verification location alternatives: In addition to XDP, signature verification can be performed at the TC (Traffic Control) eBPF layer (ingress / egress hook) or early netfilter hooks; in hardware-supported scenarios, the signature verification logic can be moved down to the SmartNIC or programmable switch (P4 implementation).

[0036] Signature algorithm and structure alternatives: The checksum can be replaced with CRC16, Adler-32 or other custom obfuscation algorithms; or a short MAC can be generated using symmetric encryption (such as AES-128-GCM) (encrypting the random number and timestamp, and attaching an authentication tag), which is then decrypted and verified by the server.

[0037] Access decision process replacement: The order can be adjusted to first verify signature and then match ACL to reduce unnecessary queries; in non-NAT environments, mapping linkage based on 802.1X authentication results can be added.

[0038] Complete solution alternative: The client signature injection function can be integrated into the endpoint firewall, SD-WAN CPE or virtual network card driver (such as TAP / TUN) without the need to deploy a proxy; the server-side XDP program can be deployed in a hybrid manner with existing zero-trust gateways, SASE platforms or traditional NAC systems (such as 802.1X+Portal).

[0039] Furthermore, in S1, the network proxy module captures all data packets flowing through the network card through the traffic interception module, distinguishes between inbound and outbound traffic using the direction identification field of the data packets, and only performs signature processing logic on TCP data packets marked as outbound. In S2, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. A predetermined number of bytes of it is taken as part of the signature to ensure that each terminal has a unique signature feature. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made, effectively preventing replay attacks.

[0040] Furthermore, in S3, the predetermined option value is the TCP experimental option field. When constructing a new option, the signature data is inserted before the original TCP Options, the original NOP padding and EOL terminator are filtered out, and other legal options such as MSS and WindowScale are retained to ensure protocol compatibility. The option field is filled with NOP padding to meet the predetermined alignment requirements to satisfy the TCP protocol specification. The IP header total length field is updated to reflect the length of the newly added Options, the TCP Data Offset field is updated to indicate the total length of the TCP header after including Options, and the IP checksum and TCP checksum are recalculated to ensure data integrity. When the system in S4 starts up, it first loads the configuration file to read the admission policy parameters, then compiles and loads the BPF program and attaches the XDP program to the specified network card, initializes the BPF Map for rule storage, and starts the event listening thread and HTTP management interface to provide runtime management capabilities.

[0041] Furthermore, the priority determination of the data packet after entering the XDP entry function in S4 includes: Packets with broadcast MAC addresses are allowed to pass, and rules are matched in descending order of priority. If the source MAC is in the registered list, the packet is allowed; if the destination IP is in the whitelist, the packet is allowed; if the source IP is in the trusted list, the packet is allowed; if the source IP is not in the admission pool, the packet is discarded; and if the ACL rule is matched, it is processed according to the configured ALLOW or DENY action. The priority-based TCP protocol signature verification in S4 includes: parsing the TCP Options field to find custom options with predetermined option values, extracting signature data and calculating a checksum using the same fastSignature variant algorithm as the client, comparing the calculated checksum with the checksum carried in the signature data, returning a signature pass result if the verification passes and allowing the data packet to pass if the verification fails, and returning a signature discard result and directly discarding the data packet if the verification fails.

[0042] Furthermore, the priority-based event reporting mechanism in S4 includes: Each rule matching result is reported to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing source IP, destination IP, protocol type, and matching result information, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis. The runtime management mechanism in S4 includes: It provides dynamic configuration capabilities through the HTTP interface, supporting the refreshing of the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list without restarting the program, so as to realize the real-time effect and hot update of policies. The processing mechanism in the NAT environment of S5 includes: The source IP address after NAT translation is added to the admission pool. The admission pool only serves as a basic list of trusted IPs and does not perform strict pre-control. The actual admission control is implemented through TCP signature verification. If the signature verification is successful, the traffic is allowed to pass; if the signature verification fails, the traffic is discarded. This achieves accurate identification and admission control of individual terminals in the NAT environment.

[0043] In this embodiment, regarding the replacement of the signature carrier, when the TCP Options field is unavailable or inapplicable, the IP Options field or other protocol fields can be used to carry the signature data.

[0044] In the signature injection scheme based on the IP Options field, the signature injection module of the client subsystem needs to modify the Options field of the IP header. The IP Options field supports multiple option types; this embodiment uses the IP option number EOExperimental Option, with decimal 30 carrying the signature data. The signature injection module first checks the IHL field of the IP header to confirm that the IP header contains an Options field; if the IHL value is greater than 5, then IP Options exist. The signature injection module constructs new IP Options, with an option structure including a 1-byte option type, a 1-byte option length, and 12 bytes of signature data. The new option is inserted before the original IP Options, the IHL field is updated to reflect the new IP header length, and the IP checksum is recalculated.

[0045] The signature verification module of the server subsystem adds IP Options parsing logic to the XDP program. After parsing the IP header, the XDP entry function checks if the IHL value is greater than 5; if it is, it iterates through the IP Options to find the option with option type 30, extracts the signature data, and performs verification. If the verification passes, the data packet is allowed to pass; otherwise, it is discarded.

[0046] In an IPv6 scenario, the signature injection module can carry signature data using either the IPv6 Hop-by-Hop Options header or the Destination Options header. The Hop-by-Hop Options header, located after the basic IPv6 header, carries options that intermediate routers need to process; the Destination Options header carries options that only the destination node needs to process. This embodiment uses the Destination Options header, employing option type 0xE4 and maintaining consistency with the Kind value of the TCP Options to carry 12 bytes of signature data. The signature verification module of the server subsystem parses the IPv6 header in the XDP program, extracts the signature data, and performs verification and validation.

[0047] Regarding alternative signature verification locations, this embodiment describes an implementation method for signature verification at the TC eBPF layer. The TCeBPF procedure is attached to the outbound or inbound direction of the network interface, processing later than XDP but earlier than traditional iptables / netfilter. The server subsystem loads the TC eBPF procedure as a redundant signature verification point simultaneously with the XDP procedure. The TCeBPF procedure is defined using the SEC ("tc") directive and can be attached to both the ingress and egress hook points.

[0048] The signature verification logic of the TC eBPF program is basically the same as that of the XDP program, the difference being that the TC program processes the skbsocket buffer structure instead of the xdp_md structure. The TC program reads the TCPOptions field using the bpf_skb_load_bytes function, extracts the signature data, calculates the checksum, and compares it. The verification result is redirected to the specified destination using the bpf_redirect function, or the packets are allowed or discarded using the TC_ACT_OK and TC_ACT_DROP constants.

[0049] In the scenario of hardware offloading of smart NICs, the server subsystem uses the programmable NIC's SDK to offload some signature verification logic to the NIC hardware. The extraction and comparison operations for signature verification are executed by the microprocessor within the NIC chip, and the XDP program is only responsible for passing the NIC processing results to the kernel. The hardware offloading solution can further reduce processing latency and is suitable for ultra-low latency scenarios.

[0050] The alternative solutions in this embodiment expand the scope of the invention, enabling the signature injection and verification mechanisms to be adapted to various network protocols and deployment environments, thereby enhancing the flexibility and robustness of the technical solution.

[0051] Regarding signature algorithm replacement, this embodiment describes an implementation method using a symmetric encryption algorithm to generate signatures. The signature injection module of the client subsystem uses the AES-128-GCM algorithm instead of the Fletcher-16 checksum to generate signature data. The signature data structure is adjusted as follows: the first 6 bytes are the last 6 bytes of the AgentID, the next 6 bytes are the encrypted data consisting of an AES-GCM encrypted random number and a timestamp, and the last 4 bytes are the authentication tag generated by AES-GCM. The key is obtained by the client and the backend server through a secure channel and stored in the TPM chip.

[0052] The signature verification module of the server subsystem uses the same AES-128-GCM key to decrypt the signature data and verify the authentication tag. First, the first 6 bytes of the AgentID are extracted and their validity verified. Then, the encrypted data portion is extracted and decrypted using the pre-shared key using AES-GCM. If decryption is successful and the authentication tag verification passes, the signature is considered valid; otherwise, the data packet is discarded. The AES-GCM algorithm provides encryption and integrity protection, and its anti-forgery capabilities are significantly superior to lightweight verification algorithms.

[0053] Regarding the alternative access decision process, this embodiment describes an implementation that performs signature verification before ACL matching. The XDP program of the server subsystem adjusts the rule matching priority, first performing signature verification on TCP protocol packets, and then performing ACL rule matching only after successful verification. This order adjustment can reduce unnecessary ACL query overhead and improve the processing efficiency of packets that have passed signature verification.

[0054] Regarding the hybrid architecture solution, this embodiment describes an implementation that integrates the signature verification mechanism of this invention with the 802.1X authentication system. The 802.1X authentication system has already been deployed in the industry private network, and terminals complete identity authentication via the EAP protocol. This embodiment adds terminal access control based on signature verification on top of successful 802.1X authentication.

[0055] After completing 802.1X authentication, the client subsystem obtains the AgentID and signature key from the authentication server and enables signature injection. The server subsystem adds a linkage interface with the 802.1X authentication system to the XDP program, querying the terminal's authentication status via the RADIUS protocol or RESTful API. If the terminal has completed 802.1X authentication and the authentication status is successful, its source MAC address is added to the mac_list whitelist, and its source IP address is added to the src_ip_list trusted list. Subsequent data packets entering the XDP program are first matched against the whitelist and trusted list; if a match is found, the packet is allowed to pass directly without signature verification. For terminals that have not completed 802.1X authentication, signature verification is still required for access control.

[0056] In scenarios where deploying a proxy module on the client side is inconvenient, this embodiment describes an implementation method that integrates signature injection functionality into the terminal virtual network interface card (NIC) driver. Virtual NIC drivers, such as TAP / TUN devices and veth virtual Ethernet devices, run in kernel space and have the ability to directly access network packets. The sending function of the virtual NIC driver is modified to automatically inject signature data before the TCP packet leaves the virtual NIC. This solution is suitable for scenarios such as virtualized desktops and container networks, eliminating the need to deploy additional proxy programs in the end-user space.

[0057] The alternative solutions in this embodiment further enrich the technical implementation of the present invention, providing a variety of optional technical paths, enabling the present invention to adapt to the security needs and deployment environments of private networks in different industries, and enhancing the scalability and compatibility of the technical solution.

[0058] This invention achieves high-performance, fine-grained terminal access control in industry private network environments through the collaborative operation of client-side signature injection and server-side XDP signature verification. The client subsystem embeds a 12-byte signature based on AgentID and encrypted random numbers into outbound TCP traffic. The server subsystem performs real-time signature verification at the kernel XDP layer, with a processing latency of less than 10 microseconds, meeting the high throughput requirements of 10 Gigabit private networks. Terminals in NAT environments can be accurately identified through the AgentID in the signature, refining the control granularity from the traditional IP level to the terminal level. The technical solution of this invention has advantages such as high performance, lightweight scalability, strong NAT traversal capability, low deployment invasiveness, and high security and reliability, making it suitable for the security construction of private networks in critical industries such as government, finance, energy, and transportation.

[0059] According to a second embodiment of the present invention, referring to Figure 2 This invention claims protection for a terminal access control device in an industry private network environment, comprising: The client subsystem and the service subsystem include: The client subsystem includes a traffic interception module, a direction determination module, a condition determination module, and a signature injection module; The traffic interception module is used to capture all data packets flowing through the network card; the direction determination module is used to determine the inbound or outbound direction of the data packets; the condition determination module is used to determine the gateway authorization, online connection and signature switch status; and the signature injection module is used to inject signature data into outbound TCP data packets. The server subsystem includes an XDP entry function module, a rule matching module, a signature verification module, and an event reporting module. The XDP entry function module is used to intercept data packets before they reach the network protocol stack. The rule matching module is used to determine whether data packets are allowed to enter based on priority. The signature verification module is used to verify the signature data carried in the TCP Options field. The event reporting module is used to report the matching results to the user-space process.

[0060] Furthermore, the signature injection module in the client subsystem is specifically used for: Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted security random number, and a calculated checksum. The signature data is carried in the TCP experimental options field. A new TCP Options is constructed and inserted in front of the original TCP Options. NOP and EOL padding are filtered out. Other legal options are retained and NOP padding is used to fill the predetermined alignment requirements. The total length of the IP header and the TCP Data Offset field are updated and the checksum is recalculated. The rule matching module in the service subsystem makes decisions in the following order according to priority: Allow broadcast MAC, rule matching, whitelist matching, admission pool check, ACL rule matching, DHCP traffic allowance, non-TCP protocol allowance, and TCP protocol signature verification.

[0061] Furthermore, the signature verification module in the service terminal system is specifically used for: Parse the TCP Options field to find custom options with predefined option values, extract signature data and calculate a checksum using the same fastSignature variant algorithm as the client, compare the calculated checksum with the checksum carried in the signature data, and if the verification passes, allow the data packet; otherwise, discard the data packet. The service subsystem also includes a NAT processing module, which adds the source IP address after NAT translation to the admission pool and performs signature verification only on TCP traffic to achieve fine-grained admission control after NAT traversal.

[0062] Furthermore, the service subsystem also includes a policy management module and an HTTP management interface module. The policy management module is used to maintain the whitelist, admission pool, ACL rule list and source IP trusted list. The HTTP management interface module is used to provide dynamic configuration capabilities, supporting refreshing the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list. In the signature injection module, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made.

[0063] Furthermore, in the rule matching module, if the source MAC is in the registered list, the destination IP is in the whitelist, the source IP is in the trusted list, the source IP is discarded if it is not in the admission pool, and the matched ACL rule is processed according to the configured ALLOW or DENY action. The client subsystem also includes a secure storage module for securely storing AgentID keys and generating encrypted random numbers; The event reporting module in the service subsystem reports the matching results to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing information such as source IP, destination IP, protocol type, and matching result, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis.

[0064] This embodiment uses a terminal access control system in an industry private network environment as an application scenario to explain in detail the terminal access control technology proposed in this invention, which is based on TCP Options field signature injection and XDP kernel-level signature verification. The system consists of two main parts: a client subsystem and a server subsystem. By embedding encrypted signatures in the client's outbound TCP traffic and performing real-time signature verification at the server's XDP layer, it achieves refined and high-performance access control of terminal traffic in a NAT environment.

[0065] During system architecture construction, the client subsystem is deployed on industry-specific network terminal equipment. Its hardware architecture includes a processor module, a storage module, a network interface module, and a security module. The processor module adopts a multi-core CPU architecture with a main frequency of no less than 2.0GHz, used to execute the traffic interception and signature injection logic of the network proxy module; the storage module uses NVMe solid-state drives with a capacity of no less than 256GB, used to store the client proxy program, AgentID configuration information, and runtime logs; the network interface module uses a gigabit Ethernet controller, supporting the complete implementation of the TCP / IP protocol stack; the security module integrates a TPM trusted computing chip, used to securely store AgentID keys and generate encrypted random numbers.

[0066] The client subsystem's software architecture includes a traffic interception module, a direction determination module, a conditional judgment module, and a signature injection module. The traffic interception module is implemented based on the Linux kernel's Netfilter framework. It captures all data packets flowing through the network interface card by registering the NF_INET_PRE_ROUTING and NF_INET_POST_ROUTING hook functions. The direction determination module parses the source and destination MAC addresses of the data packets, combines this with routing table information to determine the inbound or outbound direction of the packets, and writes the direction identifier into the packet's metadata area. The conditional judgment module maintains three status flags: a gateway authorization flag, a connection online flag, and a signature switch flag. Signature injection is only allowed when all three flags are true. The signature injection module is responsible for constructing the TCP Options field and writing the signature data into it, while simultaneously updating relevant fields in the IP header and TCP header.

[0067] The service subsystem is deployed on the industry private network border gateway device. Its hardware architecture includes a multi-core server processor, large-capacity memory, programmable network interface card (NIC), and high-speed storage array. The multi-core server processor uses an x86 architecture processor with at least 8 cores and 16 threads, with a main frequency of no less than 3.0 GHz, for running XDP / eBPF programs and user-space management programs; the large-capacity memory has a capacity of no less than 32 GB, for loading BPF programs and storing BPF Map data; the programmable NIC supports XDP offloading, which can offload some eBPF programs to the NIC hardware for execution, further improving packet processing performance; the high-speed storage array uses RAID10 configured NVMe SSDs with a capacity of no less than 2 TB, for storing admission policy configuration and audit logs.

[0068] The server subsystem's software architecture is divided into kernel-mode and user-mode components. The kernel-mode component includes the XDP entry function module, rule matching module, signature verification module, and event reporting module. The XDP entry function module is the entry point for the entire kernel-mode program. Defined by the SEC("xdp") instruction, it is attached to the specified network interface card and is called first before the data packet reaches the network protocol stack. The rule matching module implements multi-layered admission decision logic, including MAC whitelist matching, IP whitelist matching, source IP trusted list matching, admission pool checking, and ACL rule matching. The signature verification module parses the TCP Options field, extracts custom options with a Kind value of 228, calculates the checksum using a variant of the fastSignature algorithm, and compares it with the checksum in the signature data. The event reporting module reports the matching results to the user-mode process through the perf event mechanism. The user-mode component includes the configuration loading module, BPF compilation and loading module, policy management module, and HTTP management interface module. The configuration loading module reads the admission policy configuration file in JSON format; the BPF compilation and loading module uses the clang compiler to compile the eBPF source code into bytecode and load it into the kernel; the policy management module maintains the whitelist, admission pool, ACL rule list and source IP trusted list, and synchronizes them to the BPF Map; the HTTP management interface module provides a RESTful API that supports dynamic refreshing of admission policies.

[0069] The network connection between the client subsystem and the server subsystem is as follows: The network proxy module of the client subsystem establishes a communication link with the XDP gateway device of the server subsystem through the internal network of the industry private network. This link transmits control signaling based on the TCP protocol, and the application and update of AgentID are completed through this link. After the signature injection module of the client subsystem embeds signature data in the outbound TCP data packet, the data packet is transmitted to the server subsystem along the internal network of the industry private network. The server subsystem intercepts and verifies the signature of the data packet at the XDP layer.

[0070] The mechanism for adding, expiring, and deleting IP entries in the admission pool is explained in detail below: The admission pool is updated every minute by the backend management system, and its addition and removal strictly depend on the client's online status and security score; Conditions for joining the admission pool: The client must be online; The client's security score is higher than the system's preset threshold.

[0071] The security score is calculated by the system detecting the client according to the configured baseline detection rules, which are divided into risk-free items and risky items. The final score calculation formula is: Risk score = (total score of risk-free items / total score of all risky items) rounded to the nearest integer.

[0072] Conditions for removing from the admission pool: Once the client goes offline, the backend system will remove its IP address from the admission pool within the next update cycle (within a maximum of 1 minute); When a client's security score falls below a threshold, it is automatically removed from the admission pool.

[0073] This mechanism ensures that the IPs in the admission pool always correspond to online and secure clients, effectively balancing performance and security.

[0074] Based on the above system architecture, the workflow of this embodiment includes two main stages: client signature injection process and server signature verification process.

[0075] During the client-side signature injection process, the traffic interception module first captures data packets at the NF_INET_PRE_ROUTING hook point, reads the sk_buff structure information of the data packets, and parses the Ethernet frame header to obtain the source and destination MAC addresses. The direction determination module queries the kernel routing table by calling the ip_route_output function to determine the outbound direction of the data packets: if the destination IP address belongs to the local directly connected network or a valid route entry exists, the data packet is marked as outbound (direction=1); otherwise, it is marked as inbound (direction=0). The condition determination module reads the gateway authorization status file, connection status file, and signature switch status file stored in the / proc / net directory. If all three are 1, signature injection is allowed; otherwise, the data packet is allowed to pass directly without signature processing.

[0076] Once the condition judgment module confirms that signature injection is allowed, the signature injection module performs the following operations: First, it reads the AgentID from the secure storage area and takes the last 6 bytes as the first part of the signature; second, it calls the cryptographically secure random number generator crypto / rand to generate a 4-byte encrypted secure random number as the second part of the signature; then, it uses a variant of the fastSignature algorithm to calculate the Fletcher-16 checksum for the last 6 bytes of the AgentID plus the 4-byte random number, and uses the resulting 2-byte checksum as the third part of the signature; finally, it constructs the TCP Options field, setting the Kind value to 0xE4 decimal 228, the Length value to 0x0E decimal 14, and filling the Value field with 12 bytes of signature data, referring to... Figure 3 This is a diagram illustrating the TCP Options signature format and a comparison before and after injection.

[0077] When modifying the TCP Options field, the signature injection module first saves the original TCP Options, then inserts the newly constructed signature options before the original options, filtering out NOP0x01 and EOL0x00 padding characters, and retaining other valid options such as MSS and Window Scale. After construction, the total length of the options is padded with NOP padding to 4 bytes for alignment. Subsequently, the signature injection module updates the IP header total length field, adding 14 bytes to represent the newly inserted TCP Options length; it also updates the TCP Data Offset field, representing the total TCP header length in 4-byte units; and recalculates the IP checksum and TCP checksum to ensure data integrity. Finally, the signature injection module allows the modified sk_buff structure to pass through, and the data packet continues to be transmitted down the network protocol stack.

[0078] During the server-side signature verification process, when a data packet arrives at the network card of the server's subsystem, the network card driver first passes the data packet to the XDP program; the XDP entry function xdp_prog is called, receiving a data packet pointer as a parameter. The rule matching module then determines the rules layer by layer according to a predefined priority order: First, packets broadcasting MAC address ff:ff:ff:ff:ff:ff are allowed. Then, the match_by_rule function is called to perform rule matching. If the source MAC is in mac_list, the packet is allowed; if the destination IP is in ipv4_white_list, the packet is allowed; if the source IP is in src_ip_list, the packet is allowed; if the source IP is not in the pool, the packet is discarded. Next, the ACL rules in acl_list are matched according to the five-tuple source IP, destination IP, source port, destination port, and protocol. If a match is found, the ALLOW or DENY action is executed according to the action field. DHCP traffic is allowed on UDP ports 67 and 68; non-TCP protocols are allowed directly.

[0079] The src_ip_list (source IP trusted list) has a higher priority in rule matching. If a match is successful, it will indeed bypass the subsequent admission pool and TCP signature verification and allow the process directly.

[0080] `src_ip_list` is essentially a client whitelist, primarily used to support special terminal devices that cannot or are inconvenient to install clients to access industry-specific private networks, for example: Printers, scanners, IP cameras, industrial control equipment, IoT terminals, and some servers; these devices cannot run signature clients due to hardware or system limitations, but still need to access the network, so this exception channel was designed.

[0081] The `src_ip_list` list is not added by the terminals themselves, but must be manually managed through the backend management system. Each addition / deletion operation is logged in detail (operator, time, IP, reason, etc.) for easy traceability and auditing. This list mainly stores devices with fixed IPs or high trustworthiness; the number is usually limited, and it is maintained centrally by the administrator.

[0082] The system supports monitoring and dynamically adjusting the behavior of IPs in the src_ip_list. Once abnormal traffic is detected, the IP can be immediately removed from the list or added to a temporary blacklist. For core high-security areas, it is recommended to disable or minimize the use of src_ip_list to force all terminals to use the signature verification process.

[0083] The src_ip_list is an exception channel designed in this invention to be compatible with special devices that cannot install clients. It is a "highly controllable" design, not a security vulnerability. Its addition and removal are strictly controlled by the backend management system, and are supplemented by multiple protections such as auditing, behavior analysis and ACL, so the overall security risk is controllable.

[0084] For TCP packets, the signature verification module performs the following operations: First, it parses the TCP header to obtain the start position and length of the TCPOptions field; second, it iterates through the TCP Options, searching for the option with a Kind value of 0xE4; if a signature option is found, it extracts 12 bytes of signature data, obtaining the last 6 bytes of AgentID, 4 bytes of random number, and 2 bytes of checksum; then, it calculates the checksum for the first 10 bytes using the same fastSignature variant algorithm as the client; it compares the calculated checksum with the checksum carried in the signature data; if they are equal, the verification passes, and XDP_PASS is returned to allow the packet to pass; if the verification fails, XDP_DROP is returned to discard the packet.

[0085] For special handling in NAT environments, this embodiment adopts the following scheme: A range of IP addresses behind the NAT gateway is pre-added to the admission pool of the server subsystem. This range is manually added by maintenance personnel based on the actual NAT configuration or automatically learned through DHCP lease information. When a data packet enters the XDP program, if the source IP is not in the admission pool, it is directly discarded without further signature verification. The admission pool serves only as a basic list of trusted IPs; actual fine-grained admission control is achieved through TCP signature verification. Even if multiple terminals share the same IP address behind the NAT, different terminals can still be accurately distinguished through the AgentID in the signature.

[0086] After each rule matching is completed, the event reporting module encapsulates the matching result into a perf event and sends it to the user-space process. The event listening thread of the user-space process receives the perf event, constructs a Packet object containing information such as source IP address, destination IP address, protocol type, matching result, and timestamp, stores the object in TrafficMap and periodically persists it to the storage array, and also uploads it to the backend server for auditing and analysis.

[0087] The runtime management mechanism is implemented through an HTTP management interface module. Operations personnel can access a predefined RESTful interface via a browser or API client to dynamically refresh the ACL rule list, add or delete source MAC addresses, manage source IP addresses in the access pool, and update the trusted source IP list. Upon receiving an update request, the HTTP management interface module calls the relevant functions of the policy management module to write the updated policy data into the BPF Map, enabling real-time policy activation and hot updates without requiring a service restart.

[0088] This embodiment achieves terminal access control in an industry private network environment through the collaborative work of the client subsystem and the server subsystem. The client subsystem embeds a 12-byte encrypted signature in the outbound TCP traffic. This signature contains AgentID, an encrypted random number, and a Fletcher-16 checksum, which is unique and resistant to forgery. The server subsystem performs real-time signature verification on the data packets at the XDP layer, with a processing latency of less than 10 microseconds, meeting the high throughput requirements of a 10 Gigabit private network. Terminals in a NAT environment can be accurately identified through the AgentID in the signature, refining the control granularity from the IP level to the terminal level.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0091] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A terminal access control method in an industry private network environment, characterized in that, Includes the following steps: S1, driven by the network proxy module, intercepts all data packets and determines the direction of the data packets. It performs signature processing on outbound TCP data packets and calls the signature injection function to complete the injection of signature data. S2, Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted secure random number, and a calculated checksum. The checksum is calculated from the predetermined number of bytes of AgentID and the encrypted secure random number. The fastSignature variant algorithm is used to add XOR operation and salting obfuscation. S3, using the TCP experimental options field to carry signature data, construct new TCP Options and insert them in front of the original TCPOptions, filter NOP and EOL padding, retain other legal options and use NOP padding to the predetermined alignment requirements, update the total length of the IP header and the TCP Data Offset field and recalculate the checksum; S4 employs a kernel-level network access control system based on eBPF / XDP. Data packets are intercepted and filtered before reaching the network protocol stack, and are judged layer by layer according to priority. Signature verification is reported to the user space through perf event and supports dynamic hot updates through the HTTP interface. S5 adds the source IP address behind the NAT to the admission pool and performs signature verification on TCP traffic to achieve admission control after NAT traversal.

2. The terminal access control method according to claim 1, characterized in that, In S1, the network proxy module captures all data packets flowing through the network card through the traffic interception module, distinguishes between inbound and outbound traffic using the direction identifier field of the data packets, and only performs signature processing logic on TCP data packets marked as outbound. In S2, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. A predetermined number of bytes of it is taken as part of the signature to ensure that each terminal has a unique signature feature. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made, effectively preventing replay attacks.

3. The terminal access control method according to claim 1, characterized in that, In S3, the predetermined option value is the TCP experimental option field. When constructing a new option, the signature data is inserted before the original TCP Options, the original NOP padding and EOL terminator are filtered out, and other legal options such as MSS and Window Scale are retained to ensure protocol compatibility. The option field is filled with NOP padding to meet the predetermined alignment requirements to satisfy the TCP protocol specification. The IP header total length field is updated to reflect the length of the newly added Options. The TCP Data Offset field is updated to indicate the total length of the TCP header after including Options. The IP checksum and TCP checksum are recalculated to ensure data integrity. When the system in S4 starts up, it first loads the configuration file to read the admission policy parameters, then compiles and loads the BPF program and attaches the XDP program to the specified network card, initializes the BPF Map for rule storage, and starts the event listening thread and HTTP management interface to provide runtime management capabilities.

4. The terminal access control method according to claim 1, characterized in that, The priority determination of data packets after entering the XDP entry function in S4 includes: Packets with broadcast MAC addresses are allowed to pass, and rules are matched in descending order of priority. If the source MAC is in the registered list, the packet is allowed; if the destination IP is in the whitelist, the packet is allowed; if the source IP is in the trusted list, the packet is allowed; if the source IP is not in the admission pool, the packet is discarded; and if the ACL rule is matched, it is processed according to the configured ALLOW or DENY action. The priority-based TCP protocol signature verification in S4 includes: parsing the TCP Options field to find custom options with predetermined option values, extracting signature data and calculating a checksum using the same fastSignature variant algorithm as the client, comparing the calculated checksum with the checksum carried in the signature data, returning a signature pass result if the verification passes and allowing the data packet to pass if the verification fails, and returning a signature discard result and directly discarding the data packet if the verification fails.

5. The terminal access control method according to claim 1, characterized in that, The priority-based event reporting mechanism in S4 includes: Each rule matching result is reported to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing source IP, destination IP, protocol type, and matching result information, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis. The runtime management mechanism in S4 includes: It provides dynamic configuration capabilities through the HTTP interface, supporting the refreshing of the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list without restarting the program, so as to realize the real-time effect and hot update of policies. The processing mechanism in the NAT environment of S5 includes: The source IP address after NAT translation is added to the admission pool. The admission pool only serves as a basic list of trusted IPs and does not perform strict pre-control. The actual admission control is implemented through TCP signature verification. If the signature verification is successful, the traffic is allowed to pass; if the signature verification fails, the traffic is discarded. This achieves accurate identification and admission control of individual terminals in the NAT environment.

6. A terminal access control device in an industry private network environment, characterized in that, include: The client subsystem and the service subsystem include: The client subsystem includes a traffic interception module, a direction determination module, a condition determination module, and a signature injection module; The traffic interception module is used to capture all data packets flowing through the network card; the direction determination module is used to determine the inbound or outbound direction of the data packets; the condition determination module is used to determine the gateway authorization, online connection and signature switch status; and the signature injection module is used to inject signature data into outbound TCP data packets. The server subsystem includes an XDP entry function module, a rule matching module, a signature verification module, and an event reporting module. The XDP entry function module is used to intercept data packets before they reach the network protocol stack. The rule matching module is used to determine whether data packets are allowed to enter based on priority. The signature verification module is used to verify the signature data carried in the TCP Options field. The event reporting module is used to report the matching results to the user-space process.

7. The terminal access control device according to claim 6, characterized in that, The signature injection module in the client subsystem is specifically used for: Generate signature data of a predetermined length. The signature data consists of a predetermined number of bytes of AgentID, an encrypted security random number, and a calculated checksum. The signature data is carried in the TCP experimental options field. A new TCP Options is constructed and inserted in front of the original TCP Options. NOP and EOL padding are filtered out. Other legal options are retained and NOP padding is used to fill the predetermined alignment requirements. The total length of the IP header and the TCP Data Offset field are updated and the checksum is recalculated. The rule matching module in the service subsystem makes decisions in the following order according to priority: Allow broadcast MAC, rule matching, whitelist matching, admission pool check, ACL rule matching, DHCP traffic allowance, non-TCP protocol allowance, and TCP protocol signature verification.

8. The terminal access control device according to claim 6, characterized in that, The signature verification module in the service subsystem is specifically used for: Parse the TCP Options field to find custom options with predefined option values, extract signature data and calculate a checksum using the same fastSignature variant algorithm as the client, compare the calculated checksum with the checksum carried in the signature data, and if the verification passes, allow the data packet; otherwise, discard the data packet. The service subsystem also includes a NAT processing module, which adds the source IP address after NAT translation to the admission pool and performs signature verification only on TCP traffic to achieve fine-grained admission control after NAT traversal.

9. The terminal access control device according to claim 8, characterized in that, The service subsystem also includes a policy management module and an HTTP management interface module. The policy management module is used to maintain the whitelist, admission pool, ACL rule list and source IP trusted list. The HTTP management interface module is used to provide dynamic configuration capabilities, supporting refreshing the ACL rule list, adding or deleting source MAC addresses, managing the source IP list in the admission pool, and updating the source IP trusted list. In the signature injection module, AgentID is a globally unique identifier issued after the client and the backend server complete identity authentication. The encrypted secure random number is generated using a cryptographically secure random number generator, and a different random number is generated each time a signature is made.

10. The terminal access control device according to claim 9, characterized in that, In the rule matching module, if the source MAC is in the registered list, the passage is allowed; if the destination IP is in the whitelist, the passage is allowed; if the source IP is in the trusted list, the passage is allowed; if the source IP is not in the admission pool, the passage is discarded; and the matching ACL rule is processed according to the configured ALLOW or DENY action. The client subsystem also includes a secure storage module for securely storing AgentID keys and generating encrypted random numbers; The event reporting module in the service subsystem reports the matching results to the user-space process through the perf event mechanism. The user-space process constructs a Packet object containing source IP, destination IP, protocol type, and matching result information, stores the Packet object in TrafficMap, and periodically persists and uploads it to the backend server for auditing and analysis.

Images