Kubernetes-based dynamically extensible intranet penetration method and service system

Abstract

The invention discloses a Kubernetes-based intranet penetration method and a Kubernetes-based intranet penetration service system, which are based on an FTP (File Transfer Protocol) technology, are expanded by adopting a Kubernetes pod cross-host multi-copy technology, and realize correct diversion when a user accesses intranet equipment through a public network through information caching and utilization when a communication tunnel of the intranet equipment is established. The method and the system effectively solve the technical problems of difficulty in horizontal expansion of single deployment at present, mutual network isolation between pod copies when Kubernetes pod deployment supports horizontal and horizontal expansion, and difficulty in diversion of user access flow.

Description

Technical Field

[0001] The present invention relates to the technical field of computer network security, and in particular to a dynamically scalable intranet penetration method based on Kubernetes. Background Art

[0002] Intranet penetration is a technology that maps network services in the intranet to public network servers, allowing public network clients to directly access network services in the intranet. Under normal circumstances, computers and network devices in the intranet can only communicate with each other in the intranet. Computers in the external network cannot directly access computers and network devices in the intranet. Intranet penetration technology can break through this obstacle, making the data flow between the intranet and the external network smoother and more convenient.

[0003] FRP (Fast Reverse Proxy) is a high-performance reverse proxy application that focuses on intranet penetration. It supports multiple protocols such as TCP, UDP, HTTP, HTTPS, etc. It can expose intranet services to the public network in a safe and convenient way through a transit with a public IP node. Simple network topology logic: After the public network server deploys the FRP server (FRPS for short), the terminal device uses the FRP client (FRPC for short) to establish a communication connection (communication tunnel) with FRPS through configuration. At this time, FRPS will allocate a temporary local diversion port (remote_port for short) for each FRPC agent, supporting multiple agents for one FRPC. The traffic accessing this port will be forwarded to the corresponding port of the intranet service of the device terminal through this communication tunnel; that is, the above method can realize the technology that the public network client can directly access the network service in the intranet.

[0004] At present, FRPS mainly adopts host binary deployment, docker deployment, and kubernetes pod deployment. Regardless of the deployment method, the number of remote_ports that a FRPS process can listen to is limited (port range 1024-65535), and there are performance issues for a large number of FRPCs to access a FRPS process. Usually, the first thing to think of is to support it through horizontal expansion. Binary and docker deployments have conflicts with the external service port of FRPS bind. Therefore, using binary and docker methods to deploy multiple FRPS will use multiple ports to expose. Multiple ports will complicate the network and make configuration difficult to manage. In the cluster deployment solution currently used by everyone, services are deployed on multiple public network hosts, and the configuration center needs to send the host address information of the connection to different devices. The data is relatively coupled, and it is difficult to support horizontal expansion and disposal expansion at the same time. In this regard, through the kubernetes pod deployment method, kubernetes service is used to expose only one port to the outside, and pod multiple copies are deployed. When computing resources and network resources are limited, you can plan to deploy to multiple cloud hosts. The cloud resource kubernetes cluster can be horizontally expanded by adding nodes. When a single pod resource overflows the rated limit, you can configure the pod resource for horizontal expansion. However, there will be a problem. Different FRPCs are load-distributed to different FRPS PODs. FRPpods are isolated from each other by the network. When accessing intranet device services, how to accurately proxy the user's access to the intranet device traffic to the corresponding communication tunnel is a problem. Summary of the invention

[0005] In order to overcome the deficiencies of the above-mentioned prior art, the present invention provides a dynamically scalable intranet penetration method and service system based on Kubernetes, which mainly solves the problem that the current single deployment is difficult to expand horizontally, as well as the technical problems of network isolation between pod copies and difficulty in diverting user access traffic when using Kubernetes pod deployment to support horizontal and horizontal expansion. It is decentralized in design on the server side, and multiple copies are deployed on different host nodes in a stateless pod manner. When the device traffic reaches the cloud service, Kubernetes loads it to the pod on the node according to the resource usage of each node.

[0006] The dynamically scalable intranet penetration method based on Kubernetes provided in the present disclosure includes the following steps:

[0007] S1, uses FRP intranet penetration technology to expose intranet device services to the public network;

[0008] S2 uses Kubernetes pod multi-replica deployment technology and deploys multiple replicas on different host nodes in a stateless pod manner. When device traffic reaches the cloud service, Kubernetes balances it to the pods on the node based on the resource usage of each node.

[0009] S3, when the intranet device uses frpc to establish a communication tunnel through the public network, the tunnel information of the device is recorded in the cache database, including the public network IP address of frpc's exit, the device ID, the remote_port of the communication tunnel agent, and the pod IP where the communication tunnel is established;

[0010] S4, when the user accesses the intranet device service, the communication tunnel information of the device cached in the cache database is obtained according to the id of the accessed device, and the traffic is directed according to the pod ip and remote_port in the cache information, so that the user can access the corresponding service of the intranet device.

[0011] Furthermore, in step S3, the step of the intranet device using frpc to establish a communication tunnel through the public network specifically includes:

[0012] When an intranet device uses FRPC to establish a communication tunnel through the public network, it first establishes a diversion with the local intranet service;

[0013] The load is then forwarded through the load balancing device to the tunnel port exposed by the Kubernetes cluster through NodePort;

[0014] Kubernetes service load balances the traffic to each FRPS pod within the cluster, and the plug-in program set in FRPS records the device communication tunnel information to the cache database. The communication tunnel information includes the frpc's egress public network IP address, device ID, tunnel status, communication tunnel proxy remote_port, and the pod IP where the communication tunnel is established;

[0015] At this point, the communication tunnel is established successfully.

[0016] Furthermore, the step S4 specifically includes:

[0017] When users access intranet device services through the public web, the access traffic is loaded by the load balancing device to the web port exposed by the Kubernetes cluster through NodePort;

[0018] Then the Kubernetes service load balances the traffic within the cluster to the traffic diversion module;

[0019] The traffic diversion module is responsible for diverting requests that have passed authentication to the FRPS pod, which is then proxied by the remote_port port monitored by the FRPS pod to the intranet device FRPC, and finally proxied by the FRPS pod to the service inside the device;

[0020] The flow diversion method of the flow diversion module specifically comprises the following steps:

[0021] Determine whether the received user traffic is valid;

[0022] Authentication judgment processing;

[0023] If authentication is successful, then:

[0024] Use the device ID corresponding to the accessed device to obtain the cache information of the device from the cache database; determine whether the device is online, if not, directly return an exception to the user to end the process;

[0025] If online, compare the pod ip in the cache information with the pod ip of the current container:

[0026] Determine whether the pod IP is consistent. If not, it proves that the device tunnel connection accessed by the user at that time exists in other pods. The pod IP in the cached data is used as the destination address to directly divert the current traffic.

[0027] If the pod IP is consistent, it means that there is a device tunnel connection accessed by the user in the current pod. The remote_port in the cache information is the destination port to be diverted. The access traffic proxy of the intranet service is completed by diverting the traffic to the local remote_port. At this time, the user can access the service corresponding to the intranet device.

[0028] Furthermore, the method further comprises the following steps:

[0029] Device and user binding: An internal user management system is set up to bind users to devices. As a result, when users access intranet device services through the public web, illegal devices can be filtered out while authenticating the user.

[0030] Furthermore, the remote_port includes multiple types to distinguish different intranet device services.

[0031] Furthermore, the method further comprises the following steps:

[0032] Set the dynamic pod expansion and contraction configuration in the FRPS pod deployment file. When forwarding the incoming FRPC traffic load, the Kubernetes service will give priority to forwarding new traffic requests to the newly created FRPS pod replica.

[0033] A dynamically scalable intranet penetration service system based on Kubernetes using the above method mainly includes:

[0034] The FRP architecture unit is used to expose the intranet device services to the public network; it includes: client frpc and server frps; the server frps is provided with a plug-in module, which is used to record the tunnel information of the device to the cache database when the intranet device uses frpc to establish a communication tunnel through the public network;

[0035] Kubernetes cluster, used for multi-copy generation and distributed deployment scheduling, including: load balancing module and Kubernetes service server, where:

[0036] The load balancing module is used to balance the access traffic to the web port exposed by the Kubernetes cluster through NodePort, and to load balance the traffic within the cluster to the diversion module;

[0037] The Kubernetes service server includes several FRPS pod nodes, each of which is equipped with a traffic diversion module, which is used to divert the intranet device service access traffic initiated by users through the public network web. The diversion method includes: according to the id of the access device, obtaining the communication tunnel information of the device cached in the cache database, and diverting according to the pod ip and remote_port in the cache information.

[0038] Furthermore, the diversion method of the diversion module specifically includes:

[0039] Determine whether the received user traffic is valid;

[0040] Authentication judgment processing;

[0041] If authentication is successful, then:

[0042] Use the device ID corresponding to the accessed device to obtain the cache information of the device from the cache database; determine whether the device is online, if not, directly return an exception to the user to end the process;

[0043] If online, compare the pod ip in the cache information with the pod ip of the current container:

[0044] Determine whether the pod IP is consistent. If not, it proves that the device tunnel connection accessed by the user at that time exists in other pods. The pod IP in the cached data is used as the destination address to directly divert the current traffic.

[0045] If the pod IP is consistent, it means that there is a device tunnel connection accessed by the user in the current pod. The remote_port in the cache information is the destination port to be diverted. The access traffic proxy of the intranet service is completed by diverting the traffic to the local remote_port. At this time, the user can access the service corresponding to the intranet device.

[0046] Compared with the prior art, the beneficial effects of the present invention are:

[0047] (1) It solves the current problem of single deployment and difficulty in horizontal expansion: When managing a large number of devices, this solution only needs to expose an IP+port to the outside through the Kubernetes Service Nodeport. The device uses this entry to establish a return encrypted tunnel. As the number of devices increases, when bandwidth resources, memory resources, and computing resources are insufficient, it is only necessary to horizontally expand the Kubernetes node and increase the number of FRPS Pods to easily achieve the purpose of capacity expansion. No other configuration is required in this process, nor is it necessary to open multiple IPs and ports at the entry point, thereby reducing security risk points;

[0048] (2) Solved the technical problem of network isolation between pod copies and difficulty in diverting user access traffic when using Kubernetes pod deployment to support horizontal and horizontal expansion: When multiple copies are deployed, the encrypted channel established by the device FRPC and FRPS will be loaded into different FRPS Pods. When users access device services on the public network, they usually do not know how to find the return channel of the corresponding device for diversion. The FRPS plug-in in this application solves this problem. When the channel is established, the plug-in will record the device information in the cache database. When the user accesses it, the proxy's openrestry lua script will first determine whether the device actually exists, and then accurately divert it to the device channel in the specific pod. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, wherein like reference numerals generally represent like components throughout the exemplary embodiments of the present disclosure.

[0050] Figure 1 This is the principle architecture diagram of FRP intranet penetration;

[0051] Figure 2 Deployment architecture diagram for Kubernetes FRP Pod multi-replica mode;

[0052] Figure 3 A logical flow chart is designed for Openresty lua diversion according to the present disclosure. DETAILED DESCRIPTION

[0053] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0054] The present disclosure proposes a dynamically scalable intranet penetration method and service system based on Kubernetes. In an exemplary implementation, the system mainly adopts Kubernetes pod cross-host multi-copy technology, FRP tunnel penetration technology, and openresty diversion technology (referred to as proxy) to achieve the purpose of FRPS being able to dynamically expand horizontally, access internal and external devices, and correctly divert the traffic that accesses the intranet device service through the public network management.

[0055] 1. FRP intranet penetration technology

[0056] The purpose is to expose the services of intranet devices to the public network. Figure 1 As shown in the figure, the principle of intranet penetration of FRP is mainly to establish a long connection on the server with a public IP, and then forward the data of the intranet service through this long connection.

[0057] FRP mainly consists of the client frpc and the server frps: the client frpc (101) runs on a machine with an intranet IP, it is responsible for listening to the intranet port and forwarding requests to the public network server frps (103);

[0058] The server frps runs on a machine with a public IP. It is responsible for receiving requests from clients and forwarding them to the corresponding intranet service.

[0059] The focus is on the frps(103) plugin, which has the following functions: when frpc(101) requests to successfully create / disconnect a communication tunnel, it records the tunnel information for the device into the cache database, including the frpc's public network IP address, device ID, tunnel status, communication tunnel proxy remote_port, and the pod IP where the communication tunnel is established.

[0060] 2. Kubernetes pod multi-copy deployment technology

[0061] The purpose is to support dynamic horizontal expansion and distributed deployment scheduling. Figure 2 As shown:

[0062] When a large number of intranet devices (201) use FRPC to establish a communication tunnel through the public network, a diversion with a local intranet service (202) is first established;

[0063] Then the load is forwarded through the load balancer SLB (203) to the tunnel port (204) exposed by the Kubernetes cluster through NodePort;

[0064] The Kubernetes service (205) load balances the traffic within the cluster to each FRPS pod (206), and the FRPS plug-in records the device communication tunnel information to the cache database (208); at this point, the communication tunnel is successfully established;

[0065] At this point, the user (209) can access the public network through the web page. Similarly, the access traffic is loaded by the load balancer SLB (203) to the web port (210) exposed by the Kubernetes cluster through the NodePort, and then the Kubernetesservice (205) load balances the traffic within the cluster to step (207);

[0066] Step (207) is responsible for directing traffic, directing the authenticated request to FRPS pod (206), which is then proxied by the remote_port port monitored by FRPS pod (206) to the intranet device FRPC (201), and finally proxied by FRPS pod (206) to the service (202) inside the device. The above describes the entire process of establishing an intranet penetration tunnel from the device to the cloud, and the process of users accessing intranet services through the public web.

[0067] In the FRPS pod (206) deployment file, set the dynamic expansion and contraction configuration of the pod. When an FRPS pod has more and more FRPC tunnel connections, and the POD memory and CPU reach the pre-configured limits, Kubernetes will automatically create a new FRPS pod replica. Later, when the Kubernetes service forwards the incoming FRPC traffic load, it will give priority to forwarding new traffic requests to the newly created FRPS pod replica.

[0068] 3. Openresty diversion technology

[0069] The purpose is to authenticate users when they access intranet device services, and coordinate with Kubernetes pod distributed multi-copy deployment to direct traffic to the corresponding device proxy tunnel. The proxy container and FRPS container are set in the same pod.

[0070] The principle is as follows Figure 3As shown: When a user accesses the intranet device service through the public web,

[0071] Step 301, determining whether the received user traffic is valid;

[0072] Step 302: Authentication judgment processing. If the authentication is passed, then:

[0073] Step 304, get the device ID corresponding to the accessed device (when the device is connected through the FRPC tool, it is necessary to fill in the information in the configuration file, which will bring the device's own unique serial number - a unique identity is created when the device is produced. FRPS will obtain the device ID data in the interactive information and store it for subsequent diversion) to obtain the cache information of the device in the cache database;

[0074] Step 305 determines whether the device is online. If it is not online, an exception is directly returned to the user to end the process. If it is online, the pod IP in the cache information is compared with the pod IP of the current container through step 306.

[0075] Step 307, determine whether the pod IP is consistent. If not, it proves that the device tunnel connection accessed by the user at that time exists in other pods. Step 308 uses the pod IP in the cache data as the destination address to directly divert the current traffic;

[0076] If the pod IP is consistent, it means that there is a device tunnel connection accessed by the user in the current pod, and the remote_port in the cache information is the destination port to be diverted (preferably, multiple types of remote_port can be set to distinguish different intranet device services), and then step 309 diverts the traffic to the local remote_port to complete the access traffic proxy for the intranet service. At this time, the user can access the service corresponding to the intranet device.

[0077] The above technical scheme is only an exemplary embodiment of the present invention. For those skilled in the art, it is easy to make various types of improvements or modifications based on the application methods and principles disclosed in the present invention, and it is not limited to the method described in the above specific embodiment of the present invention. Therefore, the method described above is only preferred and does not have a restrictive meaning.

Claims

1. A dynamically scalable intranet penetration method based on Kubernetes, comprising the following steps: S1, uses FRP intranet penetration technology to expose intranet device services to the public network; S2 uses Kubernetes pod multi-replica deployment technology and deploys multiple replicas on different host nodes in a stateless pod manner. When device traffic reaches the cloud service, Kubernetes balances the load to the pods on the nodes. S3, when the intranet device uses frpc to establish a communication tunnel through the public network, the tunnel information of the device is recorded in the cache database, including the public network IP address of frpc's exit, the device ID, the remote_port of the communication tunnel agent, and the pod IP where the communication tunnel is established; S4, when the user accesses the intranet device service, the communication tunnel information of the device cached in the cache database is obtained according to the id of the accessed device, and the traffic is directed according to the pod ip and remote_port in the cache information, so that the user can access the corresponding service of the intranet device.

2. The method according to claim 1, characterized in that In step S3, the steps of the intranet device using frpc to establish a communication tunnel through the public network specifically include: When an intranet device uses FRPC to establish a communication tunnel through the public network, it first establishes a diversion with the local intranet service; The load is then forwarded through the load balancing device to the tunnel port exposed by the Kubernetes cluster through NodePort; Kubernetes service load balances the traffic to each FRPS pod within the cluster, and the plug-in program set in FRPS records the device communication tunnel information to the cache database. The communication tunnel information includes the frpc's egress public network IP address, device ID, tunnel status, communication tunnel proxy remote_port, and the pod IP where the communication tunnel is established; At this point, the communication tunnel is established successfully.

3. The method according to claim 1, characterized in that The step S4 specifically includes: When users access intranet device services through the public web, the access traffic is loaded by the load balancing device to the web port exposed by the Kubernetes cluster through NodePort; Then the Kubernetes service load balances the traffic within the cluster to the traffic diversion module; The traffic diversion module is responsible for diverting requests that have passed authentication to the FRPS pod, which is then proxied by the remote_port port monitored by the FRPS pod to the intranet device FRPC, and finally proxied by the FRPS pod to the service inside the device; The flow diversion method of the flow diversion module specifically comprises the following steps: Determine whether the received user traffic is valid; Authentication judgment processing; If authentication is successful, then: Use the device ID corresponding to the accessed device to obtain the cache information of the device from the cache database; Determine whether the device is online. If it is not online, an exception is directly returned to the user to end the process; If online, compare the podip in the cache information with the podip of the current container: Determine whether the podip is consistent. If not, it proves that the device tunnel connection accessed by the user at that time exists in other pods. The pod ip in the cached data is used as the destination address to directly divert the current traffic. If the podip is consistent, it means that there is a device tunnel connection accessed by the user in the current pod. The remote_port in the cache information is the destination port to be diverted. The access traffic proxy of the intranet service is completed by diverting the traffic to the local remote_port. At this time, the user can access the service corresponding to the intranet device.

4. The method according to claim 3, characterized in that The method further comprises the following steps: Device and user binding: An internal user management system is set up to bind users to devices. When users access intranet device services through the public web, illegal devices are filtered out while authenticating users.

5. The method according to claim 1, characterized in that The remote_port port includes multiple types to distinguish different intranet device services.

6. The method according to any one of claims 1 to 5, characterized in that: The following steps are also included: Set the dynamic pod expansion and contraction configuration in the FRPS pod deployment file. When forwarding the incoming FRPC traffic load, the Kubernetes service will give priority to forwarding new traffic requests to the newly created FRPS pod replica.

7. A dynamically scalable intranet penetration service system based on Kubernetes using any of the methods described in claims 1-6, characterized in that: include: The FRP architecture unit is used to expose the intranet device services to the public network; it includes: client frpc and server frps; the server frps is provided with a plug-in module, which is used to record the tunnel information of the device to the cache database when the intranet device uses frpc to establish a communication tunnel through the public network; Kubernetes cluster, used for multi-copy generation and distributed deployment scheduling, including: load balancing module and Kubernetes service server, where: The load balancing module is used to balance the access traffic to the web port exposed by the Kubernetes cluster through NodePort, and to load balance the traffic within the cluster to the diversion module; The Kubernetes service server includes several FRPS pod nodes, each of which is equipped with a traffic diversion module, which is used to divert the intranet device service access traffic initiated by users through the public network web. The diversion method includes: according to the id of the access device, obtaining the communication tunnel information of the device cached in the cache database, and diverting according to the pod ip and remote_port in the cache information.

8. The device according to claim 7, characterized in that The flow diversion method of the flow diversion module specifically includes: Determine whether the received user traffic is valid; Authentication judgment processing; If authentication is successful, then: Use the device ID corresponding to the accessed device to obtain the cache information of the device from the cache database; Determine whether the device is online. If it is not online, an exception is directly returned to the user to end the process; If online, compare the podip in the cache information with the podip of the current container: Determine whether the pod IP is consistent. If not, it proves that the device tunnel connection accessed by the user at that time exists in other pods. The pod IP in the cached data is used as the destination address to directly divert the current traffic. If the podip is consistent, it means that there is a device tunnel connection accessed by the user in the current pod. The remote_port in the cache information is the destination port to be diverted. The access traffic proxy of the intranet service is completed by diverting the traffic to the local remote_port. At this time, the user can access the service corresponding to the intranet device.

Images