Method and device for dynamic configuration of multi-domain name distribution of VPN server, computer device and medium
By setting up a DNS query server that supports DoT, DoH, and DoQ locally on the VPN server, identifying and decrypting DNS query traffic, and combining this with reverse IP address lookup to achieve dynamic domain name traffic splitting, the problem of VPN servers being unable to identify encrypted traffic domain names is solved, achieving accurate, real-time, and secure domain name traffic splitting.
Patent Information
- Application Number
- CN202511342883.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-19
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2045-09-19
AI Technical Summary
Existing VPN servers cannot accurately identify domain name information in encrypted DNS query traffic and TLS-ECH traffic, resulting in ineffective domain name traffic splitting.
Configure a DNS query server that supports DoT, DoH, and DoQ locally on the VPN server. Set the server as a DNS server through the VPN client, identify and decrypt DNS query traffic, extract domain name information, and use the IP address to look up the local IP domain name mapping table when resolution fails. Combine the rule server and the central server to update the mapping table to achieve dynamic domain name traffic distribution.
Accurate, real-time, and secure domain name traffic splitting is achieved under conditions of fully encrypted DNS query traffic, TLS-ECH traffic, and QUIC traffic, avoiding modifications to VPN clients and ensuring the reliability and anonymity of traffic splitting.
Smart Images

Figure CN120825485B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Embodiments of the present application relate to the technical field of domain name distribution in a VPN scenario, and in particular to a dynamically configured VPN server multi-domain name distribution method and device, computer equipment and a medium. BACKGROUND
[0002] Currently, common Internet traffic is mainly HTTPS (Hypertext Transfer Protocol Secure) traffic and HTTP (Hypertext Transfer Protocol) traffic. HTTPS traffic is actually TLS (Transport Layer Security) traffic, such as traffic based on TLS 1.2 and traffic based on TLS 1.3 without ECH (Encrypted Client Hello). In addition, before sending HTTPS traffic and HTTP traffic to a server, a client will perform a DNS (Domain Name System) query to obtain an IP (Internet Protocol) address.
[0003] In many scenarios of VPN (Virtual Private Network), there is a strong demand for domain name distribution, for example, cross-border traffic needs to be audited for export, while domestic traffic is directly forwarded locally. At this time, only accurate identification of domain names can automatically distinguish between domestic and foreign websites. For another example, a company intranet requires encrypted private lines to reduce latency, while Internet traffic goes through local broadband. At this time, the traffic also needs to be distributed according to domain names. In the past, DNS query traffic was in plaintext, and a VPN server could obtain domain name information by analyzing Query (i.e., the entire DNS query packet, which contains DNS query information in plaintext) on UDP (User Datagram Protocol) port 53. For traffic based on TLS 1.3 without ECH, the VPN server can obtain the domain name information that the user wants to access by analyzing the SNI (Server Name Indication) field in the Client Hello packet. For plaintext HTTP traffic, the VPN server can directly read the domain name information from the Host field in the packet header.
[0004] However, with the development of Internet security, more and more traffic is encrypted, and traditional domain name recognition methods based on plaintext DNS query information, the SNI field of TLS traffic or the Host field of HTTP traffic have been completely invalidated. For example, after DNS query traffic is encrypted as DoH (DNS over HTTPS), DoT (DNS over TLS) or DoQ (DNS over QUIC), the UDP 53 port no longer appears plaintext Query, and the VPN server cannot obtain domain name information by parsing the DNS query message; and after the TLS traffic joins the ECH extension, the SNI field in the ClientHello packet is encrypted, and the VPN server cannot directly read the domain name accessed by the user from the SNI field even if it can intercept the HTTPS or QUIC initial packet. Since the domain name accessed by the traffic cannot be analyzed, the traffic cannot be domain name shunted subsequently. SUMMARY
[0005] The present application provides a dynamically configured VPN server multi-domain name shunting method, device, computer equipment and medium aiming at the above-mentioned deficiencies or shortcomings. The method can accurately, in real time and safely shunt the encrypted traffic by domain name.
[0006] The present application provides a dynamically configured VPN server multi-domain name shunting method according to the first aspect, which is applied to a VPN server; the method comprises: receiving traffic from a VPN client, the VPN client setting the VPN server as a DNS server when establishing a VPN connection with the VPN server; identifying whether the traffic belongs to DNS query traffic or non-DNS query traffic; when the traffic belongs to DNS query traffic, forwarding the traffic to a local DNS query server, obtaining DNS response information returned by the DNS query server, extracting IP address and domain name information from the DNS response information, and updating the local IP domain name mapping table; when the traffic belongs to non-DNS query traffic, performing domain name resolution on the traffic; when the domain name resolution is successful, performing a domain name shunting operation according to the domain name information obtained by the resolution, updating the target IP address of the traffic and the domain name information obtained by the resolution to the local IP domain name mapping table; when the domain name resolution fails, querying the local IP domain name mapping table according to the target IP address of the traffic, and performing a domain name shunting operation according to the domain name information found.
[0007] In some embodiments, identifying whether the traffic belongs to DNS query traffic or non-DNS query traffic comprises: detecting whether the traffic belongs to any one of plaintext DNS query request, DoH request, DoT request and DoQ request; if yes, marking the traffic as DNS query traffic; if no, marking the traffic as non-DNS query traffic.
[0008] In some embodiments, the domain name resolution of the traffic comprises: detecting whether the traffic belongs to TCP traffic or UDP traffic; when the traffic belongs to TCP traffic, detecting whether the traffic belongs to HTTPS traffic or HTTP traffic; when the traffic belongs to HTTPS traffic, obtaining a client greeting message related to the traffic, and extracting domain name information from the client greeting message; when the traffic belongs to HTTP traffic, extracting Host field information from a HTTP request header, and extracting domain name information from the Host field information; when the traffic belongs to UDP traffic, obtaining a QUIC initial packet related to the traffic, decrypting the QUIC initial packet using a public key, and extracting domain name information from an SNI field in the decrypted QUIC initial packet; when the domain name information is extracted from the traffic, determining that the domain name resolution is successful; and when the domain name information is not extracted from the traffic, determining that the domain name resolution fails.
[0009] In some embodiments, the domain name shunting operation is performed according to the resolved domain name information, comprising: detecting whether there is a forwarding record matching the resolved domain name information in the local domain name forwarding rule; if there is, determining a target shunting server according to the forwarding record matching the resolved domain name information, and forwarding the traffic to the target shunting server; and if there is not, sending the traffic to the public network.
[0010] In some embodiments, the method further comprises: periodically pulling the local country's domain name forwarding rule from a rule server, and storing the pulled domain name forwarding rule locally; and the rule server stores a plurality of country's domain name forwarding rules predefined by a user.
[0011] In some embodiments, the method further comprises: periodically extracting domain name information from the domain name forwarding rule as a domain name to be shunted; querying a DNS query server for an IP address corresponding to the domain name to be shunted; and updating a local IP domain name mapping table according to the domain name to be shunted and the IP address corresponding thereto.
[0012] In some embodiments, the method further comprises: sending the local IP domain name mapping table to a local center server; the local center server is configured to aggregate the local IP domain name mapping tables sent by each VPN server in the local country, and send the aggregated IP domain name mapping table to each VPN server in the local country; and upon receiving the aggregated IP domain name mapping table returned by the local center server, updating the local IP domain name mapping table according to the aggregated IP domain name mapping table.
[0013] The application provides a dynamically configured VPN server multi-domain name shunting device according to a second aspect. The device is applied to a VPN server, and comprises:
[0014] The traffic receiving module is configured to receive traffic from a VPN client, and the VPN client sets the VPN server as a DNS server when establishing a VPN connection with the VPN server.
[0015] The traffic type identifying module is configured to identify whether the traffic belongs to DNS query traffic or non-DNS query traffic.
[0016] The DNS query traffic processing module is configured to, when the traffic belongs to DNS query traffic, forward the traffic to a local DNS query server, and extract IP address and domain name information from DNS response information returned by the DNS query server and update the IP address and domain name information to a local IP domain name mapping table.
[0017] The non-DNS query traffic processing module is configured to, when the traffic belongs to non-DNS query traffic, perform domain name resolution on the traffic, perform domain name shunting according to domain name information obtained through the domain name resolution when the domain name resolution is successful, and update a target IP address of the traffic and the domain name information obtained through the domain name resolution to the local IP domain name mapping table.
[0018] According to a third aspect, the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the dynamic configuration method of the VPN server multi-domain name shunting method according to any one of the above embodiments.
[0019] According to a fourth aspect, the present application provides a computer device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor is executed to implement the steps of the dynamic configuration method of the VPN server multi-domain name shunting method according to any one of the above embodiments.
[0020] The above embodiments of the present application can accurately, timely and safely perform domain name shunting on traffic in the case of full encryption of DNS query traffic, full hiding of SNI fields of TLS-ECH traffic and QUIC traffic.
[0021] Specifically, the application locally sets a DNS query server supporting DoT, DoH and DoQ on the VPN server, and sets the VPN server as the DNS server when the VPN client establishes a VPN connection with the VPN server. Based on this, the DNS query traffic and non-DNS query traffic of the VPN client are sent to the VPN server. Since the DNS query server is locally set, the encryption barrier of DoH, DoT and DoQ can be bypassed to obtain the domain name information accessed by the DNS query traffic. When processing the DNS query traffic and non-DNS query traffic, the VPN server analyzes the domain name information and IP address of the traffic, and writes the domain name information and IP address of the traffic into the local IP domain name mapping table to construct the mapping relationship between the domain name information and the IP address. Further, when the domain name cannot be resolved from the non-DNS query traffic, the IP address accessed by the non-DNS query traffic can be used to look up the local IP domain name mapping table, so as to bypass the encryption barrier of ECH. Subsequently, the domain name information found can be used to perform domain name shunting operation. In addition, the domain name resolution operation can be placed on the VPN client side, but considering that it is difficult to update the resolution rules when the VPN client performs traffic resolution, and the compatibility of different platforms is also different, therefore, the application places all the domain name resolution and shunting logic on the VPN server side, so that there is no need to modify the VPN client, and the user cannot perceive a series of operations such as domain name resolution and domain name shunting. It should be noted that the content of the local IP domain name mapping table can be continuously and dynamically updated in various ways (such as DNS query traffic processing, domain name resolution of non-DNS query traffic, active detection of IP addresses of domain names to be shunted, synchronization of IP domain name mapping data nationwide through the domestic center server, etc.), which can realize continuous shunting without downtime. BRIEF DESCRIPTION OF DRAWINGS
[0022] Figure 1 Flow chart of the dynamic configuration VPN server multi-domain name shunting method in one or more embodiments of the application;
[0023] Figure 2 Structure diagram of the dynamic configuration VPN server multi-domain name shunting device in one or more embodiments of the application;
[0024] Figure 3 Internal structure diagram of a computer device in one or more embodiments of the application. DETAILED DESCRIPTION
[0025] In order to make the purposes, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings. It should be noted that the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work belong to the scope of protection of the present application.
[0026] The following description refers to the accompanying drawings. Unless otherwise indicated, same or similar elements in different drawings are denoted by the same reference numerals. The embodiments described in the following exemplary embodiments do not represent all the embodiments consistent with the present application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.
[0027] In the description of the present application, it should be understood that the terms "first", "second", "third" and the like are only used to distinguish similar objects, and do not necessarily indicate a specific order or sequence, nor can they be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to the specific circumstances. In addition, in the description of the present application, "a plurality of" means two or more, unless otherwise specified. "And / or", which describes the association between objects, means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after it.
[0028] In view of the deficiencies or defects of the related art, the present application provides a dynamic configuration VPN server multi-domain name distribution method. The method can accurately, in real time and safely distribute traffic by domain name under the condition that DNS query traffic is fully encrypted, TLS-ECH traffic and QUIC traffic fully hide the SNI field.
[0029] The method will be described below through some exemplary embodiments. In some embodiments, the method includes the steps as shown in Figure 1 The following is an explanation of each step.
[0030] S110: receiving traffic from a VPN client.
[0031] The present method is applied to a VPN server. In the present application, the VPN server refers to a single physical or virtual computing node that can establish an encrypted tunnel with a VPN client and bear the traffic entrance, DNS recursion, domain name identification and distribution decision. The VPN client refers to a terminal software or hardware module that can initiate an encrypted tunnel connection to the VPN server and point its own DNS server address to the VPN server.
[0032] When the VPN client establishes a VPN connection with the VPN server, the VPN server is set as the DNS server, so the VPN client sends all DNS query requests to the VPN server.
[0033] The local of the VPN server at least includes a TUN, a DNS query server, and an IP traffic forwarding server. The local refers to the same physical or virtual host, and the TUN, the DNS query server, and the IP traffic forwarding server are all running in the VPN server local process space or kernel space, and they can interact through a loopback interface or a memory bus without crossing a network or a node.
[0034] TUN is the abbreviation of Tunnel interface, which is a virtual network interface device provided by the Linux or Unix kernel. It can directly hand over the IP packets received by the operating system to the user space program (such as the VPN process, i.e., the process of the VPN server), and the IP packets written by the user space program are also routed as “from a certain network card” by the kernel. Therefore, in the VPN scenario, after the VPN server creates a TUN device, all tunnel traffic (which can be referred to as VPN traffic) of the client will first enter the kernel, then be read by the VPN process through the TUN device, then be split or forwarded by the VPN process, and finally be written back to the TUN or physical network card, so as to realize user space controllable routing.
[0035] The DNS query server can be a DNS recursive server or a DNS forwarder (i.e., Forwarder) deployed in the same host as the VPN server. The DNS query server is used to decrypt the DoT request, DoH request, and DoQ request sent by the VPN client, so it needs to support DoH, DoT, and DoQ protocols, and can return standard DNS response information to the VPN server.
[0036] The IP traffic forwarding server is not a separate machine, but a local forwarding module (which can be a user space process or a kernel module) inside the VPN server. The IP traffic forwarding server can listen to external ports, such as listening to one or more TCP or UDP ports (such as TCP ports 443 and 80, UDP port 53, or other arbitrary ports) on the VPN server local machine. It is responsible for establishing an encrypted tunnel with the VPN client and receiving VPN data packets sent by the VPN client. It will forward the traffic of the VPN client to the VPN server for traffic type identification, domain name resolution, and domain name splitting, and will also write the traffic to the TUN (i.e., direct out the default route), internal socket (i.e., to the shunting server), or physical network card (i.e., directly forward through the pseudo port) according to the domain name splitting decision result of the VPN server.
[0037] The traffic of the VPN client is specifically IP packets (also referred to as IP data packets). Regardless of whether the VPN client adopts the DNS, HTTP, HTTPS or QUIC protocol, the data sent by the VPN client to the VPN server is encapsulated into IP packets (which can be IPv4 or IPv6) when passing through the VPN tunnel, and the data packet received by the VPN server is specifically an IP packet composed of a target IP address, a destination port and payload data.
[0038] S120: Identify whether the traffic belongs to DNS query traffic or non-DNS query traffic.
[0039] After receiving the traffic of the VPN client, the VPN server needs to identify the type of the traffic, specifically whether the traffic belongs to DNS query traffic or non-DNS query traffic. The identification operation can be to detect whether the traffic belongs to any one of the following: plaintext DNS query request, DoH request, DoT request and DoQ request; if yes, the traffic is marked as DNS query traffic; if no, the traffic is marked as non-DNS query traffic.
[0040] Among them, the VPN server can detect whether the destination port information of the traffic is UDP 53 port, if yes, it can be determined that the traffic is plaintext DNS query request. Then, since the DNS query server is locally deployed, it supports DoH, DoT and DoQ protocols, therefore, if the traffic is encrypted DNS query traffic (such as DoH request, DoT request or DoQ request), the DNS query server can successfully decrypt it, and the decrypted result is plaintext DNS query request, if the traffic is not encrypted DNS query traffic, the decryption operation performed by the DNS query server will fail, therefore, if the destination port information of the traffic is not UDP 53 port, first decrypt it, if the decryption is successful, it is determined that the traffic is DoH request, DoT request or DoQ request, if the decryption fails, it is determined that the traffic is non-DNS query traffic.
[0041] S130: When the traffic belongs to DNS query traffic, forward the traffic to the local DNS query server, and when the DNS response information returned by the DNS query server is obtained, extract the IP address and domain name information from the DNS response information and update to the local IP domain name mapping table.
[0042] When the traffic belongs to DNS query traffic (DNS query request in plaintext, DoH request, DoT request or DoQ request), the outer VPN tunnel encapsulation information (such as UDP / TCP or TUN encapsulation information of a virtual network card) of the traffic can be removed to obtain the original message (which can be a UDP or TCP message), and then the original message is forwarded to the DNS query server through a loopback interface (or a Unix socket).
[0043] The DNS query server removes the Ethernet, IP, UDP (TCP) header information in the original message to obtain the DNS query request. If the DNS query request is a DoT request, a DoH request or a DoQ request, decryption needs to be performed (decryption is a conventional means and will not be described here) to obtain the DNS query request in plaintext; if the DNS query request is a DNS query request in plaintext, decryption does not need to be performed. After obtaining the DNS query request in plaintext, the domain name information can be extracted therefrom, and then the IP address corresponding to the domain name information is queried according to a conventional recursive process, and a standard DNS response information is generated. The DNS query server returns the DNS response information to the VPN server. The VPN server returns the DNS response information to the VPN client, and extracts the IP address and domain name information from the DNS response information and updates the local IP domain name mapping table to construct the mapping relationship between the IP address and the domain name information.
[0044] The mapping relationship in the local IP domain name mapping table can be stored in a key-value structure, in which the IP address is the key and the domain name information is the value, for example, the domain name information corresponding to 1.1.1.1 is example.com.
[0045] Through step S130, the VPN server can forward the DNS query traffic of the VPN client to the local DNS query server when the user is normally surfing the Internet, and after receiving the DNS response information returned by the DNS query server, the domain name information and the IP address in the DNS response information are extracted through bypassing and recorded in the local IP domain name mapping table, so that accurate mapping for real-time access of the user can be provided when the VPN server fails to successfully parse the traffic of the VPN client, and the domain name shunting can still be accurately performed when the traffic is encrypted traffic.
[0046] S140: When the traffic belongs to non-DNS query traffic, performing domain name resolution on the traffic; when the domain name resolution succeeds, performing domain name distribution operation according to the domain name information obtained by the resolution, and updating the target IP address of the traffic and the domain name information obtained by the resolution to the local IP domain name mapping table; when the domain name resolution fails, querying the local IP domain name mapping table according to the target IP address of the traffic, and performing domain name distribution operation according to the domain name information found.
[0047] When the traffic belongs to non-DNS query traffic, the traffic is subjected to domain name resolution. If domain name information can be resolved from the traffic (indicating that the domain name resolution succeeds), domain name distribution operation is performed using the resolved domain name information, and a mapping relationship is established between the resolved domain name and the target IP address of the traffic. The above operation extracts the SNI field or the Host field by performing deep packet detection on HTTPS, QUIC and HTTP traffic, so as to obtain domain name information and IP address. The domain name information and the corresponding IP address are written into the local IP domain name mapping table, which can supplement the mapping data in the non-DNS query scenario (such as long connection, connection multiplexing, cache hit, etc.), and improve the freshness of the mapping records in the local IP domain name mapping table.
[0048] If domain name information cannot be resolved from the traffic (indicating that the domain name resolution fails), the target IP address is extracted from the traffic, and the corresponding domain name information is retrieved from the local IP domain name mapping table using the target IP address. Then, the domain name distribution operation is performed using the found domain name information. In this way, the accuracy of real-time resolution and the coverage of historical mapping are combined, and high-reliability domain name distribution effect is achieved in the case of encrypted traffic, missing SNI field (i.e. decryption failure), etc.
[0049] In the above operation, the operation of performing domain name resolution on the traffic can include: detecting whether the traffic belongs to TCP traffic or UDP traffic; when the traffic belongs to TCP traffic, detecting whether the traffic belongs to HTTPS traffic or HTTP traffic; when the traffic belongs to HTTPS traffic, obtaining a client hello packet related to the traffic, and extracting domain name information from the client hello packet; when the traffic belongs to HTTP traffic, extracting Host field information from the HTTP request header, and extracting domain name information from the Host field information; when the traffic belongs to UDP traffic, obtaining a QUIC initial packet related to the traffic, decrypting the QUIC initial packet using a public key, and extracting domain name information from the SNI field in the decrypted QUIC initial packet (i.e. QUIC Initial Packet); in the above operation, if domain name information can be extracted from the traffic, it is determined that the domain name resolution succeeds, and if domain name information cannot be extracted from the traffic, it is determined that the domain name resolution fails.
[0050] According to the domain name information obtained by analysis (or the domain name information found), a domain name shunting operation is performed, including: detecting whether there is a forwarding record in the local domain name forwarding rule that matches the domain name information obtained by analysis (or the domain name information found); if there is, determining a target shunting server according to the forwarding record that matches the domain name information obtained by analysis, and forwarding the traffic to the target shunting server; if there is not, directly sending the traffic to the public network.
[0051] In some embodiments, the method further includes: timing to pull the country's domain name forwarding rule from the rule server, and storing the pulled domain name forwarding rule locally; the rule server stores a plurality of country's domain name forwarding rules defined by the user in advance.
[0052] The rule server can be a centralized configuration node deployed in the cloud and independent of the VPN server, and is used to store and distribute a plurality of country's domain name forwarding rules defined by the user in advance. Generally, each country corresponds to a plurality of domain name forwarding rules.
[0053] The domain name forwarding rule is a structured configuration record for describing the mapping relationship of the domain name list and the next hop address, for example, example1.com needs to be forwarded to 1.2.3.4 or 2.3.4.5, and example2.com needs to be forwarded to 6.7.8.9. The VPN server is divided into two categories in this application, one needs to be connected with the VPN client, and the other does not need to be connected with the VPN client, and only needs to be responsible for distribution. Unless otherwise specified, "VPN server" in this paper refers to the VPN server that needs to be connected with the VPN client, and "VPN distribution server" refers to the VPN server that does not need to be connected with the VPN client and is only responsible for distribution. Through the above classification, the VPN server that allows users to connect and the VPN server that actually converts the outlet of traffic can be separated into two independent machines. Specifically, the VPN server will expose public IP to the outside, be responsible for establishing a tunnel with the VPN client, performing domain name recognition, and deciding whether to distribute, so that the user's traceroute, ipinfo.io can only see these IP addresses, and think that the traffic goes out from these IP addresses. The distribution VPN server does not hang public IP and does not accept any connection of the VPN client, only accepts "internal forwarding" traffic from the VPN server, which specially converts the traffic of specified domain names (i.e. domain names to be distributed) again (to meet the needs of unlocking, compliance, low-cost outlet and / or anonymity, etc.), and is completely invisible to users. Since the IP address of the distribution VPN server will not appear on the Internet, the user side can only find the IP address of the VPN server, and cannot perceive that there is a next hop after the VPN server, so the anonymity and anti-blocking ability can be improved, and if the VPN server fails, the distribution VPN server can be quickly switched, and the distribution VPN server can be horizontally expanded, without affecting each other, so that the availability of the entire system is stronger.
[0054] The domain name forwarding rule supports organization by country, and can also support global or regional effect.
[0055] The local domain name forwarding rule refers to the rule subset corresponding to the country where the VPN server is located in the rule server. The rule server can find the rules corresponding to the home information (including the identification information of the country where the VPN server is located) from all rule information according to the home information reported by the VPN server (the VPN server can report regularly, such as reporting every 30 seconds), as the local domain name forwarding rule, and then send these rules to the VPN server. The VPN server will store these rules, and judge the distribution mode of the traffic according to the rules and the domain name related to the traffic of the VPN client.
[0056] In some embodiments, the method further comprises: timing extracting domain name information from the domain name forwarding rule as a domain name to be shunted; querying the DNS query server for the IP address corresponding to the domain name to be shunted; and updating the local IP domain name mapping table according to the domain name to be shunted and the IP address corresponding thereto.
[0057] The VPN server can query the DNS information of the domain name to be shunted through a timing DNS query thread (the query frequency can be set as needed, such as querying once every 30 seconds or once every 1 minute), for example, the domain name information to be shunted in the domain name forwarding rule is example.com, and the A query (for querying IPv4 address) and / or AAAA query (for querying IPv6 address) are initiated to the local DNS query server using the domain name information, so as to obtain the IP address list corresponding to the domain name information, for example, [6.6.6.6, 7.7.7.7], and then each IP address in the IP address list and the domain name information are written into the local IP domain name mapping table as a key-value pair (such as 6.6.6.6-example.com, 7.7.7.7-example.com), so as to ensure that the popular domain name to be shunted always has the latest mapped IP address, avoiding the problem that the user has not checked, but the IP address has changed (such as the domain name behind the Baidu CDN, each DNS response may give different IP set. If the local IP domain name mapping table only records the old IP address at the last user access time, when the user connects again, the CDN has changed the IP address to a new node, but the local IP domain name mapping table still records the old record, which will cause the operation of using the target IP address of the traffic to check the domain name to fail, and then the domain name shunting rule is invalid, the traffic is wrongly sent to the default outlet, resulting in unlocking failure or compliance violation, etc.), or the problem of zero access leading to the vacancy of the local IP domain name mapping table (for example, some domain names are written into the domain name forwarding rule, but there is no VPN client to access it for a long time, so the local IP domain name mapping table has never recorded the domain name or the previously recorded domain name has expired. When the first user suddenly initiates HTTPS-ECH connection (without SNI field), the VPN server can only know the target IP address of the traffic, but the IP address is not found in the local IP domain name mapping table, so the domain name shunting operation cannot be performed, and the traffic can only be sent directly to the public network).
[0058] In some embodiments, the method further comprises: sending the local IP domain name mapping table to a home center server; the home center server is configured to aggregate the local IP domain name mapping tables sent by the VPN servers in the home country, and send the aggregated IP domain name mapping table to the VPN servers in the home country; and upon receiving the aggregated IP domain name mapping table returned by the home center server, updating the local IP domain name mapping table according to the aggregated IP domain name mapping table.
[0059] The VPN server periodically reports the full data or incremental data of the local IP domain name mapping table to a home center server, which refers to a center server in the same country as the VPN server. It can be a cloud-deployed aggregation node independent of the VPN server.
[0060] The home center server can aggregate (i.e., aggregate and deduplicate) the IP domain name mapping tables reported by each VPN server in the home country to obtain an aggregated IP domain name mapping table, i.e., a national-level IP domain name mapping table, and periodically push the national-level IP domain name mapping table to each VPN server in the home country. After receiving the national-level IP domain name mapping table pushed by the home center server, the VPN server merges it with the local IP domain name mapping table to obtain a new local IP domain name mapping table. In this embodiment, when the VPN server fails to successfully resolve the traffic of the VPN client, the domain name reverse lookup can also be completed with the IP domain name mapping data recorded by other VPN servers in the home country, which can improve the recognition rate of encrypted traffic.
[0061] It should be noted that, as for each step included in the dynamic configuration VPN server multi-domain name distribution method provided in any one of the above embodiments, unless otherwise specified in this document, the execution of these steps does not have strict order restrictions, and these steps can be executed in other orders. Moreover, at least part of these steps can include multiple sub-steps or multiple stages, which do not necessarily be executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages does not necessarily be sequential, but can be executed in rotation or alternation with at least part of other steps or sub-steps or stages of other steps.
[0062] Based on the same inventive concept, the present application also provides a dynamic configuration VPN server multi-domain name distribution device. In some embodiments, the dynamic configuration VPN server multi-domain name distribution device is applied to a VPN server, as shown in Figure 2 The device comprises the following modules:
[0063] The traffic receiving module 110 is configured to receive traffic from a VPN client, and the VPN client sets the VPN server as a DNS server when establishing a VPN connection with the VPN server.
[0064] The traffic type identifying module 120 is configured to identify whether the traffic belongs to DNS query traffic or non-DNS query traffic.
[0065] The DNS query traffic processing module 130 is configured to, when the traffic belongs to DNS query traffic, forward the traffic to a local DNS query server, and extract IP address and domain name information from DNS response information returned by the DNS query server and update the local IP domain name mapping table when the DNS response information is obtained.
[0066] The non-DNS query traffic processing module 140 is configured to, when the traffic belongs to non-DNS query traffic, perform domain name resolution on the traffic, perform domain name shunting according to domain name information obtained by the domain name resolution when the domain name resolution is successful, and update the local IP domain name mapping table with the target IP address of the traffic and the domain name information obtained by the domain name resolution.
[0067] In some embodiments, the traffic type identifying module 120 identifies whether the traffic belongs to DNS query traffic or non-DNS query traffic, including: detecting whether the traffic belongs to any one of plaintext DNS query request, DoH request, DoT request and DoQ request; if yes, marking the traffic as DNS query traffic; if no, marking the traffic as non-DNS query traffic.
[0068] In some embodiments, the non-DNS query traffic processing module 140 performs domain name resolution on the traffic, including: detecting whether the traffic belongs to TCP traffic or UDP traffic; detecting whether the traffic belongs to HTTPS traffic or HTTP traffic when the traffic belongs to TCP traffic; obtaining a client hello message related to the traffic and extracting domain name information from the client hello message when the traffic belongs to HTTPS traffic; extracting Host field information from the HTTP request header and extracting domain name information from the Host field information when the traffic belongs to HTTP traffic; obtaining a QUIC initial packet related to the traffic and decrypting the QUIC initial packet using a public key when the traffic belongs to UDP traffic, and extracting domain name information from the SNI field in the decrypted QUIC initial packet; determining that the domain name resolution is successful when the domain name information is extracted from the traffic, and determining that the domain name resolution fails when the domain name information is not extracted from the traffic.
[0069] In some embodiments, the non-DNS query traffic processing module 140 performs a domain name shunting operation according to the resolved domain name information, including: detecting whether there is a forwarding record in the local domain name forwarding rule that matches the resolved domain name information; if there is, determining a target shunting server according to the forwarding record that matches the resolved domain name information, and forwarding the traffic to the target shunting server; if there is not, sending the traffic to the public network.
[0070] In some embodiments, the apparatus further includes a forwarding rule pulling module. The forwarding rule pulling module is configured to pull the country's domain name forwarding rule from the rule server at a regular time, and store the pulled domain name forwarding rule locally; the rule server stores a plurality of country's domain name forwarding rules defined by the user in advance.
[0071] In some embodiments, the apparatus further includes a mapping relationship updating module. The mapping relationship updating module is configured to extract domain name information from the domain name forwarding rule as a domain name to be shunted at a regular time, query the IP address corresponding to the domain name to be shunted from the DNS query server, and update the local IP domain name mapping table according to the domain name to be shunted and the IP address corresponding thereto.
[0072] In some embodiments, the mapping relationship updating module is further configured to send the local IP domain name mapping table to the country's center server; the country's center server is configured to collect the local IP domain name mapping tables sent by each VPN server in the country, and send the collected IP domain name mapping table to each VPN server in the country; and when receiving the collected IP domain name mapping table returned by the country's center server, update the local IP domain name mapping table according to the collected IP domain name mapping table.
[0073] For specific limitations of the dynamic configuration VPN server multi-domain name shunting apparatus, refer to the limitations of the dynamic configuration VPN server multi-domain name shunting method described above, which will not be repeated here. Each module in the above dynamic configuration VPN server multi-domain name shunting apparatus can be realized by software, hardware, and combinations thereof, in whole or in part. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to be called and executed by the processor to perform the operations corresponding to each module.
[0074] The present application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor can implement the steps of the dynamic configuration VPN server multi-domain name shunting method provided in any of the above embodiments when executing the computer program.
[0075] In some embodiments, the internal structure diagram of the computer device can be as shown in Figure 3As shown in the figure. The computer device includes a processor, a memory and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The database of the computer device is used to store data such as local IP domain name mapping table. The specific stored data can also refer to the definition in the above method embodiments. The network interface of the computer device is used to communicate with the external terminal through the network connection. The computer program is executed by the processor to implement a kind of dynamically configured VPN server multi-domain name split-flow method.
[0076] Those skilled in the art can understand that, Figure 3 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or less components than those shown in the figure, or combine certain components, or have a different component arrangement.
[0077] The present application also provides a computer readable storage medium, in some embodiments, the computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the dynamically configured VPN server multi-domain name split-flow method provided in any of the above embodiments.
[0078] In the above embodiments of the present application, the description of each embodiment has its own focus. The parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.
[0079] Those skilled in the art can understand that all or part of the processes in the above-mentioned method embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the method can be included. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink), DRAM (SLDRAM), memory bus (Rambus), direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0080] The technical features of the above embodiments can be combined in any way. In order to make the description simple, not all possible combinations of the technical features in the above embodiments are described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the present application.
[0081] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of the patent protection of the present application should be subject to the appended claims.
Claims
1. A dynamic configuration VPN server multi-domain name offloading method, characterized in that, The method is applied to a VPN server; the method comprises: receiving traffic from a VPN client, the VPN client setting the VPN server as a DNS server when establishing a VPN connection with the VPN server; identifying whether the traffic belongs to DNS query traffic or non-DNS query traffic; when the traffic belongs to DNS query traffic, forwarding the traffic to a local DNS query server, extracting IP address and domain name information from DNS response information returned by the DNS query server, and updating the IP domain name mapping table locally; when the traffic belongs to non-DNS query traffic, performing domain name resolution on the traffic; when the domain name resolution is successful, performing domain name shunting operation according to the domain name information obtained by the resolution, updating the target IP address of the traffic and the domain name information obtained by the resolution to the local IP domain name mapping table; when the domain name resolution fails, querying the local IP domain name mapping table according to the target IP address of the traffic, and performing domain name shunting operation according to the domain name information obtained by the query.
2. The method of claim 1, wherein, The identification of whether the traffic belongs to DNS query traffic or non-DNS query traffic comprises: detecting whether the traffic belongs to any one of plaintext DNS query request, DoH request, DoT request and DoQ request; if yes, marking the traffic as DNS query traffic; if no, marking the traffic as non-DNS query traffic.
3. The method of claim 1, wherein, The domain name resolution on the traffic comprises: detecting whether the traffic belongs to TCP traffic or UDP traffic; when the traffic belongs to TCP traffic, detecting whether the traffic belongs to HTTPS traffic or HTTP traffic; when the traffic belongs to HTTPS traffic, obtaining the client hello message related to the traffic, and extracting domain name information from the client hello message; when the traffic belongs to HTTP traffic, extracting Host field information from the HTTP request header, and extracting domain name information from the Host field information; when the traffic belongs to UDP traffic, obtaining the QUIC initial data packet related to the traffic, decrypting the QUIC initial data packet using a public key, and extracting domain name information from the SNI field in the decrypted QUIC initial data packet; when the domain name information is extracted from the traffic, it is determined that the domain name resolution is successful; when the domain name information is not extracted from the traffic, it is determined that the domain name resolution fails.
4. The method of claim 1, wherein, The domain name shunting operation according to the domain name information obtained by the resolution comprises: detecting whether there is a forwarding record matching the domain name information obtained by the resolution in the local domain name forwarding rule; if yes, determining a target shunting server according to the forwarding record matching the domain name information obtained by the resolution, and forwarding the traffic to the target shunting server; if no, sending the traffic to the public network.
5. The method of claim 4, wherein, The method further comprises: pulling the domain name forwarding rule of the country from a rule server at a regular time, and storing the pulled domain name forwarding rule locally; the rule server stores a plurality of country domain name forwarding rules defined by a user in advance.
6. The method of claim 4, wherein, The method further comprises: timing extracting domain name information from the domain name forwarding rule as a domain name to be shunted; querying an IP address corresponding to the domain name to be shunted from the DNS query server; updating the local IP domain name mapping table according to the domain name to be shunted and the IP address corresponding thereto.
7. The method of claim 1, wherein, The method further comprises: sending the local IP domain name mapping table to a home center server; the home center server is configured to collect local IP domain name mapping tables sent by each VPN server in the home country, and send the collected IP domain name mapping table to each VPN server in the home country; updating the local IP domain name mapping table according to the collected IP domain name mapping table returned by the home center server when the collected IP domain name mapping table is received.
8. A dynamic configured VPN server multi-domain name offloading apparatus, characterized in that, The device is applied to a VPN server; the device comprises: a traffic receiving module configured to receive traffic from a VPN client, the VPN client setting the VPN server as a DNS server when establishing a VPN connection with the VPN server; a traffic type identifying module configured to identify whether the traffic belongs to DNS query traffic or non-DNS query traffic; a DNS query traffic processing module configured to, when the traffic belongs to DNS query traffic, forward the traffic to a local DNS query server, and extract IP address and domain name information from DNS response information returned by the DNS query server and update the local IP domain name mapping table when the DNS response information is obtained; a non-DNS query traffic processing module configured to, when the traffic belongs to non-DNS query traffic, perform domain name resolution on the traffic, and perform domain name shunting operation according to domain name information obtained by the resolution and update the local IP domain name mapping table with a target IP address of the traffic and the domain name information obtained by the resolution when the domain name resolution succeeds, and query the local IP domain name mapping table according to the target IP address of the traffic and perform domain name shunting operation according to domain name information found when the domain name resolution fails.
9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 7.
10. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 7.
Citation Information
Patent Citations
Method and device for proxying DNS by VPN server side
CN107911496A
VPN request processing method, client device and system
CN112887444A