A vpn identification method and system based on large model semantic embedding

Abstract

The application provides a VPN identification method and system based on large model semantic embedding, and relates to the technical field of network security. First, historical HTTPS traffic data and historical VPN traffic data are obtained, and corresponding first historical behavior data and second historical behavior data are extracted. Then, through vector conversion and semantic mapping, they are uniformly mapped to a high-dimensional semantic space to generate a semantic vector. The historical HTTPS semantic vector and the historical VPN semantic vector are used as sample data to train a contrast learning model to distinguish VPN traffic from HTTPS traffic. Based on the contrast learning model, the traffic identification of the to-be-identified traffic can be performed to obtain the traffic type judgment result of the to-be-identified traffic, so as to accurately identify the VPN traffic and locate the application type of the VPN, thereby improving the network security.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a VPN identification method and system based on large model semantic embedding. Background Technology

[0002] With increasingly stringent cybersecurity regulations, various organizations need to manage cross-border VPNs (such as V2Ray / Trojan / Shadowsocks) within their internal networks. These tools disguise themselves as legitimate HTTPS traffic through TLS encrypted tunnels, allowing internal users to bypass network boundaries and access overseas networks. This poses compliance and data security risks, creating significant challenges to cybersecurity and compliance management. Therefore, identifying such disguised traffic is a crucial aspect of cybersecurity protection.

[0003] Existing traffic identification methods typically detect traffic based on ports, DPI (Device Probe Index), and TLS metadata. For example, cross-border VPN applications can be identified by detecting TCP / UDP port numbers or protocol header characteristics; DPI identifies protocol types by parsing packet payload content; or cross-border VPN applications can be identified by analyzing plaintext information (SNI, JA3 fingerprint, certificate chain) during the TLS handshake phase.

[0004] However, modern cross-border VPN applications commonly use port 443 (masquerading as HTTPS), rendering port signatures completely ineffective. Cross-border VPN applications employ strong encryption algorithms to encrypt the entire payload, rendering DPI unable to extract any useful information and thus completely ineffective. Therefore, existing technologies struggle to effectively identify cross-border VPN traffic, resulting in poor network security. Summary of the Invention

[0005] This application provides a VPN identification method and system based on large model semantic embedding to solve the problem that existing technologies are difficult to effectively identify cross-border VPN traffic and have poor network security.

[0006] Firstly, this application provides a VPN identification method based on large model semantic embedding, the method comprising: Obtain historical network connection traffic; historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data; First historical behavior data is extracted based on historical HTTPS traffic data, and second historical behavior data is extracted based on historical VPN traffic data. Convert the first historical behavior data into a first historical behavior vector, and convert the second historical behavior data into a second historical behavior vector; Map the first historical behavior vector and the second historical behavior vector to a unified semantic space, and merge the semantically unified first historical behavior vector into a historical HTTPS semantic vector, and merge the semantically unified second historical behavior vector into a historical VPN semantic vector. A contrastive learning model is trained using historical HTTPS semantic vectors and historical VPN semantic vectors as sample data; the contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic. Based on the contrastive learning model, traffic identification is performed on the traffic to be identified, and the traffic type determination result of the traffic to be identified is obtained.

[0007] In some feasible embodiments, traffic identification is performed based on a contrastive learning model, including: The embedding space is obtained based on a contrastive learning model; the embedding space includes normalized embedding vectors corresponding to multiple sample data. Obtain the initial semantic vector corresponding to the traffic to be identified, and input the initial semantic vector into the contrastive learning model to obtain the semantic vector to be identified mapped into the embedding space; The KNN classifier is used to find multiple nearest-neighbor normalized embedding vectors of the semantic vector to be identified in the embedding space; Determine the traffic type corresponding to multiple nearest neighbor normalized embedding vectors; the traffic type includes VPN traffic or HTTPS traffic. The proportion of each traffic type is obtained in multiple nearest neighbor normalized embedding vectors, and the traffic type with the highest proportion is determined as the predicted type of the traffic to be identified; and the proportion of traffic corresponding to the predicted type in multiple nearest neighbor normalized embedding vectors is determined as the confidence score.

[0008] In some feasible embodiments, a contrastive learning model is trained using historical HTTPS semantic vectors and historical VPN semantic vectors as sample data, including: Determine the VPN type corresponding to the historical VPN semantic vector; VPN types include V2Ray, Trojan, and Shadowsocks. Combine any two historical VPN semantic vectors corresponding to the same VPN type to obtain multiple positive sample pairs; By combining any historical HTTPS semantic vector and any historical VPN semantic vector, multiple pairs of negative samples of the first type are obtained; Obtain the associated VPN semantic vector of the historical VPN semantic vector; the VPN type corresponding to the associated VPN semantic vector is a variant of the same VPN protocol as the historical VPN semantic vector but a different protocol. By combining historical VPN semantic vectors and associated VPN semantic vectors, multiple pairs of negative samples of the second type are obtained; Using positive sample pairs, first-class negative sample pairs, and second-class negative sample pairs as sample data, a contrastive learning model is trained based on the InfoNCE loss function. The InfoNCE loss function is used to maximize the similarity of positive sample pairs, minimize the similarity of first-class negative sample pairs, and minimize the similarity of second-class negative sample pairs.

[0009] In some feasible embodiments, the first historical behavior data and the second historical behavior data include TLS handshake data, packet length sequence, time sequence data, DNS behavior data, and statistical traffic data; TLS handshake data includes a sequence of Client Hello extended fields and a list of cipher suites; The packet length sequence includes the packet length sequence of the first 32 packets after the TLS handshake is completed; Timing data includes connection establishment time and packet arrival interval; DNS behavioral data includes DNS query domain names before a connection is established; Traffic statistics include network round-trip time, traffic volume, and connection duration.

[0010] In some feasible embodiments, converting first historical behavior data into a first historical behavior vector and second historical behavior data into a second historical behavior vector includes: The Client Hello extended field sequence is One-Hot encoded to obtain a One-Hot vector; and the list of cipher suites is encoded into an Embedding vector through a pre-trained Embedding layer. The packet length sequence is normalized using Z-score to form a packet length sequence vector. The mean, variance, and autocorrelation coefficient of the time series data are extracted to form a time series feature vector; The DNS query domain name is denoised and segmented to obtain the DNS behavior vector; By concatenating the network round-trip time, traffic data volume, and connection duration, a statistical traffic vector is obtained.

[0011] In some feasible embodiments, the semantically unified first historical behavior vector is fused into a historical HTTPS semantic vector, and the semantically unified second historical behavior vector is fused into a historical VPN semantic vector, including: The multilayer perceptron (MLP) based on a 3-layer structure converts the one-hot vector and the embedding vector into the first semantic vector; the hidden layer dimensions corresponding to the 3-layer structure are 256, 128 and 64 dimensions respectively. Feature extraction is performed on the packet-length sequence vector based on a one-dimensional convolutional neural network, and a second semantic vector is generated after global average pooling. The temporal feature vector is processed using a Transformer self-attention encoder to generate a third semantic vector; The DNS behavior vector is semantically encoded based on the pre-trained BERT encoder to generate a fourth semantic vector. The multilayer perceptron (MLP) based on a three-layer structure maps statistical flow vectors to fifth semantic vectors. The first, second, third, fourth, and fifth semantic vectors are weighted and fused through an attention fusion layer to output a 128-dimensional semantic vector.

[0012] In some feasible embodiments, after obtaining the traffic type determination result of the traffic to be identified, the method further includes: Obtain the internal network user IP and session 5-tuple corresponding to the traffic to be identified; the session 5-tuple includes source IP, destination IP, source port, destination port, and transport layer protocol; Based on the preset user-IP mapping table, the system queries user identity information according to the intranet user IP and session 5-tuple, and outputs alarm information based on the user identity information.

[0013] Secondly, this application also provides a VPN identification system based on large model semantic embedding, including: The data acquisition module is configured to acquire historical network connection traffic; historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data. The feature extraction module is configured to extract first historical behavior data based on historical HTTPS traffic data and second historical behavior data based on historical VPN traffic data. The vector conversion module is configured to convert first historical behavior data into a first historical behavior vector and second historical behavior data into a second historical behavior vector. The semantic acquisition module is configured to map the first historical behavior vector and the second historical behavior vector to a unified semantic space, and to fuse the semantically unified first historical behavior vector into a historical HTTPS semantic vector, and to fuse the semantically unified second historical behavior vector into a historical VPN semantic vector. The model training module is configured to train a contrastive learning model using historical HTTPS semantic vectors and historical VPN semantic vectors as sample data; the contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic. The prediction module is configured to identify the traffic to be identified based on a contrastive learning model, and obtain the traffic type determination result of the traffic to be identified.

[0014] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method provided in the first aspect of this application.

[0015] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect of this application.

[0016] As described above, this application provides a VPN identification method and system based on large-model semantic embedding. First, historical HTTPS traffic data and historical VPN traffic data are acquired, and their corresponding first and second historical behavior data are extracted respectively. Then, through vector transformation and semantic mapping, these data are uniformly mapped to a high-dimensional semantic space and fused to generate semantic vectors. Using the historical HTTPS semantic vectors and historical VPN semantic vectors as sample data, a contrastive learning model is trained to distinguish between VPN traffic and HTTPS traffic. Based on the contrastive learning model, traffic identification of the traffic to be identified can obtain the traffic type determination result, thereby accurately identifying VPN traffic, locating the VPN application type, and improving network security. Attached Figure Description

[0017] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 The overall flowchart of VPN identification methods based on large model semantic embedding in some embodiments is shown; Figure 2 The overall structure diagram of a VPN identification system based on large model semantic embedding is shown in some embodiments. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0021] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0022] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0023] HTTPS traffic refers to network traffic transmitted using the Hypertext Transfer Protocol Secure (HTTPS), which typically uses Transport Layer Security (TLS) to encrypt the communication content. Normal HTTPS traffic conforms to standard browser TLS handshake behavior and HTTP request / response semantics, and the connection duration is usually on the order of minutes.

[0024] VPN traffic refers to network traffic transmitted through a Virtual Private Network (VPN) tunnel. In this embodiment, VPN traffic specifically refers to traffic generated by cross-border VPN applications, including but not limited to V2Ray traffic (including Vmess and Vless protocols), Trojan traffic (including Trojan-GFW variants), and Shadowsocks traffic (including ShadowsocksR variants). This type of traffic is disguised as HTTPS traffic through an encrypted tunnel.

[0025] Semantic embedding refers to the technique of mapping raw data (such as text, behavioral features, etc.) to a low-dimensional continuous vector space, so that semantically similar samples are closer in the vector space.

[0026] Contrastive learning is a self-supervised learning method that learns discriminative feature representations by bringing the representations of similar samples (positive sample pairs) closer together and pushing the representations of dissimilar samples (negative sample pairs) further apart.

[0027] TLS handshake data refers to plaintext information generated during the handshake phase of a transport layer security protocol.

[0028] Packet length sequence refers to an ordered sequence of data packet lengths in a network connection.

[0029] JA3 fingerprint is a hash fingerprint value calculated based on the TLS Client Hello message, used to identify a specific TLS client implementation.

[0030] The KNN classifier (K-Nearest Neighbors) makes a classification decision by finding the K nearest known samples in the embedding space that are closest to the sample to be classified, based on the class distribution of the nearest neighbor samples.

[0031] The InfoNCE loss function, or Information NoiseContrastive Estimation, is used in contrastive learning to measure the contrast between the similarity of positive sample pairs and the similarity of negative sample pairs.

[0032] One-Hot encoding is an encoding method that converts discrete categorical features into binary vectors. Each dimension of the vector corresponds to a possible category value, with only one dimension having a value of 1 and the other dimensions having a value of 0.

[0033] Z-score normalization is a data standardization method that transforms raw data into data with a mean of 0 and a standard deviation of 1.

[0034] BERT (Bidirectional Encoder Representations from Transformers) is a pre-trained language model encoder based on the Transformer architecture that captures deep semantic information from text sequences through a bidirectional self-attention mechanism.

[0035] A session 5-tuple is a set of five pieces of information used to uniquely identify a network session, including the source IP address, destination IP address, source port number, destination port number, and transport layer protocol type (such as TCP or UDP).

[0036] Bypass mirroring refers to the technology of replicating network outbound traffic data packets without affecting the performance of the original link, using fiber optic splitters or traffic replicators.

[0037] AEAD encryption (Authenticated Encryption with Associated Data) provides both encryption and message authentication. Shadowsocks 2022 uses AEAD encryption, which exhibits fixed-block encryption characteristics in the packet length sequence, differing from the packet length distribution of ordinary TCP proxy traffic.

[0038] The application scenarios of this application will be explained below.

[0039] With increasingly stringent cybersecurity regulations, various organizations need to manage cross-border VPNs (such as V2Ray / Trojan / Shadowsocks) within their internal networks. These tools disguise themselves as legitimate HTTPS traffic through TLS encrypted tunnels, allowing internal users to bypass network boundaries and access overseas networks. This poses compliance and data security risks, creating significant challenges to cybersecurity and compliance management. Therefore, identifying such disguised traffic is a crucial aspect of cybersecurity protection.

[0040] Existing traffic identification methods typically detect traffic based on port, DPI, TLS metadata, etc.

[0041] Among these methods, identification based on port and protocol characteristics identifies cross-border VPN applications by detecting TCP / UDP port numbers or protocol header features. For example, traditional VPNs (IPSec PPTP, L2TP) use fixed ports (1701, 500, 4500, etc.), and can be identified by port matching. However, modern cross-border VPN applications commonly use port 443 (masquerading as HTTPS), rendering port characteristics completely ineffective.

[0042] DPI (Deep Packet Inspection)-based identification methods identify protocol types by parsing the packet payload. However, cross-border VPN applications (such as V2Ray, Trojan, and Shadowsocks) use strong encryption algorithms (AES-256, ChaCha20) to encrypt the entire payload, rendering DPI completely ineffective as it cannot extract any useful information.

[0043] Identification methods based on TLS handshake metadata analyze plaintext information (SNI, JA3 fingerprint, certificate chain) during the TLS handshake phase to identify cross-border VPN applications. However, V2Ray's WebSocket+TLS transport mode uses genuine and valid SSL certificates, and its SNI field is a spoofed domain name or legitimate CDN node, indistinguishable from normal HTTPS traffic. The Trojan protocol itself is designed to mimic HTTPS traffic, and its TLS handshake process is completely identical to that of a normal web server. Although Shadowsocks does not use TLS, its traffic characteristics are difficult to distinguish from ordinary TCP proxies.

[0044] Traffic classification methods based on machine learning, such as SVM and random forest, classify traffic by manually extracting statistical features (packet length, RTT, connection duration, etc.). This method is limited by the constraints of manual feature engineering, cannot capture subtle behavioral differences in cross-border VPN applications, and has insufficient generalization ability when faced with protocol variants and new obfuscation techniques.

[0045] Therefore, existing technologies struggle to effectively identify cross-border VPN traffic, resulting in poor network security.

[0046] To address the aforementioned issues, this application proposes a VPN identification method based on large model semantic embedding. Figure 1 A flowchart illustrating the overall process of VPN identification methods based on large model semantic embedding in some embodiments is shown. Figure 1 As shown, the method includes the following steps: S100. Obtain historical network connection traffic. This includes historical HTTPS traffic data and historical VPN traffic data.

[0047] Historical network connection traffic serves as sample data for training the contrastive learning model. Bidirectional traffic data is collected at the network egress node via a bypass mirroring method, without affecting the existing network performance.

[0048] Historical HTTPS traffic data refers to network traffic generated by normal HTTPS protocol communication, such as traffic generated when a user accesses a website through a standard browser. Its TLS handshake behavior conforms to the characteristics of standard browsers (standard JA3 fingerprint, standard extended field sequence), the packet length distribution conforms to HTTP request / response semantics, and the connection duration is usually on the order of minutes.

[0049] Historical VPN traffic data refers to network traffic transmitted via VPN tunneling protocols, including V2Ray traffic, Trojan traffic, and Shadowsocks traffic. V2Ray is a modular, cross-platform encrypted proxy kernel framework, collectively known in the industry as the V2Ray family. It provides multiple internal transport protocols, and the outer layer can be wrapped with TLS / WebSocket to completely disguise it as standard HTTPS traffic. V2Ray includes VMess (the original protocol) and VLESS (an iterative upgrade of VMess, a protocol variant). Trojan is a circumvention tool specifically designed to disguise itself as standard HTTPS; it also refers to a Trojan virus, including native Trojan and Trojan-GFW (a protocol variant). Shadowsocks is a lightweight encrypted proxy framework, including native Shadowsocks (SS) and ShadowsocksR (SSR, a protocol variant). Its behavior differs from normal HTTPS traffic in several dimensions.

[0050] S200: Extract first historical behavior data based on historical HTTPS traffic data, and extract second historical behavior data based on historical VPN traffic data.

[0051] The first historical behavioral data consists of multi-dimensional behavioral features extracted from historical HTTPS traffic data, while the second historical behavioral data consists of multi-dimensional behavioral features extracted from historical VPN traffic data. Both the first and second historical behavioral data include behavioral features across five dimensions: TLS handshake data, packet length sequence, time sequence data, DNS behavioral data, and statistical traffic data.

[0052] It can also associate internal network IP location and user session information with each traffic.

[0053] S300, Convert the first historical behavior data into a first historical behavior vector, and convert the second historical behavior data into a second historical behavior vector.

[0054] Different types of raw behavioral data are converted into standardized numerical vector representations for subsequent processing by machine learning models. The first and second historical behavioral data contain the same data types and undergo the same transformation method.

[0055] S400: Map the first historical behavior vector and the second historical behavior vector to a unified semantic space, and merge the semantically unified first historical behavior vector into a historical HTTPS semantic vector, and merge the semantically unified second historical behavior vector into a historical VPN semantic vector.

[0056] The first and second historical behavior vectors contain multiple heterogeneous vectors from different feature domains (such as One-Hot vectors, Embedding vectors, packet length sequence vectors, temporal feature vectors, DNS behavior vectors, and statistical traffic vectors). Each vector is located in a different feature space and has different dimensions, scales, and distribution characteristics. They need to be mapped to a unified semantic space through their respective independent projection networks before being fused.

[0057] S500 uses historical HTTPS semantic vectors and historical VPN semantic vectors as sample data to train a contrastive learning model. The contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic.

[0058] Through contrastive learning training, the semantic vectors of VPN traffic are clustered together in the embedding space, while the semantic vectors of HTTPS traffic are far apart from those of VPN traffic. The contrastive learning model is a large model based on the Transformer architecture, whose backbone network can learn discriminative general behavioral representations.

[0059] S600: Based on the contrastive learning model, traffic identification is performed on the traffic to be identified, and the traffic type determination result of the traffic to be identified is obtained.

[0060] After the contrastive learning model is trained, it can map the behavioral features of any input traffic to semantic vectors in the embedding space, and then make classification decisions based on nearest neighbor relationships in the embedding space. The embedding space is a low-dimensional space with class discriminative power, which is optimized through contrastive learning during the training phase. Semantic vectors of VPN traffic of the same type are clustered in this space, while traffic of different types is kept away from each other.

[0061] The implementation of steps S100-S600 is illustrated below.

[0062] In step S100, historical network connection traffic is obtained. This historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data.

[0063] In some embodiments, when collecting historical network connection traffic, a test network environment is set up to simulate the scenario of intranet users accessing overseas resources through cross-border VPN applications, while normal HTTPS traffic is collected simultaneously as a control sample. Each flow record is labeled with a traffic type tag, including VPN type tags (such as V2Ray-Vmess, V2Ray-vless, Trojan, Trojan-GFW, Shadowsocks, ShadowsocksR, etc.) and an HTTPS tag. The tag information is used to construct positive and negative sample pairs in subsequent comparative learning training. Regarding data scale, at least 10,000 flow records are collected for each type of VPN application, and at least 50,000 flow records are collected for normal HTTPS traffic, with a total training dataset of no less than 100,000 flow records to ensure the sufficiency of samples and statistical reliability for model training.

[0064] The method provided in this application embodiment can collect different types of historical network connection traffic as training data, and combined with a sufficient sample size and fine traffic type labeling, provide a rich sample foundation for the subsequent training of the comparative learning model, enabling the model to learn the distinguishable feature representations of VPN traffic and HTTPS traffic from diverse traffic patterns.

[0065] In step S200, first historical behavior data is extracted based on historical HTTPS traffic data, and second historical behavior data is extracted based on historical VPN traffic data.

[0066] The data dimensions of the first and second historical behavior data can be the same, both including TLS handshake data, packet length sequence, time sequence data, DNS behavior data, and statistical traffic data.

[0067] The following sections will explain the specific content of the behavioral data for each dimension.

[0068] TLS handshake data includes a sequence of Client Hello extended fields and a list of cipher suites, and may also include an ALPN protocol list, an SNI field, and a JA3 fingerprint.

[0069] The Client Hello extended field sequence represents the type identifiers and order of extended fields sent by the client during the TLS handshake phase. Since different TLS client implementations (such as standard browsers and VPN clients) have different sets and orders of extended fields, the extended field sequence can serve as a micro-behavioral feature distinguishing VPN traffic from normal HTTPS traffic. For V2Ray's WebSocket+TLS transport mode, the Client Hello message may contain custom or non-standard extended fields (such as protocol identifiers like VLESS and TROJAN), and the number and order of these extended fields show subtle but detectable differences compared to standard browsers (Chrome, Firefox, Edge). While the overall behavior of Trojan protocol TLS client implementations is highly consistent with standard browsers, specific patterns may exist in TLS version selection and cipher suite preferences. The Shadowsocks protocol does not use TLS, therefore its traffic does not contain Client Hello messages; this dimension can serve as a basis for distinguishing it from VPN protocols that use TLS.

[0070] The cipher suite list is a list of supported cryptographic algorithm suites declared by the client in the Client Hello message. Different TLS client implementations have different priorities and sets of cipher suites, and there are differences in cipher suite preferences between normal browsers (such as Chrome) and VPN clients (such as V2Ray's built-in TLS implementation).

[0071] The ALPN protocol list consists of application layer protocol identifiers (such as h2, http / 1.1, etc.) declared in the Application Layer Protocol Negotiation Extension field. Some VPN clients may include non-standard protocol identifiers or no protocol identifiers in their ALPN list, which differs from the ALPN declaration of standard browsers.

[0072] The SNI (Server Name Indication) field is the domain name of the target server declared in the Client Hello message. In V2Ray's WebSocket+TLS transport mode, the SNI field is usually a spoofed domain name (such as a CDN node domain name or a legitimate website domain name). The SNI field in the Trojan protocol is usually the same as the domain name of the spoofed target server. Shadowsocks does not use TLS, therefore it does not have an SNI field. The SNI field in normal HTTPS traffic is the actual target domain name accessed.

[0073] The JA3 fingerprint is a hash fingerprint value calculated based on fields such as the TLS version, cipher suite list, extended field list, and elliptic curve parameters in the Client Hello message. It is used to identify a specific TLS client implementation. Normal HTTPS traffic corresponds to the JA3 fingerprint distribution of standard browsers (Chrome, Firefox, Edge, etc.). V2Ray's default TLS client configuration generates specific clusters of JA3 fingerprints, which differ from the JA3 fingerprint distribution of standard browsers and can be used as an identification feature. The JA3 fingerprint of the Trojan protocol is consistent with the target browser it impersonates; therefore, it is difficult to distinguish them based on the JA3 fingerprint alone, and a comprehensive judgment needs to be made in conjunction with other behavioral characteristics.

[0074] The packet length sequence includes the packet length sequence of the first 32 packets after the TLS handshake is completed.

[0075] Selecting the packet length sequence of the first 32 data packets allows for control over computational complexity while preserving sufficient behavioral information. The packet length sequence reflects the transmission pattern of application layer data; different protocol data encapsulation formats result in different statistical characteristics in the packet length distribution. Specifically: In V2Ray's Vmess protocol, the first 16 bytes of the packet length sequence are a fixed-format header (containing unencrypted information such as protocol version and random number), followed by an encrypted payload. The packet length distribution exhibits a specific obfuscation pattern, which is significantly different from the HTTP request / response interaction pattern of normal HTTPS traffic.

[0076] In the Trojan protocol, although the packet length distribution is similar to the spoofed target (such as accessing a normal HTTPS website), there are HTTP semantic anomalies (such as the length declared in the Content-Length field being inconsistent with the actual payload length), and there may be abnormal packet length distributions in the packet length sequence that do not match the HTTP semantics.

[0077] Shadowsocks uses AEAD encryption, and its packet length sequence exhibits obvious block encryption characteristics—data packets of fixed block size (such as 1360 or 1370 bytes) appear regularly in the sequence, which is significantly different from the packet length distribution of ordinary TCP proxy traffic.

[0078] In normal HTTPS traffic, packet length distribution conforms to HTTP request / response semantics. Request packets are typically smaller (HTTP headers), while response packets are larger (HTTP content), with packet lengths generally consistent with the Content-Length declared in the HTTP header.

[0079] Timing data includes connection establishment time and packet arrival interval, and may also include heartbeat interval and burst transmission mode.

[0080] The connection establishment time records the time difference between TCP connection establishment and TLS handshake completion, reflecting the efficiency of the handshake interaction between the VPN client and server. The packet arrival interval records the sequence of intervals between the arrival times of adjacent packets, containing rich temporal behavior information. Regarding connection establishment timing: V2Ray and Trojan typically send application data (such as spoofed HTTP requests or encrypted payloads) immediately after the TLS handshake is complete, without the rendering wait and resource request delays unique to browsers. Normal HTTPS traffic usually goes through a complete interactive process of sending an HTTP request, server processing, and returning a response after the TLS handshake is complete, with the timing intervals of each stage conforming to HTTP semantics. Shadowsocks, because it does not use TLS, does not have a TLS handshake phase; its connection enters the data transmission phase directly after establishment.

[0081] Regarding heartbeat intervals: V2Ray and Trojan connections typically send heartbeat packets every 30 to 60 seconds to maintain a long connection. These heartbeat intervals are highly fixed and significantly different from user data transmission patterns. Calculating the autocorrelation coefficient of packet arrival intervals (using lag=30s as an example) can reflect the periodic pattern of the heartbeats. Normal HTTPS short connections (minute-level) typically do not exhibit regular heartbeat patterns.

[0082] Regarding burst transmission patterns: VPN traffic surges when a user performs an action (such as downloading resources or playing videos), then returns to a fixed-interval heartbeat pattern when idle. The frequency and magnitude of burst transmissions differ from the access pattern of normal HTTPS traffic, which typically follows a page-level interaction pattern of "request-response-rendering-subsequent request".

[0083] DNS behavioral data includes DNS query domain names before a connection is established.

[0084] Before establishing an encrypted connection, applications typically need to obtain the target server's IP address through DNS resolution. Therefore, the DNS query behavior includes the target domain name information for establishing the connection. Specifically, V2Ray usually performs DNS queries to unlock the node domain name or CDN domain name before establishing an encrypted tunnel. The queried domain name may contain specific keywords or point to an overseas CDN node. Trojan usually performs DNS queries to spoof the domain name before establishing a connection. Shadowsocks performs fewer DNS queries because the node address is usually configured as an IP address rather than a domain name. Normal HTTPS traffic corresponds to the DNS query behavior of regular websites, and the queried domain name is consistent with the actual website accessed. In addition, the DNS query frequency of cross-border VPN applications may be abnormal—multiple queries for the same domain name in a short period of time (such as reconnection or node switching scenarios), and there is a strong time correlation between the DNS query and the subsequent traffic establishment (a connection to an overseas IP is established within a short period of time after the DNS query, such as within 5 seconds).

[0085] Traffic statistics include network round-trip time (RTT), traffic volume, and connection duration.

[0086] Network round-trip time (RTT) is the time interval between the sending of a data packet and the receiving of an acknowledgment from the receiving end, reflecting the end-to-end latency of a VPN tunnel. Since VPN traffic typically passes through overseas relay nodes, its RTT is usually significantly higher than that of HTTPS traffic directly accessing domestic servers. Traffic volume is the total number of bytes transmitted during the connection, reflecting the actual usage intensity of the VPN tunnel. Connection duration is the time span from connection establishment to connection closure. V2Ray and Trojan typically maintain long connections (hours or even days), demonstrating a strong willingness to maintain connections. Shadowsocks connections typically last for several hours. Normal HTTPS connections are usually short (minutes), limited by the HTTP Keep-Alive mechanism; idle connections automatically close after a period of no data transmission. The combined characteristics of connection duration and RTT can serve as an important statistical dimension for distinguishing between long VPN connections and short HTTPS connections.

[0087] In step S300, the first historical behavior data is converted into a first historical behavior vector, and the second historical behavior data is converted into a second historical behavior vector.

[0088] The following explanation uses one set of behavioral data as an example.

[0089] For the Client Hello extended field sequence in the TLS handshake data, the Client Hello extended field sequence is One-Hot encoded to obtain a One-Hot vector. One-Hot encoding maps each extended type appearing in the extended field sequence to a dimension of the vector; if the extended field appears in the Client Hello, the corresponding dimension is set to 1, otherwise it is set to 0.

[0090] Simultaneously, the cipher suite list is encoded into an embedding vector using a pre-trained embedding layer. This pre-trained embedding layer maps the identifier of each cipher suite to a dense vector of fixed dimensions, capturing the semantic relationships between different cipher suites; for example, cipher suites belonging to the same security strength are adjacent in the embedding space. The ALPN protocol list and SNI field are also encoded into dense vectors using their respective embedding layers. The JA3 fingerprint, as a discrete identifier, is encoded into a dense vector using a separate embedding layer.

[0091] For packet length sequences, Z-score normalization is performed to form a packet length sequence vector. Z-score normalization subtracts the sequence mean from each packet length value and divides by the sequence standard deviation, eliminating the difference in the absolute value of traffic data between different connections, allowing the model to focus on the relative distribution pattern of the packet length sequence rather than its absolute value. The normalized packet length sequence vector is a floating-point vector of length 32.

[0092] For time-series data, the mean, variance, and autocorrelation coefficient are extracted to construct a time-series feature vector. The mean and variance reflect the central tendency and dispersion of packet arrival intervals, while the autocorrelation coefficient reflects the periodic pattern of packet arrival intervals. For example, calculating the autocorrelation coefficient for lag=30s can effectively capture the fixed-interval characteristics of heartbeat packets from cross-border VPN applications. The autocorrelation coefficients of V2Ray and Trojan traffic are usually significantly higher than the corresponding values ​​for normal HTTPS traffic because VPN heartbeats have strong periodicity while normal HTTPS interactions do not have a fixed periodic pattern.

[0093] For DNS behavior data, the DNS query domain names are denoised and segmented to obtain DNS behavior vectors. Denoising includes removing common top-level domain suffixes (such as .com, .net, .org, etc.) and common subdomain prefixes (such as www). Segmentation breaks down the domain name's tags at each level into independent tokens. The denoised and segmented domain name token sequence is used as input to the pre-trained BERT encoder.

[0094] For statistical traffic data, the network round-trip time, traffic volume, and connection duration are concatenated to obtain a statistical traffic vector. The concatenated statistical traffic vector is a three-dimensional vector, corresponding to the statistical values ​​of network round-trip time, traffic volume, and connection duration, respectively.

[0095] In step S400, the semantically unified first historical behavior vector is fused into a historical HTTPS semantic vector, and the semantically unified second historical behavior vector is fused into a historical VPN semantic vector.

[0096] The two data processing methods are the same; the following explanation uses one set of behavioral data as an example. Specifically, it includes the following steps: For the vectors corresponding to TLS handshake data, a three-layer multilayer perceptron (MLP) transforms the One-Hot vector and Embedding vectors (which may include ALPN Embedding vectors, SNI Embedding vectors, and JA3 Embedding vectors) into a first semantic vector. The hidden layer dimensions of the three layers are 256, 128, and 64, respectively. The first layer maps the high-dimensional features obtained by concatenating multiple TLS behavior encoding vectors to a 256-dimensional intermediate representation space. The second layer further compresses this to 128 dimensions, and the third layer outputs a 64-dimensional first semantic vector. The ReLU activation function is used between layers to introduce non-linear transformation capabilities, enhancing the model's ability to model non-linear relationships in TLS behavior features.

[0097] For packet-length sequence vectors, features are extracted from the packet-length sequence vectors based on a one-dimensional convolutional neural network, and then a second semantic vector is generated after global average pooling.

[0098] A one-dimensional convolutional neural network consists of two convolutional layers with 32 kernels of size 3. It extracts local pattern features from packet-length sequences by sliding the convolutional kernels—for example, detecting combined patterns in consecutive fixed-length data packets (such as the 16-byte header + subsequent encrypted payload pattern in V2Ray Vmess). Global average pooling compresses the feature maps of each convolutional channel into a single scalar value, eliminating the dimensionality inconsistency caused by sequence length differences, while also possessing translation invariance.

[0099] For temporal feature vectors, a Transformer self-attention encoder is used to process the temporal feature vectors and generate a third semantic vector. The Transformer self-attention encoder consists of two Transformer encoding layers and a four-head self-attention mechanism, which captures long-range dependencies between different time steps in the temporal feature vector through multi-head self-attention. Compared to recurrent neural networks (such as LSTM), the Transformer encoder can more effectively model the periodic patterns of heartbeat packets—the self-attention mechanism can directly establish attentional connections between two time steps separated by 30 seconds (corresponding to a 30-second heartbeat cycle) without needing to cross time steps through stepwise propagation.

[0100] For DNS behavior vectors, a fourth semantic vector is generated by semantically encoding the DNS behavior vectors using a pre-trained BERT encoder. The pre-trained BERT encoder is trained on a large-scale DNS domain name corpus and can capture the semantic information of domain names—for example, distinguishing the differences in lexical composition and structural patterns between normal domain names (such as common commercial websites and educational institution domains) and VPN node domain names (such as domains containing specific keywords, overseas CDN identifiers, or random subdomains). During the inference phase, the parameters of the BERT encoder are frozen and do not participate in backpropagation gradient updates to reduce inference latency.

[0101] For statistical traffic vectors, a three-layer multilayer perceptron (MLP) maps the statistical traffic vectors to a fifth semantic vector. The structure of the three-layer MLP is consistent with the aforementioned TLS behavior encoder, with hidden layer dimensions of 256, 128, and 64, respectively, mapping the three-dimensional statistical traffic vector to a 64-dimensional semantic representation space.

[0102] The first, second, third, fourth, and fifth semantic vectors are weighted and fused through an attention fusion layer to output a 128-dimensional semantic vector.

[0103] The attention fusion layer learns the contribution weights of each semantic vector to the final fusion result and aggregates multi-source feature information through weighted summation. First, the attention fusion layer maps each semantic vector to the same dimension via linear projection. Then, it calculates the attention score of each projected vector and finally uses the attention scores as weights to perform a weighted summation of the original semantic vectors. For example, if a connection's TLS behavior features have extended field sequences and JA3 fingerprints that are significantly different from those of standard browsers, the attention fusion layer can assign a higher weight to the first semantic vector; if a connection primarily uses fixed-block-size encryption, the attention fusion layer can assign a higher weight to the second semantic vector; if a connection exhibits a clear heartbeat cycle (such as V2Ray / Trojan long connections), a higher weight can be assigned to the third semantic vector; and if a connection's DNS query domain name contains sensitive keywords, a higher weight can be assigned to the fourth semantic vector.

[0104] In this embodiment, a multi-feature encoder and attention fusion mechanism can be used to uniformly map heterogeneous multi-dimensional behavioral data to a 128-dimensional semantic space. This allows five different modalities of behavioral features—TLS behavior, packet length sequence, temporal pattern, DNS query, and statistical features—to be co-expressed in a unified semantic space, thereby capturing complex behavioral patterns that cannot be reflected by a single feature dimension. Unlike traditional schemes that rely on only a single feature (such as TLS metadata or packet length statistics), the multi-modal fusion mechanism enables the model to utilize complementary information from each feature dimension to improve the ability to distinguish between VPN traffic and HTTPS traffic. In particular, for highly disguised VPN traffic (such as Trojan protocols), it is necessary to comprehensively consider subtle behavioral differences across multiple dimensions to achieve effective identification.

[0105] In step S500, a contrastive learning model is trained using historical HTTPS semantic vectors and historical VPN semantic vectors as sample data.

[0106] First, historical HTTPS semantic vectors and historical VPN semantic vectors can be divided into positive and negative samples.

[0107] The VPN types corresponding to historical VPN semantic vectors are determined. VPN types include V2Ray, Trojan, and Shadowsocks. Each historical VPN semantic vector is associated with a specific VPN protocol type label of its source traffic. For example, V2Ray is further divided into Vmess protocol variants and Vless protocol variants; Trojan is further divided into the original Trojan protocol and Trojan-GFW variants; and Shadowsocks is further divided into the original Shadowsocks and ShadowsocksR (SSR) variants. This refined labeling system provides a foundation for constructing high-quality positive and negative sample pairs in contrastive learning.

[0108] Combining the semantic vectors of any two historical VPNs corresponding to the same VPN type yields multiple positive sample pairs. For example, the semantic vectors corresponding to two V2Ray-Vmess traffic flows constitute one positive sample pair, the semantic vectors corresponding to two Trojan traffic flows constitute another, and the semantic vectors corresponding to two Shadowsocks traffic flows constitute yet another. The construction of positive sample pairs is based on the assumption that traffic generated by the same VPN protocol has high similarity in behavioral characteristics, and its semantic vectors should be close to each other in the embedding space. Using the same VPN type (rather than the same VPN family) to construct positive sample pairs ensures behavioral consistency within the positive sample pair and avoids semantic vector dispersion caused by the introduction of protocol variants.

[0109] By combining any historical HTTPS semantic vector with any historical VPN semantic vector, multiple Class I negative sample pairs are obtained. These Class I negative sample pairs are used to train the model to distinguish VPN traffic from normal HTTPS traffic and are easily distinguishable negative samples. Since HTTPS traffic differs from VPN traffic across multiple dimensions (TLS behavior, packet length sequence, connection duration, DNS queries, etc.), the Class I negative sample pairs provide the basic classification boundaries.

[0110] Retrieve the associated VPN semantic vector from the historical VPN semantic vector. The VPN type corresponding to the associated VPN semantic vector belongs to the same VPN protocol family as the historical VPN semantic vector but is a different protocol variant. Specifically: if the historical VPN semantic vector comes from the Vmess protocol variant of V2Ray, then its associated VPN semantic vector can come from the Vless protocol variant of V2Ray; if it comes from the original Trojan protocol, then the associated semantic vector can come from the Trojan-GFW variant; if it comes from the original Shadowsocks protocol, then the associated semantic vector can come from the ShadowsocksR (SSR) variant or SS2022 version. The tag granularity of the associated VPN semantic vector belongs to the same VPN protocol family as the historical VPN semantic vector, but corresponds to different specific implementation versions or configurations.

[0111] By combining historical VPN semantic vectors with related VPN semantic vectors, multiple second-type negative sample pairs are obtained. These second-type negative sample pairs consist of semantic vector pairs belonging to the same VPN protocol family but different variants, and are considered hard negative samples (difficult to distinguish). The purpose of introducing second-type negative sample pairs is to enhance the model's ability to distinguish between different variants within the same VPN protocol family—for example, enabling the model to differentiate between Vmess and Vless, both V2Ray family variants with different implementations. If only first-type negative sample pairs (VPN vs HTTPS) are used, the model may only learn coarse-grained binary classification boundaries and ignore behavioral differences between VPN protocol variants, resulting in insufficient recognition ability when faced with new variants. By introducing hard negative sample constraints for protocol variants, the model is forced to learn subtle behavioral differences between different versions / configurations of the same protocol type during optimization, thereby achieving stronger generalization ability.

[0112] A contrastive learning model was trained using positive sample pairs, first-class negative sample pairs, and second-class negative sample pairs as sample data, based on the InfoNCE loss function.

[0113] The InfoNCE loss function is used to maximize the similarity of positive sample pairs, minimize the similarity of first-class negative sample pairs, and minimize the similarity of second-class negative sample pairs.

[0114] The optimization objective of the InfoNCE loss function is to, given a sample as an anchor, ensure that the similarity of positive samples in the embedding space is significantly higher than the similarity of all negative samples (including both Class I and Class II negative samples), thereby learning a discriminative embedding representation. The loss function can be supplemented with a distance constraint term for hard negative samples from protocol variants, forcibly widening the semantic distance between samples from different variants within the same protocol family in the embedding space.

[0115] In some embodiments, a two-stage training paradigm of "self-supervised pre-training + supervised fine-tuning" is adopted in terms of training strategy. The first stage involves self-supervised contrastive learning pre-training on large-scale unlabeled traffic data, utilizing a self-supervised construction mechanism of positive and negative sample pairs (without manual annotation) to learn a general traffic behavior representation. The pre-training data can cover various traffic scenarios and protocol types to enhance the breadth of representation learning coverage. The second stage involves supervised fine-tuning on manually labeled VPN type data, utilizing the precise protocol type labels to specifically improve the model's recognition accuracy for specific VPN types (V2Ray, Trojan, Shadowsocks, and their variants). This two-stage training strategy balances the generality of representation learning with the specificity of task recognition.

[0116] In this embodiment, by introducing protocol variants as a second type of negative sample pair (hard negative samples), the contrastive learning model can learn not only the coarse-grained classification boundary between VPN traffic and HTTPS traffic, but also the fine-grained differences within the same VPN protocol family (such as Vmess vs vless, Trojan vs Trojan-GFW, SS vs SSR). This design overcomes the limitation of traditional binary classification methods in distinguishing protocol variants and improves the model's adaptability to frequent updates of VPN protocol variants. When a new protocol variant appears, because the model has already learned the distinguishing patterns of variants within the same protocol family during the training phase, it can still maintain reasonable recognition generalization when facing new variants, without having to rely entirely on timely updates of the fingerprint database. At the same time, the self-supervised pre-training mechanism enables the model to learn general behavioral representations using a large amount of unlabeled traffic data, reducing the dependence on finely labeled data.

[0117] In step S600, traffic identification is performed on the traffic to be identified based on a contrastive learning model to obtain a traffic type determination result for the traffic to be identified. This includes the following steps: Step S601: Obtain the embedding space based on the contrastive learning model. The embedding space includes normalized embedding vectors corresponding to multiple sample data.

[0118] During the model training phase, all training samples (historical HTTPS semantic vectors and historical VPN semantic vectors) are mapped by the contrastive learning model, forming a structured distribution in the embedding space—similar traffic clusters are formed, while dissimilar traffic clusters maintain sufficient distance. The normalized embedding vectors are unit vectors after L2 normalization. All normalized embedding vectors lie on the unit hypersphere, allowing the similarity between vectors to be directly measured by the inner product or Euclidean distance, resulting in high computational efficiency and uniform dimensions.

[0119] Step S602: Obtain the initial semantic vector corresponding to the traffic to be identified, and input the initial semantic vector into the contrastive learning model to obtain the semantic vector to be identified mapped to the embedding space.

[0120] The initial semantic vector extraction process is consistent with the semantic vector extraction process of the training samples, that is, the behavior data extraction (same as step S200), behavior vector transformation (same as step S300), and semantic space mapping and fusion (same as step S400) are performed sequentially to ensure that the same feature extraction pipeline is used in the training and inference stages. The contrastive learning model further maps the initial semantic vectors to the embedding space constructed in the training stage to maintain the consistency between the training space and the inference space.

[0121] Step S603: Use the KNN classifier to find multiple nearest-neighbor normalized embedding vectors of the semantic vector to be identified in the embedding space.

[0122] The KNN classifier calculates the similarity (e.g., cosine similarity) between the semantic vector to be identified and all normalized embedding vectors in the embedding space, and selects the K vectors with the highest similarity as nearest neighbors. For example, the value of K can be set to 5, which strikes a balance between classification stability and computational efficiency: a value of K that is too small (e.g., K=1) is easily affected by noisy samples, while a value of K that is too large may cause out-of-class samples to be mixed into the nearest neighbor set.

[0123] Step S604: Determine the traffic types corresponding to multiple nearest neighbor normalized embedding vectors. Traffic types include VPN traffic and HTTPS traffic. VPN traffic can be further subdivided into specific types such as V2Ray, Trojan, and Shadowsocks. Each normalized embedding vector is associated with the traffic type label of its source traffic during the training phase, and this label information serves as the known classification basis during the identification phase.

[0124] Step S605: Obtain the proportion of each traffic type in multiple nearest neighbor normalized embedding vectors, and determine the traffic type with the highest proportion as the predicted type of the traffic to be identified. For example, if 3 of the 5 nearest neighbors correspond to VPN traffic (2 of which are V2Ray and 1 is Trojan) and 2 correspond to HTTPS traffic, then the proportion of VPN traffic is 60%, the proportion of HTTPS traffic is 40%, and the predicted type is determined to be VPN traffic (and can be further determined to be the specific subtype with the highest proportion).

[0125] The confidence score is determined by the proportion of traffic corresponding to the predicted type in multiple nearest neighbor normalized embedding vectors. In the example above, the confidence score is 60%, or 0.6. The confidence score quantifies the reliability of the classification decision, providing security operations personnel with a quantitative reference for credibility—high confidence (e.g., ≥0.8) indicates that the traffic to be identified is highly similar to known VPN traffic in the embedding space, which can directly trigger a high-risk alarm; medium confidence (e.g., 0.5-0.8) indicates that there is some uncertainty, and it is recommended to combine it with other dimensions of information to assist in the judgment; low confidence (e.g., <0.5) indicates that the behavioral characteristics of the traffic to be identified are not typical enough, and manual review may be required.

[0126] In this embodiment, a KNN classifier can perform nearest neighbor retrieval in the embedding space constructed through contrastive learning, achieving traffic type determination in a parameter-free manner. This avoids the cumbersome process of training a separate binary classifier for each VPN protocol in traditional methods. In the embedding space, newly added VPN protocol type samples only need to have their semantic vectors registered; the KNN classifier can then naturally cover the new category, demonstrating good scalability. Furthermore, by outputting confidence scores rather than simple binary classification results, a quantitative credibility reference is provided for security operation decisions, supporting differentiated tiered response strategies. For example, high-confidence alarms can be prioritized and automatically blocked, while low-confidence alarms can be manually reviewed or logged for subsequent analysis.

[0127] In some embodiments, after obtaining the traffic type determination result of the traffic to be identified, the method further includes the following steps S701-S702: Step S701: Obtain the internal network user IP and session 5-tuple corresponding to the traffic to be identified. The session 5-tuple includes the source IP, destination IP, source port, destination port, and transport layer protocol.

[0128] The internal network user IP is the user's private IP address before Network Address Translation (NAT) at the network exit. The session 5-tuple is used to uniquely identify the network session. By obtaining both the internal network user IP and the session 5-tuple, traffic identification results can be accurately associated with specific users and sessions at the network exit, avoiding multi-user confusion caused by NAT's many-to-one mapping.

[0129] Step S702: Based on the preset user-IP mapping table, query the user identity information according to the intranet user IP and session 5-tuple, and output alarm information according to the user identity information.

[0130] The user-IP mapping table can be obtained from a Dynamic Host Configuration Protocol (DHCP) server or an Authentication, Accounting and Authorization (AAA) server, which records the correspondence between each internal network IP address and user identity information (such as username, employee ID, department, contact information, etc.). By performing mapping queries on internal network user IPs, specific users using VPN applications can be accurately located, transforming traffic-level identification results into actionable user-level information.

[0131] Alarm information can be output in JSON format for easy integration with Security Operations Center (SOC) or Security Information and Event Management (SIEM) systems. Specifically, the alarm JSON object includes the following fields: timestamp (time stamp of the alarm), user_ip (internal network user IP address), user_name (user name), department (user's department), app_type (detected VPN application type, such as V2Ray, Trojan, or Shadowsocks), confidence (confidence score, a floating-point number from 0 to 1), risk_level (risk level, such as high, medium, or low), suspect_features (list of suspect features, recording key behavioral dimensions that triggered identification and their abnormal descriptions), and flow_info (a five-tuple containing source IP, destination IP, source port, destination port, and protocol type). This JSON alarm format provides the security operations team with complete event context information, allowing operations personnel to quickly determine the authenticity and severity of the alarm and take appropriate security intervention measures.

[0132] In this embodiment, by associating traffic identification results with internal network user identity information, a complete closed loop from "traffic identification" to "user location" can be achieved. This allows security operations personnel not only to know that VPN traffic exists, but also to accurately locate specific internal network users, their identity information, and their departments, supporting timely and effective security intervention and compliance management measures. Combining confidence scores and risk level tiered outputs, the operations team can establish differentiated alarm response strategies—for example, immediately initiating a security incident response process for high-confidence VPN alarms from high-risk users, and periodically summarizing and analyzing medium-confidence alarms from low-risk users.

[0133] The embodiments of this application have the following technical effects: 1. Strong behavioral fingerprinting capability: By deeply analyzing the behavioral fingerprint characteristics (TLS micro-behavior, packet length obfuscation mode, connection sequence, DNS pre-query, etc.) of cross-border VPN protocols such as V2Ray / Trojan / Shadowsocks, it can accurately identify spoofed traffic.

[0134] 2. Application identification is achieved without decryption. It does not rely on decrypting the encrypted payload, but only uses externally observable behavioral data such as TLS handshake characteristics, packet length sequence, and timing behavior to complete the identification, thus avoiding the limitation that encryption protocols are unbreakable.

[0135] 3. Large-scale contrastive learning has strong generalization ability. It does not require a large amount of labeled data. It can learn discriminative behavioral representations through self-supervised contrastive learning and has good generalization ability for protocol variants and unknown cross-border VPN applications.

[0136] 4. Multi-feature fusion improves recognition accuracy. It integrates five dimensions: TLS behavior, packet length sequence, time sequence pattern, DNS query, and statistical features, which has a stronger discriminative ability than single feature methods.

[0137] 5. Supports protocol variant detection. Through hard negative sample constraints and protocol variant differentiation training, it can identify different versions of the same VPN family (such as Vmess vs vless, Trojan vs Trojan-GFW).

[0138] 6. Precise user location: By combining contextual information such as internal network IP, session 5-tuple, and timestamp, accurate mapping from traffic to users is achieved, supporting security operation decisions.

[0139] 7. The alarm output includes information such as protocol type, suspected feature dimensions, and confidence level, which security analysts can quickly understand and handle.

[0140] Based on the same inventive concept, this application also provides a VPN identification system based on large model semantic embedding. The solution provided by this system is similar to the solution described in the above method. Therefore, the specific limitations of the VPN identification system based on large model semantic embedding provided below can be found in the limitations of the VPN identification method based on large model semantic embedding above, and will not be repeated here.

[0141] In one exemplary embodiment, such as Figure 2 As shown, a VPN identification system 200 based on large model semantic embedding is provided, including: The data acquisition module 201 is configured to acquire historical network connection traffic; the historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data. The feature extraction module 202 is configured to extract first historical behavior data based on the historical HTTPS traffic data and extract second historical behavior data based on the historical VPN traffic data. The vector conversion module 203 is configured to convert the first historical behavior data into a first historical behavior vector and the second historical behavior data into a second historical behavior vector. The semantic acquisition module 204 is configured to map the first historical behavior vector and the second historical behavior vector to a unified semantic space, and to fuse the semantically unified first historical behavior vector into a historical HTTPS semantic vector, and to fuse the semantically unified second historical behavior vector into a historical VPN semantic vector. The model training module 205 is configured to train a contrastive learning model using the historical HTTPS semantic vector and the historical VPN semantic vector as sample data; the contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic. The prediction module 206 is configured to perform traffic identification on the traffic to be identified based on the contrastive learning model, and obtain the traffic type determination result of the traffic to be identified.

[0142] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of a large model adaptive inference method for heterogeneous computing power collaboration as described above.

[0143] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0144] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The components described as separate parts may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0145] The above-described embodiments are merely illustrative of several implementation methods of the embodiments of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the embodiments of this application, and these modifications and improvements all fall within the protection scope of the embodiments of this application.

Claims

1. A VPN identification method based on large model semantic embedding, characterized in that, The method includes: Obtain historical network connection traffic; the historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data; First historical behavior data is extracted based on the historical HTTPS traffic data, and second historical behavior data is extracted based on the historical VPN traffic data. The first historical behavior data is converted into a first historical behavior vector, and the second historical behavior data is converted into a second historical behavior vector. The first historical behavior vector and the second historical behavior vector are mapped to a unified semantic space, and the first historical behavior vector after semantic unification is merged into a historical HTTPS semantic vector, and the second historical behavior vector after semantic unification is merged into a historical VPN semantic vector. A contrastive learning model is trained using the historical HTTPS semantic vector and the historical VPN semantic vector as sample data; the contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic. Based on the contrastive learning model, traffic identification is performed on the traffic to be identified, and the traffic type determination result of the traffic to be identified is obtained.

2. The VPN identification method based on large model semantic embedding according to claim 1, characterized in that, The process of identifying traffic based on the contrastive learning model includes: An embedding space is obtained based on the contrastive learning model; the embedding space includes normalized embedding vectors corresponding to multiple sample data. Obtain the initial semantic vector corresponding to the traffic to be identified, and input the initial semantic vector into the contrastive learning model to obtain the semantic vector to be identified mapped to the embedding space; The KNN classifier is used to find multiple nearest neighbor normalized embedding vectors of the semantic vector to be identified in the embedding space; Determine the traffic type corresponding to the plurality of nearest neighbor normalized embedding vectors; the traffic type includes VPN traffic or HTTPS traffic. Obtain the proportion of each traffic type in the plurality of nearest neighbor normalized embedding vectors, and determine the traffic type with the highest proportion as the predicted type of the traffic to be identified; and determine the proportion of the traffic corresponding to the predicted type in the plurality of nearest neighbor normalized embedding vectors as the confidence score.

3. The VPN identification method based on large model semantic embedding according to claim 1, characterized in that, The step of training a contrastive learning model using the historical HTTPS semantic vector and the historical VPN semantic vector as sample data includes: Determine the VPN type corresponding to the historical VPN semantic vector; the VPN type includes V2Ray, Trojan, and Shadowsocks. Combine any two historical VPN semantic vectors corresponding to the same VPN type to obtain multiple positive sample pairs; By combining any one of the historical HTTPS semantic vectors and any one of the historical VPN semantic vectors, multiple pairs of negative samples of the first type are obtained; Obtain the associated VPN semantic vector of the historical VPN semantic vector; the VPN type corresponding to the associated VPN semantic vector is a variant of the same VPN protocol as the historical VPN semantic vector but a different protocol. The historical VPN semantic vector and the associated VPN semantic vector are combined to obtain multiple second-type negative sample pairs; Using the positive sample pairs, the first type of negative sample pairs, and the second type of negative sample pairs as sample data, a contrastive learning model is trained based on the InfoNCE loss function; the InfoNCE loss function is used to maximize the similarity of the positive sample pairs, minimize the similarity of the first type of negative sample pairs, and minimize the similarity of the second type of negative sample pairs.

4. The VPN identification method based on large model semantic embedding according to claim 1, characterized in that, The first historical behavior data and the second historical behavior data include TLS handshake data, packet length sequence, time sequence data, DNS behavior data, and statistical traffic data; The TLS handshake data includes a sequence of Client Hello extended fields and a list of cipher suites; The packet length sequence includes the packet length sequence of the first 32 data packets after the TLS handshake is completed; The timing data includes connection establishment time and data packet arrival interval; The DNS behavior data includes the DNS query domain name before the connection is established; The statistical traffic data includes network round-trip time, traffic data volume, and connection duration.

5. The VPN identification method based on large model semantic embedding according to claim 4, characterized in that, The step of converting the first historical behavior data into a first historical behavior vector and the second historical behavior data into a second historical behavior vector includes: The Client Hello extended field sequence is One-Hot encoded to obtain a One-Hot vector; and the list of cipher suites is encoded into an Embedding vector through a pre-trained Embedding layer. The packet length sequence is Z-score normalized to form a packet length sequence vector. The mean, variance, and autocorrelation coefficient of the time series data are extracted to form a time series feature vector. The DNS query domain name is denoised and segmented to obtain the DNS behavior vector; The network round-trip time, the amount of traffic data, and the connection duration are concatenated to obtain a statistical traffic vector.

6. The VPN identification method based on large model semantic embedding according to claim 5, characterized in that, The step of fusing the semantically unified first historical behavior vector into a historical HTTPS semantic vector and the semantically unified second historical behavior vector into a historical VPN semantic vector includes: The multilayer perceptron (MLP) based on a 3-layer structure converts the One-Hot vector and the Embedding vector into a first semantic vector; the hidden layer dimensions corresponding to the 3-layer structure are 256, 128 and 64 dimensions respectively. Feature extraction is performed on the packet-length sequence vector based on a one-dimensional convolutional neural network, and a second semantic vector is generated after global average pooling. The temporal feature vector is processed using a Transformer self-attention encoder to generate a third semantic vector; The DNS behavior vector is semantically encoded based on the pre-trained BERT encoder to generate a fourth semantic vector; The multilayer perceptron (MLP) based on a three-layer structure maps the statistical flow vector to a fifth semantic vector. The first, second, third, fourth, and fifth semantic vectors are weighted and fused through an attention fusion layer to output a 128-dimensional semantic vector.

7. The VPN identification method based on large model semantic embedding according to claim 1, characterized in that, After obtaining the traffic type determination result of the traffic to be identified, the method further includes: Obtain the intranet user IP and session 5-tuple corresponding to the traffic to be identified; the session 5-tuple includes source IP, destination IP, source port, destination port, and transport layer protocol; Based on the preset user-IP mapping table, the user identity information is queried according to the intranet user IP and the session 5-tuple, and alarm information is output according to the user identity information.

8. A VPN identification system based on large model semantic embedding, characterized in that, include: The data acquisition module is configured to acquire historical network connection traffic; the historical network connection traffic includes historical HTTPS traffic data and historical VPN traffic data. The feature extraction module is configured to extract first historical behavior data based on the historical HTTPS traffic data and extract second historical behavior data based on the historical VPN traffic data; The vector conversion module is configured to convert the first historical behavior data into a first historical behavior vector and the second historical behavior data into a second historical behavior vector. The semantic acquisition module is configured to map the first historical behavior vector and the second historical behavior vector to a unified semantic space, and to fuse the semantically unified first historical behavior vector into a historical HTTPS semantic vector, and to fuse the semantically unified second historical behavior vector into a historical VPN semantic vector. The model training module is configured to train a contrastive learning model using the historical HTTPS semantic vector and the historical VPN semantic vector as sample data; the contrastive learning model is used to distinguish between VPN traffic and HTTPS traffic. The prediction module is configured to identify the traffic to be identified based on the contrastive learning model, and obtain the traffic type determination result of the traffic to be identified.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images