Virtual-real fusion target range platform establishing method and device

Abstract

The invention is suitable for the technical field of network security, and provides a virtual-real fusion target range platform establishment method and device. A communication system is generated based on each virtual instance and a control node, a target range platform for network security testing is established based on the communication system, the control node in the communication system is in communication connection with each real physical node, and each virtual instance is in communication connection with the control node. The target range platform established by the application can be used for network security testing, so that the virtual instance in the communication system can communicate with the external real physical node, and the target range platform can test the communication flow between the virtual instance in the communication system and the external real physical node; the effectiveness of network security testing in each network security scene is improved, and the security and stability of each network security system are improved.

Description

Technical Field

[0001] The present application belongs to the field of network security technology, and in particular relates to a method and device for establishing a virtual-reality integrated shooting range platform. Background Art

[0002] Virtual-reality integration is similar to hardware-in-the-loop simulation, which involves integrating real physical nodes and components into the simulation system. In real-world simulation scenarios, there are engineering requirements for receiving physical information from external physical nodes and components. For example, in a power monitoring network, each substation receives network services provided by a server through a terminal. To simulate a similar network scenario using a network simulation test cloud and to visually assess the quality of terminal communication data flows in the simulation, currently only simulated data can be obtained through software such as NS-2 (Network Simulator Version 2), rather than directly obtaining actual communication data flow information.

[0003] To scale network simulation, a large number of virtual instances in the network simulation test cloud need to be connected to a real physical network. Existing technologies lack a technical solution for connecting real physical nodes with virtual instances in the network simulation test cloud, achieving virtual-reality integration. Consequently, there is also a lack of a technical solution for establishing a virtual-reality integrated training range platform. Summary of the Invention

[0004] The embodiments of the present application provide a method and device for establishing a virtual-reality integrated target range platform, which can solve the problem in the prior art of lacking a technical solution for how to communicate and connect real physical nodes with virtual instances in a network simulation test cloud and perform virtual-reality integration.

[0005] In a first aspect, an embodiment of the present application provides a method for establishing a virtual-reality integrated shooting range platform, comprising:

[0006] Generate a communication system based on each virtual instance and the control node, wherein the control node in the communication system is respectively communicatively connected to each real physical node, and each virtual instance is respectively communicatively connected to the control node;

[0007] A shooting range platform is established based on the communication system, and the shooting range platform is used for network security testing.

[0008] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node, including:

[0009] Each of the virtual instances is communicatively connected to the control node via a virtual router in the virtual subnet.

[0010] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node through a virtual router in the virtual subnet, including:

[0011] When data needs to be sent to a real physical node, the virtual instance sends the data to the virtual router in the virtual subnet based on the floating IP address;

[0012] The virtual router in the virtual subnet sends the data to the control node;

[0013] The control node sends the data to the real physical node.

[0014] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node, including:

[0015] Each of the virtual instances is communicatively connected to the control node via a mapping node.

[0016] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node through a mapping node, including:

[0017] When data needs to be sent to a real physical node, the virtual instance sends the data to the mapped node based on the floating IP address;

[0018] The mapping node sends the data to the virtual router inside the control node;

[0019] The virtual router inside the control node sends the data to the real physical node.

[0020] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node through a mapping node, including:

[0021] When data needs to be sent to a real physical node, the virtual instance sends the data to the encapsulation tunnel bridge according to the floating IP address, and the encapsulation tunnel bridge is connected to the summary bridge of the control node;

[0022] The mapping node sends the data received through the summary bridge to the virtual router inside the control node;

[0023] The virtual router inside the control node sends the data to the real physical node through an external bridge.

[0024] In a possible implementation of the first aspect, each virtual instance is communicatively connected to the control node, including:

[0025] The external network card of the control node receives data sent by the routing node, the first floating IP address of the data sent by the routing node corresponds to the first management network segment of the target virtual instance, wherein the routing node receives the data sent by the real physical node and forwards it to the external network card of the control node;

[0026] The virtual router inside the control node determines the first management network segment where the target virtual instance corresponding to the first floating IP address is located according to the mapping relationship between the floating IP address and the management network segment;

[0027] The control node sends the data to the target virtual instance corresponding to the data according to the first management network segment.

[0028] In a second aspect, an embodiment of the present application provides a device for establishing a virtual-real fusion shooting range platform, comprising:

[0029] A first generating module is configured to generate a communication system based on each virtual instance and a control node, wherein the control node in the communication system is communicatively connected to each real physical node, and each virtual instance is communicatively connected to the control node;

[0030] The second establishing module is used to establish a shooting range platform based on the communication system, and the shooting range platform is used for network security testing.

[0031] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the electronic device implements the method described in the first aspect above.

[0032] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in the first aspect above is implemented.

[0033] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed, enables the method described in the first aspect above to be executed.

[0034] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0035] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0036] The present application generates a communication system based on each virtual instance and a control node, and establishes a range platform for network security testing based on the communication system, wherein the control node in the communication system is respectively connected to each real physical node, and the each virtual instance is respectively connected to the control node. The present application generates a communication system based on each virtual instance and a control node, and respectively connects each virtual instance to the control node and connects the control node to each real physical node, so that each virtual instance can be connected to each real physical node, thereby integrating the virtual instance with the real physical node to generate a virtual-real fusion communication system. By generating a virtual-real fusion communication system, a range platform can be further established. The range platform can be used for network security testing, so that the virtual instances in the communication system can communicate with external real physical nodes, and then the range platform can test the communication traffic between the virtual instances in the communication system and the external real physical nodes, thereby improving the effectiveness of network security testing in various network security scenarios and improving the security and stability of various network security systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0038] Figure 1 This is a flow chart of a method for establishing a virtual-reality integrated shooting range platform provided in one embodiment of the present application;

[0039] Figure 2 Schematic diagram of a virtual-reality fusion shooting range platform provided in one embodiment of the present application;

[0040] Figure 3 is a schematic diagram of a communication system provided by an embodiment of the present application;

[0041] Figure 4 This is a schematic diagram of floating IP address conversion provided by an embodiment of the present application;

[0042] Figure 5 is a schematic diagram of a communication system provided by another embodiment of the present application;

[0043] Figure 6 is a schematic diagram of a communication system provided by yet another embodiment of the present application;

[0044] Figure 7 is a schematic diagram of a communication system provided by another embodiment of the present application;

[0045] Figure 8 is a schematic diagram of a communication system provided by yet another embodiment of the present application;

[0046] Figure 9 This is a schematic diagram of a container architecture provided by an embodiment of the present application;

[0047] Figure 10 This is a schematic diagram of virtual instances communicating via a summary bridge provided by an embodiment of the present application;

[0048] Figure 11 This is a schematic diagram of real physical nodes communicating through an external bridge provided by an embodiment of the present application;

[0049] Figure 12 is a structural diagram of a communication system provided by yet another embodiment of the present application;

[0050] Figure 13 It is a schematic diagram of a physical network card in a virtual router in the prior art;

[0051] Figure 14 This is a schematic diagram of a physical network card in a virtual router provided by an embodiment of the present application;

[0052] Figure 15 is a schematic diagram of a routing node provided in one embodiment of the present application;

[0053] Figure 16 is a schematic diagram of a routing node cluster provided in an embodiment of the present application;

[0054] Figure 17 Schematic diagram of the structure of the virtual-reality fusion shooting range platform establishment device provided in an embodiment of the present application;

[0055] Figure 18 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0057] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0058] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0059] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0060] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0061] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0062] The method for establishing a virtual-reality integrated shooting range platform provided in the embodiments of the present application can be applied to electronic devices such as network servers, network communication equipment, mobile phones, tablet computers, wearable devices, vehicle-mounted equipment, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs). The embodiments of the present application do not impose any restrictions on the specific types of electronic devices.

[0063] For example, the electronic device may be a station (STAION, ST) in a WLAN, a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA) device, a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, a vehicle-mounted device, a vehicle networking terminal, a computer, a laptop computer, a handheld communication device, a handheld computing device, a satellite wireless device, a wireless modem card, a TV set-top box (STB), customer premise equipment (CPE) and / or other devices for communicating on a wireless system and a next-generation communication system, such as a mobile terminal in a 5G network or a mobile terminal in a future evolved Public Land Mobile Network (PLMN) network.

[0064] In order to expand the scale of network simulation, it is necessary to connect a large number of virtual instances in the network simulation test cloud to the real physical network. The existing technology lacks a technical solution for how to communicate and connect real physical nodes with virtual instances in the network simulation test cloud and perform virtual-real integration. Therefore, there is also a lack of a technical solution for establishing a target range platform for virtual-real integration. Here, the "virtual" in virtual-real integration refers to virtual instances, and the "real" in virtual-real integration refers to real physical nodes. The present application provides a technical solution for integrating virtual instances with real physical nodes and establishing a target range platform. The target range platform can be used for network security testing, such as network security testing for power monitoring networks.

[0065] Figure 1 It is a flowchart of a method for establishing a virtual-reality integrated shooting range platform provided in one embodiment of the present application.

[0066] S11, generating a communication system based on each virtual instance and a control node, wherein the control node in the communication system is communicatively connected to each real physical node, and each virtual instance is communicatively connected to the control node.

[0067] Virtual instances include, but are not limited to, any of virtual machines, containers, databases, bare metal servers, object storage buckets, cloud gateways, and cloud caches.

[0068] The control node is used to communicate with the external network and is the external network interface of the entire communication system. The control node may include an external network card, which is used to communicate with the external network.

[0069] By generating a communication system based on each virtual instance and a control node, and respectively establishing communication connections between each virtual instance and the control node, and establishing communication connections between the control node and each real physical node, it is possible to establish communication connections between each virtual instance and each real physical node, thereby integrating the virtual instance and the real physical node to generate a virtual-real integrated communication system.

[0070] S12, establishing a range platform based on the communication system, wherein the range platform is used for network security testing.

[0071] By generating a virtual-reality fusion communication system, a test range platform can be further established. This test range platform can be used for cybersecurity testing. For example, the test range platform can be applied to the field of cybersecurity test range simulation platform for power monitoring systems.

[0072] When devices used to receive real physical nodes need to be connected to the communication system, communication applications corresponding to the target simulation scenario nodes can be deployed on each virtual instance in the communication system and displayed through a front-end visual interface. Simulation testers can simulate various attributes related to communication traffic based on the constructed simulation scenario.

[0073] A network simulation test cloud can be implemented based on the OpenStack cloud operating system to manage hardware resources. Although virtual instances within OpenStack can access external OpenStack traffic using floating IP addresses (FloatingIPs) provided by external networks, the internal OpenStack network is a "black box" to the outside world. External networks are unaware of the virtual instance topology within OpenStack.

[0074] The present application generates a communication system based on each virtual instance and a control node, and establishes a range platform for network security testing based on the communication system, wherein the control node in the communication system is respectively connected to each real physical node, and the each virtual instance is respectively connected to the control node. The present application generates a communication system based on each virtual instance and a control node, and respectively connects each virtual instance to the control node and connects the control node to each real physical node, so that each virtual instance can be connected to each real physical node, thereby integrating the virtual instance with the real physical node to generate a virtual-real fusion communication system. By generating a virtual-real fusion communication system, a range platform can be further established. The range platform can be used for network security testing, so that the virtual instances in the communication system can communicate with external real physical nodes, and then the range platform can test the communication traffic between the virtual instances in the communication system and the external real physical nodes, thereby improving the effectiveness of network security testing in various network security scenarios and improving the security and stability of various network security systems.

[0075] The target range platform used for network security testing in this application can be applied to various fields. When applied to a power monitoring system, it can enable the power monitoring system network security target range simulation platform to receive real external physical information, such as real communication information of a real substation, so that the power monitoring system network security target range can test real external physical information more realistically, thereby improving the security and stability of the power monitoring system.

[0076] Figure 2 It is a schematic diagram of a virtual-reality fusion shooting range platform provided in one embodiment of the present application.

[0077] like Figure 2 As shown, in the communication system, the first control node 221, the second control node 222, ..., the Nth control node 22N are respectively communicatively connected to the first real physical node 231, the second real physical node 232, ..., the Nth real physical node 23N. The first virtual instance 211, the second virtual instance 212, ..., the first virtual instance 21N are respectively communicatively connected to the first control node 221, the second control node 222, ..., the Nth control node 22N.

[0078] By generating a communication system based on the above virtual instances and control nodes, and respectively communicating with each virtual instance and the control node, and communicating with each real physical node, it is possible to achieve communication connection between each virtual instance and each real physical node, thereby realizing the fusion of virtual instances and real physical nodes to generate a virtual-real fusion communication system, and realizing the establishment of a target range platform for network security testing based on the communication system.

[0079] In one embodiment, each of the virtual instances is communicatively connected to the control node, including:

[0080] Each of the virtual instances is communicatively connected to the control node via a virtual router in the virtual subnet.

[0081] The communication system includes a virtual subnet corresponding to the external network. This virtual subnet is used to establish a virtual router responsible for routing external traffic. The virtual router internally records NAT and routing information for communication between the internal and external networks. The virtual router assigns floating IP addresses to each virtual instance within the communication system. On the communication system's dashboard, floating IP addresses appear attached to each virtual instance. However, in reality, the virtual instances remain unchanged. The floating IP addresses are actually reflected in the routing table within the virtual router, which records the correspondence and mapping between the floating IP addresses and the internal IP addresses of the virtual instances. The control node communicates with the physical nodes on the external network through its external network interface card. The control node and its external network interface card serve as the external network interface of the communication system.

[0082] Each virtual instance communicates with the control node through the virtual router in the virtual subnet, and the control node communicates with the real physical node of the external network through its external network card to realize the communication connection between each virtual instance and each real physical node.

[0083] Figure 3 2 is a schematic diagram of a communication system provided in an embodiment of the present application.

[0084] like Figure 3 As shown, a virtual machine is bound to a virtual port through a virtual network card. Furthermore, the virtual port is bound to a floating IP address and a virtual router. Virtual subnets provide IP address acquisition, isolation, and routing. A virtual router provides a public IP address through a floating IP address. The virtual router communicates with the internet and external physical nodes through an external network access interface and a physical network card.

[0085] When virtual machines obtain external traffic from the cloud platform, they cannot do without the support of the Neutron module in OpenStack. In the process of virtual-to-real intercommunication, the virtual network card and port inside the virtual machine, the physical external network card of the control node host in the communication system, the external network of OpenStack, and the floating IP address provided by the virtual router in the external network are involved. The process of establishing a connection between the virtual instance inside OpenStack and the external real traffic is as follows: Figure 3 shown.

[0086] In one embodiment, each virtual instance is communicated with the control node through a virtual router in a virtual subnet, including:

[0087] When data needs to be sent to a real physical node, the virtual instance sends the data to the virtual router in the virtual subnet based on the floating IP address;

[0088] The virtual router in the virtual subnet sends the data to the control node;

[0089] The control node sends the data to the real physical node.

[0090] When a virtual instance needs to send data to a real physical node, it sends the data to the virtual router in the virtual subnet using the floating IP address assigned by the virtual router. The virtual router in the virtual subnet then sends the data to the control node in the communication system. The control node then sends the data to the real physical node using the physical network interface card (NIC) on the external network.

[0091] The principles of communication within OpenStack virtual instances explain why establishing floating IP addresses is essential for facilitating traffic flow between virtual instances and external physical nodes. Before understanding how floating IP addresses facilitate communication between virtual instances and the outside world, it's important to understand that floating IP addresses provide a unified IP address, not the actual IP address providing services. Instead, they employ a type of static NAT (Network Address Translation).

[0092] Figure 4 This is a schematic diagram of floating IP address conversion provided by an embodiment of the present application.

[0093] like Figure 4 As shown, when it is a corresponding virtual instance (for example, a virtual machine, Figure 4 After a floating IP address is assigned to a virtual machine (VM, which stands for Virtual Manufacturing), OpenStack automatically configures the floating IP address 192.168.1.140 / 32 on the interface of the virtual router.

[0094] The following two NAT rules for floating IP addresses are added to the routing table (iptables):

[0095] "-d 192.168.1.140 / 32-j DNAT--to-destination 10.0.1.13

[0096] -s 10.0.1.13 / 32-j SNAT–to-source 192.168.1.140”.

[0097] When a packet is sent from the external network to OpenStack, its destination address is the floating IP address of the virtual instance represented by the external network: 192.168.1.140. After passing through the virtual router, the packet's destination address becomes the virtual instance's internal IP address, 10.0.1.13, allowing the packet to reach the virtual instance successfully. Conversely, when a virtual instance within OpenStack sends a packet to the external OpenStack network, the packet's source address changes from 10.0.1.13 to the floating IP address, 192.168.1.140, after passing through the virtual router. Observing the interface behavior on the virtual router using a packet capture tool (such as tcpdump) reveals that communication with the external network on this interface always occurs through the floating IP address, 192.168.1.140. However, once the data is forwarded to the tenant network, the packet's address changes to the tenant virtual instance's IP address, 10.0.1.13. This is the complete process of communication between virtual instances within the cloud platform and the external world.

[0098] Based on the traffic exchange between virtual instances and external physical nodes, a node that acts as a "mapping node" can be generated within the communication system. By assigning a floating IP address to this mapping node, the barriers between OpenStack's internal and external networks can be broken down.

[0099] Figure 5 It is a schematic diagram of a communication system provided by another embodiment of the present application.

[0100] like Figure 5 As shown, when a real physical node communicates with the corresponding network within the communication system, it can communicate with the node that creates the "mapping effect." Conversely, when a virtual instance within the communication system communicates with a real physical node externally, it is equivalent to the virtual instance communicating with the mapping node, which is connected to the same internal network segment. Within the communication system, this mapping node acts as the physical node with which the external real physical node and virtual instance communicate. By mapping the external real physical node to a node within the communication system that the virtual instance intends to communicate with, traffic between virtual instances within OpenStack and external real physical nodes is achieved.

[0101] In one embodiment, each of the virtual instances is communicatively connected to the control node, including:

[0102] Each virtual instance is connected to the control node through a mapping node. The virtual instance of OpenStack communicates with the external network through a floating IP address. The floating IP address is generated by a virtual router, and the virtual router must be established in the external network of OpenStack. Therefore, the first step for a virtual instance to communicate with the external network is to establish an external network on the external network card. On the basis that the virtual instance (Instance) of OpenStack can communicate with the external network, the internal mapping node (the mapping node is mapped to the external real physical node) is mounted on the management network segment. Based on the previous configuration, the management network segment can already communicate with the external network.

[0103] Assign a floating IP address to the mapping node. The instructions are as follows:

[0104] "#neutron floatingip-create ext-net

[0105] #nova floating-ip-associate instance 192.168.1.140

[0106] #iptables -t nat -S".

[0107] After that, you need to configure corresponding routing rules on the real physical nodes outside the communication system. This allows the real physical nodes to forward packets destined for the OpenStack intranet IP address 10.0.1.13 through the floating IP address configured on the mapping node. This is a key step in connecting the external real physical nodes with the OpenStack internal tenant network. Accordingly, virtual instances that want to communicate with the real physical nodes outside OpenStack must also configure the same routing rules. This ensures that packets sent from the virtual instances are also sent to the external real physical nodes along the same path, thus achieving symmetric communication paths.

[0108] Finally, to ensure that data packets can be sent to the mapping node smoothly after reaching the virtual router inside the OpenStack control node, you need to add routing rules on the virtual router:

[0109] #ip netns exec qrouter-298ff74e-xxxxxx route add-net 10.0.1.0 / 24gw192.168.1.141

[0110] Figure 6 This is a schematic diagram of a communication system provided in yet another embodiment of the present application.

[0111] like Figure 6 As shown, external real physical nodes communicate with virtual instances through virtual routers and mapping nodes.

[0112] In one embodiment, each virtual instance is communicated with the control node through a mapping node, including:

[0113] When data needs to be sent to a real physical node, the virtual instance sends the data to the mapped node based on the floating IP address;

[0114] The mapping node sends the data to the virtual router inside the control node;

[0115] The virtual router inside the control node sends the data to the real physical node.

[0116] like Figure 6 As shown in the figure, when a virtual instance needs to send data to a real physical node, the virtual instance sends the data to the mapping node using the floating IP address assigned by the mapping node. The mapping node then sends the data to the virtual router inside the control node using the floating IP address. The virtual router inside the control node then sends the data to the real physical node.

[0117] Figure 7 It is a schematic diagram of a communication system provided by another embodiment of the present application.

[0118] The mapping node replaces the external real physical node to forward data packets. In other words, the mapping node is equivalent to the external real physical node. When the external real physical node changes from a single physical node to a physical node cluster, it can transition from a single virtual link to multiple virtual links in parallel. Figure 7 As shown, each real physical node that wants to communicate with the communication system corresponds to a mapping node in the communication system that provides forwarding function for the real physical node.

[0119] Here, mapping nodes include but are not limited to virtual machines, containers, etc. Figure 5 、 Figure 6 、 Figure 7 In the illustrated embodiment, the mapping node can be a KVM (Kernel-based Virtual Machine) virtual machine. The mapping node can also be a container. The following describes an implementation using a container as a mapping node.

[0120] Figure 8 This is a schematic diagram of a communication system provided in yet another embodiment of the present application.

[0121] like Figure 8As shown, Docker containers are used as mapping nodes. Data packets from real physical nodes are sent to the Docker containers, which then forward the received data packets to the corresponding virtual instances. While the existing network topology remains unchanged, using Docker containers as mapping nodes significantly reduces the overhead of OpenStack's underlying physical resources. When the number of real physical nodes communicating with virtual instances in the communication system is large, the virtual-real integration achieved through Docker's lightweight containerization technology significantly reduces the overhead of underlying physical resources.

[0122] The method of establishing a target range platform that uses KVM virtual machines as mapping nodes to achieve virtual-real integration is more suitable for applications with fewer real physical nodes. For example, in the scenario of a single real physical node mentioned above, in this scenario, only one mapping node needs to be generated to meet the needs of virtual-real integration, which has almost no impact on the overall performance of the communication system. However, for simulation scenarios such as large-scale networks with a large number of real physical nodes, if KVM virtual machines equal to the number of nodes in the real physical node cluster are generated as mapping nodes, the computing resources in the communication system will be greatly occupied. For scenarios with multiple real physical nodes, in order to prevent the mapping nodes from occupying too many underlying resources when realizing the virtual-real integration of the physical node network, lightweight virtualization technology can be used to use Docker containers instead of KVM virtual machines as mapping nodes.

[0123] Docker automates the process of deploying applications into highly portable and self-sufficient containers, while remaining independent of hardware, languages, frameworks, and even operating systems. With the advancement of cloud computing, Docker has been integrated into the OpenStack cloud resource management platform. Furthermore, thanks to the Nova module within OpenStack, the integration of Nova and Docker further enhances Docker's capabilities. This is because OpenStack can centrally manage Docker through components within Nova. Compared to KVM virtual machines, Docker containers directly virtualize the host operating system. Each independent space has its own underlying CPU, memory, and other resources. Therefore, containers significantly outperform KVM virtual machines in terms of CPU, memory, and bandwidth utilization. To better represent resource utilization, this article abstracts the physical host's resource configuration as the set: HR = {cpu, mem, bw}, representing the CPU, memory (mem), and network interface card bandwidth (bw), respectively. To facilitate understanding of the model, this article will not consider the impact of resident processes on the physical machine. In the simulation test cloud, the resource usage of a computing node refers to the sum of the resource requests of all virtual instances created in the cloud platform. The resource usage rate is the quotient of the resource requests and the total resources. The resource usage rate of computing node pj is:

[0124]

[0125] Among them, h belongs to the HR set and represents the type of resource request. Represents the computing node P j The actual utilization rate of the hth type of resources. Represents the computing node P j The sum of the h-th type of resources owned by the above. Indicates deployment on computing node P j The total amount of requests for h-th type of resources by the virtual machines on the computing node P j Virtual machine V deployed on j Assuming the same number of The larger the value, the more serious the virtual machine's resource usage. The smaller the value, the smaller the virtual machine's occupancy of the computing node.

[0126] After the introduction of container virtualization, the host will have two sets of virtualized resources: VI = {V, O}. V represents the KVM virtual machine and O represents the Docker container. j The resource usage is:

[0127]

[0128] Since containers occupy much more CPU, memory, and bandwidth resources than KVM virtual machines, under the premise of performing the same tasks, for the same resources, are much smaller than r i h Therefore, replacing KVM virtual machines with Docker containers will greatly optimize host resource utilization.

[0129] This application uses Nova-Docker to integrate OpenStack with Docker. This solution allows Docker containers to be operated like KVM virtual machines and used as mapping nodes. Nova uses the Nova-Docker component to integrate Docker into OpenStack, allowing scheduling operations such as starting and shutting down Docker containers just like operating virtual machines, without the need for a separate management module to manage Docker in a unified manner.

[0130] Figure 9 This is a schematic diagram of a container architecture provided in an embodiment of the present application.

[0131] like Figure 9 As shown, Docker acts as a new hypervisor. Therefore, containers can be scheduled as if they were virtual machines. Furthermore, the Nova driver embeds a small HTTP client that communicates via Unix sockets and Docker's internal REST API, using the HTTP API to control containers and obtain information about them. The driver can also retrieve images from OpenStack's Glance image service module and load them into the Docker file system. This allows images to be exported from Docker and placed in Glance using the Docker save command.

[0132] By integrating Docker into OpenStack, lightweight containerization technology can be used to create containers, replacing KVM virtual machines as mapping nodes for forwarding. With this approach, aside from differences in the creation process and centralized management within OpenStack, Docker containers and KVM virtual machines operate in the same way when it comes to assigning floating IP addresses and forwarding data packets from real physical nodes to their corresponding target virtual instances.

[0133] A method for establishing a virtual-real fusion target range platform based on node mapping configures corresponding routing rules for virtual routers to allow data packets to smoothly enter the internal network of the communication system, and uses mapping nodes established within the communication system to "receive" data packets from real physical nodes.

[0134] The virtual-real integration achieved through this method has the following advantages: First, it is simple and easy to operate. For each real physical node to communicate with the virtual instance within OpenStack, a mapping node is simply established to map to the real physical node, without having to touch or operate the underlying OpenStack network architecture. Second, it is intuitive. By using mapping nodes to achieve virtual-real integration, although the real physical nodes are external to the communication system, the mapping nodes within OpenStack can be effectively treated as "physical nodes within the cloud simulation platform." Therefore, in the simulation test cloud topology, the mapping nodes can be presented instead of physical nodes.

[0135] However, achieving virtual-reality integration solely through mapping nodes has its drawbacks. First, it consumes a lot of virtual resources. Every time a real physical node connects to the communication system to communicate with a virtual instance, the OpenStack cloud resource management layer must invoke underlying resources within the communication system to create a new virtual instance as a mapping node for the real physical node. Consequently, when more real physical nodes are subsequently needed to connect to the communication system, the OpenStack cloud resource management layer must invoke even more underlying resources to create a corresponding number of mapping nodes, resulting in significant resource waste. Second, it can degrade network performance. After packets from a real physical node pass through the virtual router and enter the cloud platform's internal network, they must be forwarded once by a mapping node before reaching the corresponding virtual instance. Packets sent from a virtual instance to a node outside the cloud platform also undergo a forwarding process, rather than directly reaching the corresponding real physical node. This extra hop increases network latency, further degrading network performance. Finally, some simulation scenarios can obscure the simulation topology. For example, if a cluster of real physical nodes exists outside the cloud simulation platform, but only a few of the real physical nodes are connected to the cloud simulation platform in the physical topology, the cloud simulation platform will generate an equal number of mapping nodes to serve as replacements for the real physical nodes within the cloud platform. However, the network topology automatically displayed to the user on the cloud simulation platform's user interface is a combination of the mapping nodes and the real physical nodes connected to the cloud platform, rather than the complete topology of the network under test as required by the simulation.

[0136] Overall, the disadvantages of achieving virtual-reality fusion through mapping nodes are that an additional mapping node is established for the real physical node within the cloud platform, which leads to multiple issues such as simulation cost, network performance, and scene blurring. Therefore, based on the method mentioned above, this application provides a virtual-reality fusion simulation solution based on OpenvSwitch.

[0137] The OpenStack architecture described in this article is as follows: the control node and network nodes are deployed on the same physical machine, while the compute nodes are distributed. Within the overall cloud platform architecture, the control node is the management and control node for all nodes, interacting with data and management information with all other nodes. This cross-host communication is implemented using Generic Routing Encapsulation Tunnel (GRE tunnel). Furthermore, in addition to cross-host communication, communication between virtual instances within a compute node, as well as communication between the control node and numerous virtual machines on the external network, requires the use of a bridge. OpenStack implements this functionality using the Open vSwitch virtual bridge.

[0138] Open vSwitch is an open-source virtual switch primarily used to provide network connectivity for virtual instances in virtual environments. It is a key technology for network virtualization and is therefore widely used in cloud computing data centers. Compared to conventional switches, Open vSwitch is not only low-cost but also adapts to both traditional and emerging network protocols. Furthermore, because it is a virtualization-focused switch, Open vSwitch supports many popular virtualization technologies, making it well-suited for integration with cloud computing. It includes three types of bridges: br-tun (encapsulation tunnel bridge), br-int (aggregation bridge), and br-ex (external bridge). These three bridges have distinct functions. br-int (aggregation bridge) is an aggregation bridge, where all forwarding packets from each node are aggregated and processed. br-tun (encapsulation tunnel bridge) is responsible for encapsulation tunnels in a distributed architecture, connecting different hosts. br-ex (external bridge) handles communication between the cloud platform's internal network and the cloud platform's external network.

[0139] When using Open vSwitch to build a communication channel between the OpenStack intranet and the external network, the most important thing is to properly handle the connection relationship between the three bridges in Open vSwitch.

[0140] Figure 10 This is a schematic diagram of virtual instances communicating through a summary bridge provided by an embodiment of the present application.

[0141] like Figure 10 As shown in the figure, when a virtual instance is created in OpenStack, a tap is created on the corresponding virtual instance's network port on the compute node. The tap is directly connected to the virtual bridge device qbr. qbr, in turn, connects to the qvo device mounted on the compute node's br-int bridge through the qvb device. Each host, whether a compute node or a controller node, has its own br-int bridge. However, both virtual machines and virtual routers perceive themselves as connected to the same large br-int bridge, which communicates over the same Layer 2 network. Virtual machines and virtual routers are only aware of the br-int bridge and are unaware of the br-tun bridge. Therefore, all packets connected to the same br-int bridge can communicate freely over the data network segment.

[0142] Because br-int bridges exist on different physical machines, a method is needed to solve the cross-host communication problem of br-int bridges on different hosts. In the target range platform built in this article, the underlying OpenStack uses GREtunnel (Generic Routing Encapsulation Tunnel) to connect br-int on different machines.

[0143] For virtual instances to communicate with networks outside of OpenStack, they need two things: a floating IP address and a br-ex bridge. As mentioned earlier, the first step for virtual instances within OpenStack to communicate with the external network is to create an external network. The floating IP address here must match the external network segment configured previously. This is because the network established with Open vSwitch is a Layer 2 network. If the segments are not on the same network segment, traffic will not be uniformly transmitted through the external network interface card. The floating IP address is generated by the virtual router of the network node (in this case, the control node), while the br-ex bridge must be generated manually. In Open vSwitch, the connection between bridges is similar to a veth interface in Linux and requires a patch port to connect. The same principle applies when creating a br-ex bridge.

[0144] Figure 11 This is a schematic diagram of real physical nodes communicating through an external bridge provided by an embodiment of the present application.

[0145] like Figure 11As shown in the figure, when creating the br-ex (external bridge), there are two core ports. One port is the patch port connected to the br-int bridge. The other port is the normal port connected to the external network card on the control node.

[0146] In an unmodified OpenStack platform, packets are sent from the physical network interface cards (NICs) of real physical nodes and arrive at the control node's NIC, which connects to the external network. By reconfiguring the Open vSwitch bridge, the control node's external NIC is connected to the br-ex bridge, allowing packets to reach the control node's external NIC. Because the virtual router lacks routing rules to the target virtual instance, packets are stuck at the control node's entry point. Furthermore, the virtual instance's IP address is private, so the packet still cannot be addressed to the private IP address and, therefore, cannot reach the target virtual instance. Therefore, the virtual instance must be assigned the same floating IP address as the physical node. In this case, the floating IP address is mapped one-to-one with the virtual machine's management network segment on the virtual router. Once the floating IP address is found, the packet can successfully reach the target virtual machine. Once the packet enters the cloud platform, it can then use the floating IP mapping rules in the virtual router to find the target virtual instance and complete communication. The reverse process for sending packets from the virtual instance to physical machines outside the cloud platform is the same.

[0147] Figure 12 It is a structural diagram of a communication system provided in yet another embodiment of the present application.

[0148] Each virtual instance is communicated with the control node through a mapping node, including:

[0149] When data needs to be sent to a real physical node, the virtual instance sends the data to the encapsulation tunnel bridge according to the floating IP address, and the encapsulation tunnel bridge is connected to the summary bridge of the control node;

[0150] The mapping node sends the data received through the summary bridge to the virtual router inside the control node;

[0151] The virtual router inside the control node sends the data to the real physical node through an external bridge.

[0152] like Figure 12As shown, when a virtual instance in a compute node needs to send data to a real physical node, the virtual instance sends the data to the encapsulation tunnel bridge (br-tun) based on the floating IP address. The encapsulation tunnel bridge is connected to the control node's summary bridge via GRE. The mapping node sends the data received through the summary bridge (br-int) to the virtual router inside the control node. The virtual router inside the control node sends the data to the real physical node via the external bridge (br-ex).

[0153] In practice, network topologies typically involve multiple network segments coexisting and co-simulating. Within a cloud platform, virtual instances on different network segments can all communicate with real physical nodes outside the cloud platform through floating IP addresses assigned by routers connected to the cloud platform's external network segment. However, since the cloud platform's external network segment is only one, only one floating IP address can be assigned to a virtual instance. When a cluster of real physical nodes on multiple, different network segments outside the cloud simulation platform wants to connect to the cloud platform, whether achieving virtual-reality integration through node mapping or virtual switches, the challenge is how to direct traffic from multiple external network segments into the cloud platform.

[0154] First, the floating IP address service is provided by the virtual router (V-Router). However, in OpenStack, there is only one external network by default, and the virtual router exists in the virtual router.

[0155] Figure 13 This is a schematic diagram of a physical network card in a virtual router in the prior art.

[0156] like Figure 13 As shown in the figure, OpenStack can only provide a floating IP address in one network segment. At the same time, OpenStack also assumes that all virtual routers connected to the Linux-Bridge (Linux bridge) are connected to the same fixed physical network card. Figure 13 As shown in the figure, due to the settings in the / etc / neutron / plugins / ml2 / ml2_conf.ini configuration file, both VMs can only reach the external network through the same physical NIC. Even if a virtual router and a new physical NIC are added to connect to the external network, the virtual router's Linux Bridge will still connect to eth1 due to the default configuration settings. Therefore, the underlying configuration must be modified to enable multiple floating IP addresses in OpenStack by creating multiple virtual routers.

[0157] In the configuration file, change the virtual router's physical network card connection method from "default: eth1" to "eth1, eth3." Create a new external network for the newly created eth3 network card. Then, create a new virtual router and associate it with the newly created external network.

[0158] Figure 14 This is a schematic diagram of a physical network card in a virtual router provided in an embodiment of the present application.

[0159] like Figure 14 As shown in the figure, the new virtual router (router2) will be connected to the physical network port (eth3) corresponding to the new external network due to the change in the configuration file, so that the same floating IP as the external network can be allocated.

[0160] In OpenStack, the steps to establish a floating IP pool are as follows: first, you need to establish an external network. When creating the external network, you will specify the network card connected to the outside. This option is generally the default (OpenStack has only one external network card by default). After creating the external network, you need to create a new virtual router under this external network, and then you can use this virtual router to generate floating IP addresses under this external network. In general, the virtual and real integration of real physical nodes in multiple network segments based on multiple floating IP addresses is mainly achieved by modifying the configuration of the underlying OpenStack of the cloud platform, changing the OpenStack external network card from the default one to multiple, and creating a new virtual router under the new external network. At this point, OpenStack will add a new floating IP pool based on the virtual router under the new external network, so that floating IP addresses of multiple network segments can be allocated to virtual instances.

[0161] This solution breaks the underlying limitation of OpenStack that it can only support one external network by default, allowing more network segment traffic to enter the communication system through the floating IP address corresponding to the network segment to collaborate with the virtual instance simulation.

[0162] However, since adding a new external network and thus a new floating IP address requires adding a physical network card, this solution is overly dependent on the number of physical devices. The physical machines hosting the cloud simulation platform's network nodes have a very limited capacity for adding physical network cards. If the number of network segments in the external physical node network exceeds the number of physical network cards on the network node host, this solution will not work. Therefore, this solution is only suitable for simulation scenarios with a small number of network segments in the physical node network.

[0163] To overcome the limitations of physical network cards when implementing virtual-real convergence across multiple network segments, it is essential to ensure that no matter how many external network segments access the simulated test cloud, they can only communicate with the virtual instance through a single external network port. Taking the communication system in this article as an example, without changing the underlying configuration of the communication system, the external network port is set to the eth2 network card on the host where the control node resides. The external network segment corresponding to eth2 is 192.168.31.0 / 24, meaning that external traffic can only enter through the eth2 network port. The communication system exposes only one accessible network segment to external physical nodes: 192.168.31.0 / 24. Regardless of the number of external physical nodes or their network segments, access to the communication system can only be achieved through the eth2 network port, i.e., through the 192.168.31.0 / 24 network segment.

[0164] As previously mentioned, when integrating virtual and real resources into a single physical node, provided virtual routers and virtual switches are configured, physical traffic can be imported by attaching a floating IP address corresponding to the physical node's network to an internal virtual instance. Based on this physical node, a routing node can be added to the original communication system to import traffic from multiple external network segments. By configuring routing rules on this routing node, traffic not destined for the 192.168.31.0 / 24 network segment specified by the cloud platform's external network can be routed and forwarded to the virtual instance configured with the floating IP address.

[0165] Figure 15 This is a schematic diagram of a routing node provided in an embodiment of the present application.

[0166] like Figure 15 As shown in the figure, the portion to the right of the dashed line represents the network topology of the actual physical nodes to be connected to the communication system. The portion to the left of the dashed line represents the communication system. In addition to the existing compute and control nodes, the communication system adds a routing node responsible for routing different network segments. To expand the number of external network segments that the routing node can route, several expansion network cards are connected in addition to the routing node's built-in network card.

[0167] The network card corresponding to the routing node on the left is connected to the control node in the communication system. This network card is set to the same IP address as the floating IP address in the communication system: 192.168.31.145. This allows it to access the communication system's external network segment. The network port IP addresses to the right of the routing node in the figure are: 192.168.32.145, 192.168.33.145, and 192.168.34.145, respectively, which are connected to the corresponding physical nodes 192.168.32.101, 192.168.33.101, and 192.168.34.101 in the real physical node network.

[0168] Based on the above physical device connections, corresponding routing rules must be added within the routing node to ensure smooth cross-segment traffic. At the same time, for each additional network segment, the control node (also known as the network node) in the communication system must add a corresponding route to the routing table, ensuring that data packets destined for the target physical network segment must pass through the network card in the routing node connected to the communication system. For example, if the 192.168.32.0 / 24 network segment is added to the real physical node network:

[0169] #route add-net 192.168.32.0 / 24gw 192.168.31.145.

[0170] Correspondingly, a real physical node that wants to communicate with the virtual instance in the communication system also needs to add a routing instruction, also using the 192.168.32.0 / 24 network segment as an example:

[0171] #route add-net 192.168.31.0 / 24gw 192.168.31.145.

[0172] When a data packet is sent from a real physical node, it passes through the router and is centrally sent to the right network card of the routing node. Because routing rules have been set up in advance, the data can enter the routing node smoothly. Once at the routing node, the routing node's internal forwarding rules will send the data packet to the network card connected to the routing node and the communication system. The data packet will then smoothly enter the external network segment of the host computer where the communication system is located, and thus reach the virtual instance. The process of sending data packets from the virtual instance to the external physical machine is also the same.

[0173] In one embodiment, each of the virtual instances is communicatively connected to the control node, including:

[0174] The external network card of the control node receives data sent by the routing node, the first floating IP address of the data sent by the routing node corresponds to the first management network segment of the target virtual instance, wherein the routing node receives the data sent by the real physical node and forwards it to the external network card of the control node;

[0175] The virtual router inside the control node determines the first management network segment where the target virtual instance corresponding to the first floating IP address is located according to the mapping relationship between the floating IP address and the management network segment;

[0176] The control node sends the data to the target virtual instance corresponding to the data according to the first management network segment.

[0177] like Figure 15 As shown, the routing node receives data sent by the real physical node and forwards it to the external network card of the control node. The external network card of the control node receives the data sent by the routing node. The first floating IP address of the data sent by the routing node corresponds to the first management network segment of the target virtual instance. Then, the virtual router within the control node determines the first management network segment of the target virtual instance corresponding to the first floating IP address based on the mapping relationship between the floating IP address and the management network segment. Subsequently, the control node sends the data to the target virtual instance corresponding to the data based on the first management network segment.

[0178] By configuring a virtual instance with the same floating IP address as a physical node, the virtual router maps the floating IP address to the virtual machine's management network segment. Once the floating IP address is found, traffic can reach the target virtual instance. After entering the communication system, data packets can then find the target virtual instance using the floating IP mapping rules within the virtual router, completing communication.

[0179] By adding routing nodes, the communication system no longer needs to maintain multiple floating IP pools for different external network segments. The communication system always has only one external network segment. Whenever a virtual instance within the communication system wants to communicate with an external physical node, it simply uses a floating IP address, regardless of the physical node's network segment. The entire routing, addressing, and forwarding process is handled by the routing nodes, making the establishment of a virtual-real world converged range platform clearer, easier to understand, and more easily implemented.

[0180] Furthermore, by adding routing nodes, the creation of a virtual-reality fusion range platform is no longer limited by the number of physical network cards in the host computer housing the control node (network node) in the communication system. However, routing nodes also have a limited number of network cards. For example, in the host computer used as the routing node in this article, even if all slots reserved for network card expansion are used, the maximum number of network ports can only reach 20. In other words, a single routing node can extend up to 20 external network segments into the cloud simulation platform's external network segment.

[0181] When the number of network segments in a network consisting of external physical nodes exceeds 20, expansion can be performed on a single routing node to address the issue of insufficient carrying capacity. By transforming a routing node into a routing node cluster, the communication bottleneck caused by all physical traffic entering the cloud platform through a single network card in the routing node can be resolved.

[0182] Figure 16 This is a schematic diagram of a routing node cluster provided in an embodiment of the present application.

[0183] like Figure 16 As shown in the figure, as the number of real physical nodes to the right of the dotted line increases, the routing node can be expanded from a single node to a routing node cluster. All routing nodes in the cluster and the external network ports of the communication system are connected to a single router. The routing rules deployed in this router ensure that packets exiting the communication system's external network port know which routing node to enter, thereby reaching the corresponding real physical node. This solution fundamentally solves the technical problem of insufficient physical network ports on the communication system host by expanding the number of routing nodes.

[0184] Figure 17 It is a structural diagram of the device for establishing a virtual-reality integrated shooting range platform provided in an embodiment of the present application.

[0185] like Figure 17 As shown, the device 171 includes:

[0186] A first generating module 1711 is configured to generate a communication system based on each virtual instance and a control node, wherein the control node in the communication system is respectively communicatively connected to each real physical node, and each virtual instance is respectively communicatively connected to the control node;

[0187] The second establishing module 1712 is configured to establish a range platform based on the communication system, where the range platform is used for network security testing.

[0188] Another embodiment of the present invention discloses a device 171. Figure 17On the basis of the corresponding embodiment, each virtual instance is respectively communicated with the control node, including:

[0189] Each of the virtual instances is communicatively connected to the control node via a virtual router in the virtual subnet.

[0190] Another embodiment of the present invention discloses a device 171. Figure 17 On the basis of the corresponding embodiment, each virtual instance is communicated with the control node through a virtual router in the virtual subnet, including:

[0191] When data needs to be sent to a real physical node, the virtual instance sends the data to the virtual router in the virtual subnet based on the floating IP address;

[0192] The virtual router in the virtual subnet sends the data to the control node;

[0193] The control node sends the data to the real physical node.

[0194] Another embodiment of the present invention discloses a device 171. Figure 17 On the basis of the corresponding embodiment, each virtual instance is respectively communicated with the control node, including:

[0195] Each of the virtual instances is communicatively connected to the control node via a mapping node.

[0196] Another embodiment of the present invention discloses a device 171. Figure 17 On the basis of the corresponding embodiment, each virtual instance is communicated with the control node through a mapping node, including:

[0197] When data needs to be sent to a real physical node, the virtual instance sends the data to the mapped node based on the floating IP address;

[0198] The mapping node sends the data to the virtual router inside the control node;

[0199] The virtual router inside the control node sends the data to the real physical node.

[0200] Another embodiment of the present invention discloses a device 171. Figure 17 On the basis of the corresponding embodiment, each virtual instance is communicated with the control node through a mapping node, including:

[0201] When data needs to be sent to a real physical node, the virtual instance sends the data to the encapsulation tunnel bridge according to the floating IP address, and the encapsulation tunnel bridge is connected to the summary bridge of the control node;

[0202] The mapping node sends the data received through the summary bridge to the virtual router inside the control node;

[0203] The virtual router inside the control node sends the data to the real physical node through an external bridge.

[0204] Another embodiment of the present invention discloses a device 171. Figure 17 On the basis of the corresponding embodiment, each of the virtual instances is communicated with the control node respectively, including:

[0205] The external network card of the control node receives data sent by the routing node, the first floating IP address of the data sent by the routing node corresponds to the first management network segment of the target virtual instance, wherein the routing node receives the data sent by the real physical node and forwards it to the external network card of the control node;

[0206] The virtual router inside the control node determines the first management network segment where the target virtual instance corresponding to the first floating IP address is located according to the mapping relationship between the floating IP address and the management network segment;

[0207] The control node sends the data to the target virtual instance corresponding to the data according to the first management network segment.

[0208] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of this application. Their specific functions and technical effects can be found in the method embodiment section and will not be repeated here.

[0209] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0210] The present application also provides an electronic device, such as Figure 18 As shown, the electronic device 18 includes: at least one processor 180, a memory 181, and a computer program 182 stored in the memory 181 and executable on the at least one processor 180. When the processor 180 executes the computer program 182, the steps in any of the above-mentioned method embodiments are implemented.

[0211] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned various method embodiments can be implemented.

[0212] An embodiment of the present application provides a computer program product. When the computer program product is run on a mobile terminal, the mobile terminal can implement the steps in the above-mentioned various method embodiments when executing the computer program product.

[0213] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / electronic device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0214] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0215] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0216] In the embodiments provided in the present application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0217] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0218] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for establishing a virtual-real fusion shooting range platform, characterized in that: include: Generate a communication system based on each virtual instance and the control node, wherein the control node in the communication system is respectively communicatively connected to each real physical node, and each virtual instance is respectively communicatively connected to the control node; A shooting range platform is established based on the communication system, and the shooting range platform is used for network security testing.

2. The method for establishing a virtual-reality fusion shooting range platform according to claim 1, characterized in that: The respective virtual instances are respectively connected to the control node for communication, including: Each of the virtual instances is communicatively connected to the control node via a virtual router in the virtual subnet.

3. The method for establishing a virtual-reality fusion shooting range platform according to claim 2, wherein: Each virtual instance is communicated with the control node through a virtual router in the virtual subnet, including: When data needs to be sent to a real physical node, the virtual instance sends the data to the virtual router in the virtual subnet based on the floating IP address; The virtual router in the virtual subnet sends the data to the control node; The control node sends the data to the real physical node.

4. The method for establishing a virtual-reality fusion shooting range platform according to claim 1, wherein: The respective virtual instances are respectively connected to the control node for communication, including: Each of the virtual instances is communicatively connected to the control node via a mapping node.

5. The method for establishing a virtual-reality fusion shooting range platform according to claim 4, characterized in that: Each virtual instance is communicated with the control node through a mapping node, including: When data needs to be sent to a real physical node, the virtual instance sends the data to the mapped node based on the floating IP address; The mapping node sends the data to the virtual router inside the control node; The virtual router inside the control node sends the data to the real physical node.

6. The method for establishing a virtual-reality fusion shooting range platform according to claim 5, characterized in that: Each virtual instance is communicated with the control node through a mapping node, including: When data needs to be sent to a real physical node, the virtual instance sends the data to the encapsulation tunnel bridge according to the floating IP address, and the encapsulation tunnel bridge is connected to the summary bridge of the control node; The mapping node sends the data received through the summary bridge to the virtual router inside the control node; The virtual router inside the control node sends the data to the real physical node through an external bridge.

7. The method for establishing a virtual-reality fusion shooting range platform according to claim 1, wherein: The respective virtual instances are respectively connected to the control node for communication, including: The external network card of the control node receives data sent by the routing node, the first floating IP address of the data sent by the routing node corresponds to the first management network segment of the target virtual instance, wherein the routing node receives the data sent by the real physical node and forwards it to the external network card of the control node; The virtual router inside the control node determines the first management network segment where the target virtual instance corresponding to the first floating IP address is located according to the mapping relationship between the floating IP address and the management network segment; The control node sends the data to the target virtual instance corresponding to the data according to the first management network segment.

8. A device for establishing a shooting range platform integrating virtuality and reality, characterized in that: include: A first generating module is configured to generate a communication system based on each virtual instance and a control node, wherein the control node in the communication system is communicatively connected to each real physical node, and each virtual instance is communicatively connected to the control node; The second establishing module is used to establish a shooting range platform based on the communication system, and the shooting range platform is used for network security testing.

9. The device for establishing a virtual-reality fusion shooting range platform according to claim 8, characterized in that: The respective virtual instances are respectively connected to the control node for communication, including: Each of the virtual instances is communicatively connected to the control node via a virtual router in the virtual subnet.

10. The device for establishing a virtual-reality fusion shooting range platform according to claim 9, characterized in that: Each virtual instance is communicated with the control node through a virtual router in the virtual subnet, including: When data needs to be sent to a real physical node, the virtual instance sends the data to the virtual router in the virtual subnet based on the floating IP address; The virtual router in the virtual subnet sends the data to the control node; The control node sends the data to the real physical node.

Images