IP layer-oriented SSL VPN tunnel transmission method

Abstract

The application discloses an SSL VPN tunnel transmission method for an IP layer, and relates to the technical field of network communication.The method constructs an IP virtual tunnel outside an SSL session, and directly encapsulates and transmits complete IP messages, thereby completely breaking through the limitation that a traditional SSL VPN only supports a Web proxy, and transparently passing through the tunnel for TCP services, UDP streaming media, ICMP network diagnostic messages, and the like, so that the method realizes remote access of the IP layer in a true sense, and a server adopts a south-north decoupling design, a virtual network port is used as a southward interface to communicate with a client tunnel, and the northward directly interacts with an intranet physical network card through a system routing table, without analyzing transport layer content, without maintaining a TCP connection state, and only performing IP layer transparent forwarding, so that the processing cost is greatly reduced, and the throughput performance is obviously improved.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, specifically to an SSL VPN tunneling method for the IP layer. Background Technology

[0002] SSL VPN, a remote access technology based on the SSL / TLS protocol, shares the same origin as HTTPS encryption technology for websites. It establishes a secure communication channel through encryption and authentication, aiming to solve the flexibility and ease-of-use issues of traditional IPSec VPNs in remote access. From a technological evolution perspective, first-generation VPNs operate at the network layer, requiring dedicated client software, resulting in complex deployment and NAT traversal problems. Second-generation VPNs operate at the application layer, enabling clientless access through a browser, supporting dynamic content rewriting and port forwarding, and better adapting to mobile office needs. Third-generation VPNs further optimize performance bottlenecks, improving throughput and reducing latency. However, existing SSL VPN technology still has obvious shortcomings: its core mechanism only supports application layer protocols and cannot handle non-application layer protocol packets such as UDP and ICMP. Specifically, traditional SSL VPNs achieve resource access through web proxies or port forwarding. For TCP packets that meet the policy, the TCP payload data is usually encapsulated into SSL record layer data, which is then decrypted by the server and the connection is reconstructed before being forwarded to the target server. This design makes it impossible for important IP layer-based applications such as UDP streaming media, VoIP, DNS queries, and ICMP network diagnostics to be transmitted through SSL VPN tunnels, which seriously limits the applicable scenarios of SSL VPN. Therefore, while retaining the ease of use and security of SSL VPN, breaking through its limitation of only supporting application layer protocols and achieving transparent support for all IP layer protocols such as TCP, UDP, and ICMP is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0003] The purpose of this invention is to provide an IP-layer-oriented SSL VPN tunneling method to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: an SSL VPN tunneling method for the IP layer, comprising the following steps: S1. Create virtual network interfaces on the SSL server and SSL client respectively, as the entry and exit points for IP layer data; S2. Build a virtual tunnel on the basis of the SSL connection and bind the virtual network port to the SSL session; S3. After the tunnel is established, in the uplink direction, the client IP packets enter the virtual network card through the router. The SSL client encrypts them and sends them to the server. After the server decrypts them, they are directly injected into the protocol stack through the virtual network port and forwarded from the physical network card to the internal network server according to the routing table. The downlink direction is the opposite, realizing bidirectional IP layer secure communication. S4 transmits complete IP packets, transparently supports TCP, UDP, and ICMP protocols, and configures back-pointing routing and traffic splitting strategies. It ensures tunnel stability through keep-alive, disconnection reconnection, and multi-session isolation.

[0005] Preferably, step S1 specifically includes the following steps: When the S101 SSL client starts, it creates a virtual network interface card in the operating system, assigns a virtual IP address, and configures a routing policy to direct traffic destined for a specified intranet segment to the virtual network interface card. S102. The SSL server creates a virtual network interface card and assigns a virtual IP address, which serves as the tunnel endpoint for communication with the client. S103, the server's virtual network port serves as the southbound interface for tunnel communication with the client, while the northbound interface directly interacts with the internal physical network card through the routing table. This interface performs IP layer data forwarding.

[0006] Preferably, step S2 specifically includes the following steps: S201. The client and server complete a standard SSL handshake and establish an SSL encrypted session through certificate verification. Within the established SSL encrypted session, the two parties exchange key configuration parameters of the virtual network interface through custom control messages, including the virtual IP address, subnet mask, MTU value, and DNS server information. S202. Control messages reside in the SSL application data layer. With the help of SSL encryption protection, the client and server dynamically synchronize network parameters. S203. The server associates the current SSL session with the corresponding virtual network interface to form a virtual tunnel, and the client binds the SSL session with the local virtual network card to complete the tunnel binding.

[0007] Preferably, step S3 specifically includes the following steps: S301. After tunnel binding, IP packets are bidirectionally converted between the virtual network interface and the SSL tunnel. In the uplink direction, i.e. from the client to the internal network, when the client application generates an IP packet, the packet is sent to the virtual network card according to the routing rules. S302: After capturing IP packets, the SSL client encapsulates them into SSL record layer data and sends them to the server through the established SSL encrypted tunnel. After receiving the encrypted data, the S303 and SSL servers decrypt it from the SSL record layer, restore the original IP packet, and verify whether the packet conforms to the policy. If it does not conform, it is discarded; otherwise, the IP packet is injected into the operating system's protocol stack through the virtual network interface. According to the local routing table, the packet is forwarded from the physical network card to the target server on the internal network, completing the uplink forwarding.

[0008] Preferably, step S3 further includes the following steps: S304. In the downlink direction, i.e. from the intranet to the client, the response message returned by the intranet server has the client's virtual IP address as its destination IP. After the message reaches the server's physical network card, the routing table will direct traffic whose destination address belongs to the virtual IP pool to the server's virtual network interface. After the S305 SSL server captures this IP packet, it encrypts it with SSL through the virtual tunnel associated with the client and sends it back to the client. S306 After receiving the encrypted data, the client decrypts it, restores the original IP packet, and writes it to the local virtual network card. The client's operating system's protocol stack then delivers the packet to the corresponding application.

[0009] Preferably, step S4 specifically includes the following steps: S401. Since the transmitted data is a complete IP packet, for the TCP protocol, the server only forwards the IP packet and does not maintain the TCP state. For the UDP protocol, the IP packet is directly encapsulated so that the application can communicate normally. For the ICMP protocol, the packet is also encapsulated and forwarded. S402. Configure the back-pointing route on the server side. On the core switch of the internal network, the traffic that is meant to the virtual IP pool is directed to the physical network card address of the SSL server to ensure that the downlink data can reach the server correctly. S403: The client selects a traffic splitting strategy based on the scenario. In full tunnel mode, the client's default route is modified to direct all traffic to the virtual network card. In Split Tunneling mode, only routes for specific intranet segments are added, and other traffic goes through the local gateway.

[0010] Preferably, step S4 further includes the following steps: S404. Set up a keepalive mechanism. This mechanism maintains NAT traversal and long connection status through a custom keepalive message in the SSL layer, preventing intermediate devices from disconnecting due to timeout. The disconnection reconnection and status recovery functions enable the client to automatically reconnect after disconnection, and rebind the virtual network interface and refresh the routing table after recovery. S405. Data isolation is achieved through IP addresses. When the server-side virtual network port is bound to multiple client sessions, IP packets between different users do not interfere with each other.

[0011] Compared with the prior art, the beneficial effects of the present invention are: This invention constructs an IP virtual tunnel outside the SSL session, directly encapsulating and transmitting complete IP packets. This completely breaks through the limitation of traditional SSL VPNs that only support web proxies. Whether it is TCP services, UDP streaming media, or ICMP network diagnostic messages, they can all transparently traverse the tunnel, realizing true IP-layer full-protocol remote access. At the same time, the server adopts a north-south decoupling design. The virtual network port serves as the southbound interface for communication with the client tunnel, while the northbound interface directly interacts with the internal physical network card through the system routing table. It does not parse transport layer content, does not maintain TCP connection state, and only performs transparent IP-layer forwarding, which greatly reduces processing overhead and significantly improves throughput performance. Attached Figure Description

[0012] Figure 1 An overall method flowchart is provided for embodiments of the present invention; Figure 2 A typical application topology diagram is provided for embodiments of the present invention. Detailed Implementation

[0013] 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.

[0014] Example 1: Please see Figure 1 - Figure 2 This invention provides a technical solution: an IP-layer-oriented SSL VPN tunnel transmission method, comprising the following steps: S1. Create virtual network interfaces on the SSL server and SSL client respectively, as the entry and exit points for IP layer data; S2. Build a virtual tunnel on the basis of the SSL connection and bind the virtual network port to the SSL session; S3. After the tunnel is established, in the uplink direction, the client IP packets enter the virtual network card through the router. The SSL client encrypts them and sends them to the server. After the server decrypts them, they are directly injected into the protocol stack through the virtual network port and forwarded from the physical network card to the internal network server according to the routing table. The downlink direction is the opposite, realizing bidirectional IP layer secure communication. S4 transmits complete IP packets, transparently supports TCP, UDP, and ICMP protocols, and configures back-pointing routing and traffic splitting strategies. It ensures tunnel stability through keep-alive, disconnection reconnection, and multi-session isolation.

[0015] S1 specifically includes the following steps: When the S101 SSL client starts, it creates a virtual network interface card in the operating system, assigns a virtual IP address, and configures a routing policy to direct traffic destined for a specified intranet segment to the virtual network interface card. S102. The SSL server creates a virtual network interface card and assigns a virtual IP address, which serves as the tunnel endpoint for communication with the client. S103, the server virtual network port serves as the southbound interface for tunnel communication with the client, while the northbound interface directly interacts with the internal physical network card through the routing table. This interface performs IP layer data forwarding. S2 specifically includes the following steps: S201. The client and server complete a standard SSL handshake and establish an SSL encrypted session through certificate verification. Within the established SSL encrypted session, the two parties exchange key configuration parameters of the virtual network interface through custom control messages, including the virtual IP address, subnet mask, MTU value, and DNS server information. S202. Control messages reside in the SSL application data layer. With the help of SSL encryption protection, the client and server dynamically synchronize network parameters. S203. The server associates this SSL session with the corresponding virtual network interface to form a virtual tunnel, and the client binds the SSL session with the local virtual network card to complete the tunnel binding. S3 specifically includes the following steps: S301. After tunnel binding, IP packets are bidirectionally converted between the virtual network interface and the SSL tunnel. In the uplink direction, i.e. from the client to the internal network, when the client application generates an IP packet, the packet is sent to the virtual network card according to the routing rules. S302: After capturing IP packets, the SSL client encapsulates them into SSL record layer data and sends them to the server through the established SSL encrypted tunnel. After receiving the encrypted data, the S303 SSL server decrypts it from the SSL record layer, restores the original IP packet, and verifies whether the packet conforms to the policy. If it does not conform, it is discarded; otherwise, the IP packet is injected into the operating system's protocol stack through the virtual network interface. According to the local routing table, the packet is forwarded from the physical network card to the target server on the internal network, completing the uplink forwarding. S3 also includes the following steps: S304. In the downlink direction, i.e. from the intranet to the client, the response message returned by the intranet server has the client's virtual IP address as its destination IP. After the message reaches the server's physical network card, the routing table will direct traffic whose destination address belongs to the virtual IP pool to the server's virtual network interface. After the S305 SSL server captures this IP packet, it encrypts it with SSL through the virtual tunnel associated with the client and sends it back to the client. S306. After receiving the encrypted data, the client decrypts it, restores the original IP packet, and writes it to the local virtual network card. The client's operating system's protocol stack then delivers the packet to the corresponding application. S4 specifically includes the following steps: S401. Since the transmitted data is a complete IP packet, for the TCP protocol, the server only forwards the IP packet and does not maintain the TCP state. For the UDP protocol, the IP packet is directly encapsulated so that the application can communicate normally. For the ICMP protocol, the packet is also encapsulated and forwarded. S402. Configure the back-pointing route on the server side. On the core switch of the internal network, the traffic that is meant to the virtual IP pool is directed to the physical network card address of the SSL server to ensure that the downlink data can reach the server correctly. S403: The client selects a traffic splitting strategy based on the scenario. In full tunnel mode, the client's default route is modified to direct all traffic to the virtual network card. In Split Tunneling mode, only routes for specific intranet segments are added, and other traffic goes through the local gateway. S4 also includes the following steps: S404. Set up a keepalive mechanism. This mechanism maintains NAT traversal and long connection status through a custom keepalive message in the SSL layer, preventing intermediate devices from disconnecting due to timeout. The disconnection reconnection and status recovery functions enable the client to automatically reconnect after disconnection, and rebind the virtual network interface and refresh the routing table after recovery. S405. Data isolation is achieved through IP addresses. When the server-side virtual network port is bound to multiple client sessions, IP packets between different users do not interfere with each other.

[0016] Example 2: This invention supports the establishment of IP virtual channels and secure forwarding of IP layer data on virtual network ports outside SSL tunnels. Through the cooperation of SSL server and SSL client software, IP-level secure communication can be established on the terminal. In this scheme, the SSL server acts as a server in the southbound direction, but neither as a server nor a client in the northbound direction. It directly forwards IP layer data through virtual network ports and routers. Once the virtual tunnel is established, it supports IP layer data communication such as TCP, UDP, and ICMP, without being restricted by the server or client. The terminal can communicate directly with the northbound service address.

[0017] (1) IP packets such as UDP and ICMP For IP packets such as UDP and ICMP that conform to the policy, they are directly routed to the virtual network interface card (NIC). The SSL client receives data from the virtual NIC, encapsulates the IP packets into SSL record layer data, and sends them to the SSL server through the SSL tunnel. The SSL server decrypts the data from the SSL record layer, restores it to IP packets, and verifies whether it conforms to the policy. If it does not conform, it discards the packet; otherwise, it sends it to the server through the virtual network card.

[0018] (2) TCP message For TCP packets that conform to the policy, the TCP payload data and its context (IP header, TCP header) are encapsulated into SSL record layer data and sent to the SSL server through the SSL tunnel; The SSL server decrypts data from the SSL record layer and forwards the original data to the server.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0020] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for SSL VPN tunneling oriented towards the IP layer, characterized in that, The method includes the following steps: S1. Create virtual network interfaces on the SSL server and SSL client respectively, as the entry and exit points for IP layer data; S2. Build a virtual tunnel on the basis of the SSL connection and bind the virtual network port to the SSL session; S3. After the tunnel is established, in the uplink direction, the client IP packets enter the virtual network card through the router. The SSL client encrypts them and sends them to the server. After the server decrypts them, they are directly injected into the protocol stack through the virtual network port and forwarded from the physical network card to the internal network server according to the routing table. The downlink direction is the opposite, realizing bidirectional IP layer secure communication. S4 transmits complete IP packets, transparently supports TCP, UDP, and ICMP protocols, and configures back-pointing routing and traffic splitting strategies. It ensures tunnel stability through keep-alive, disconnection reconnection, and multi-session isolation.

2. The SSL VPN tunneling method for IP layer as described in claim 1, characterized in that, S1 specifically includes the following steps: When the S101 SSL client starts, it creates a virtual network interface card in the operating system, assigns a virtual IP address, and configures a routing policy to direct traffic destined for a specified intranet segment to the virtual network interface card. S102. The SSL server creates a virtual network interface card and assigns a virtual IP address, which serves as the tunnel endpoint for communication with the client. S103, the server's virtual network port serves as the southbound interface for tunnel communication with the client, while the northbound interface directly interacts with the internal physical network card through the routing table. This interface performs IP layer data forwarding.

3. The SSL VPN tunneling method for IP layer as described in claim 1, characterized in that, S2 specifically includes the following steps: S201. The client and server complete a standard SSL handshake and establish an SSL encrypted session through certificate verification. Within the established SSL encrypted session, the two parties exchange key configuration parameters of the virtual network interface through custom control messages. S202. Control messages reside in the SSL application data layer. With the help of SSL encryption protection, the client and server dynamically synchronize network parameters. S203. The server associates the current SSL session with the corresponding virtual network interface to form a virtual tunnel, and the client binds the SSL session with the local virtual network card to complete the tunnel binding.

4. The SSL VPN tunneling method for IP layer as described in claim 1, characterized in that, S3 specifically includes the following steps: S301. After tunnel binding, IP packets are bidirectionally converted between the virtual network interface and the SSL tunnel. In the uplink direction, when the client application generates an IP packet, the packet is sent to the virtual network card according to the routing rules. S302: After capturing IP packets, the SSL client encapsulates them into SSL record layer data and sends them to the server through the established SSL encrypted tunnel. After receiving the encrypted data, the S303 and SSL servers decrypt it from the SSL record layer, restore the original IP packet, and verify whether the packet conforms to the policy. If it does not conform, it is discarded; otherwise, the IP packet is injected into the operating system's protocol stack through the virtual network interface. According to the local routing table, the packet is forwarded from the physical network card to the target server on the internal network, completing the uplink forwarding.

5. The SSL VPN tunneling method for IP layer as described in claim 4, characterized in that, S3 specifically includes the following steps: S304. In the downlink direction, the response message returned by the internal network server has a destination IP of the client's virtual IP address. After the message arrives at the server's physical network card, the routing table will direct traffic whose destination address belongs to the virtual IP pool to the server's virtual network interface. After the S305 SSL server captures this IP packet, it encrypts it with SSL through the virtual tunnel associated with the client and sends it back to the client. S306 After receiving the encrypted data, the client decrypts it, restores the original IP packet, and writes it to the local virtual network card. The client's operating system's protocol stack then delivers the packet to the corresponding application.

6. The SSL VPN tunneling method for IP layer as described in claim 1, characterized in that, S4 specifically includes the following steps: S401. Since the transmitted data is a complete IP packet, for the TCP protocol, the server only forwards the IP packet and does not maintain the TCP state. For the UDP protocol, the IP packet is directly encapsulated so that the application can communicate normally. For the ICMP protocol, the packet is also encapsulated and forwarded. S402. Configure the back-pointing route on the server side. On the core switch of the internal network, the traffic that is meant to the virtual IP pool is directed to the physical network card address of the SSL server to ensure that the downlink data can reach the server correctly. S403: The client selects a traffic splitting strategy based on the scenario. In full tunnel mode, the client's default route is modified to direct all traffic to the virtual network card. In Split Tunneling mode, only routes for specific intranet segments are added, and other traffic goes through the local gateway.

7. The SSL VPN tunneling method for IP layer as described in claim 6, characterized in that, S4 specifically includes the following steps: S404. Set up a keepalive mechanism. This mechanism maintains NAT traversal and long connection status through a custom keepalive message in the SSL layer, preventing intermediate devices from disconnecting due to timeout. The disconnection reconnection and status recovery functions enable the client to automatically reconnect after disconnection, and rebind the virtual network interface and refresh the routing table after recovery. S405. Data isolation is achieved through IP addresses. When the server-side virtual network port is bound to multiple client sessions, IP packets between different users do not interfere with each other.

Images