Virtual-real combined network target range simulation environment construction method and system

Abstract

The invention discloses a virtual-real combined network target range simulation environment construction method and system. The method comprises the following steps: receiving a network topology which is defined by a user through a graphical interface and comprises shadow components of virtual nodes and entity nodes; and analyzing a virtual-real connection relationship in the topology, and automatically linking and configuring the physical network and the virtual network by taking the virtual-real connection relationship as a trigger. The core of the system is that the system automatically configures VLAN isolation for a physical equipment port on a physical switch, and meanwhile, in a software router serving as a virtual network gateway, an interface facing a physical network and a VXLAN tunnel interface used for the virtual network are directly bridged to the same software network bridge. And automatically mapping VLAN (Virtual Local Area Network) and VXLAN (Virtual eXtensible Local Area Network) identifiers for virtual and real data streams by utilizing the network capability of the virtualized host machine, thereby constructing a transparent data forwarding tunnel. According to the invention, seamless and transparent communication between virtual resources and physical resources is realized through automatic VLAN and VXLAN tunnel mapping.

Description

Technical Field

[0001] This invention relates to the intersection of network communication technology and virtualization technology, and more specifically, to a method and system for constructing a virtual-real combined network range simulation environment. Background Technology

[0002] With the rapid development of information technology, the scale and complexity of network systems are increasing daily, and cybersecurity threats are becoming more diversified and complex. Against this backdrop, network ranges, as core infrastructure capable of simulating real network environments for network technology testing, cybersecurity attack and defense drills, and technology research and development verification, are becoming increasingly important.

[0003] The development of network range technology can be roughly divided into three stages. The first stage is the pure physical range stage. Ranges in this stage are entirely built from real physical devices, such as routers, switches, servers, and firewalls. Its advantage lies in providing extremely high environmental fidelity, accurately reflecting the performance of devices and network behavior in a real network. However, its drawbacks are also significant: high construction costs, requiring the purchase of a large number of expensive physical devices; long deployment cycles, involving complex physical wiring, device debugging, and network configuration; and poor scalability, as whenever a new network scenario needs to be built or devices added, hardware redeployment and configuration are often required, making it difficult to meet the testing needs of the rapid iteration of modern network technologies.

[0004] The second stage is the pure virtual testbed stage. With the maturity of virtualization technologies (such as KVM, VMware, Docker, etc.), pure virtual testbeds have become mainstream. These testbeds simulate various network nodes such as routers, switches, and terminal hosts on physical servers using virtualization software. Typical examples include open-source virtual simulation tools such as GNS3 and EVE-NG, as well as various virtual testbed systems built on cloud platforms. The core advantages of pure virtual testbeds are low construction costs, fast deployment speed, and the ability to flexibly create, destroy, and reset network scenarios. However, their biggest problem is insufficient realism. Virtual components cannot fully simulate the hardware characteristics of physical devices, such as the forwarding performance of specific chips, hardware-level vulnerabilities, electrical characteristics of physical ports, and signal attenuation and interference in real physical links. This leads to discrepancies between the test or exercise results based on pure virtual testbeds and the real network environment. Especially in scenarios with extremely high requirements for device realism, such as network security attack and defense exercises and industrial control network security testing, their application value is greatly limited, often resulting in the predicament of successful exercises but failure in real-world scenarios.

[0005] To balance realism and flexibility, the industry has begun exploring the third phase: the hybrid virtual-physical range phase. This phase aims to improve the fidelity of the range by connecting key physical devices to a virtual range environment via network connectivity. However, most existing hybrid virtual-physical solutions are still in the early stages of exploration and generally suffer from a series of technical bottlenecks.

[0006] First, there is a lack of standardized mechanisms for connecting physical devices. Connecting different types and manufacturers of physical devices (such as industrial PLCs or specific firewall models) often requires customized driver development or complex adaptation work, resulting in cumbersome connection processes and poor compatibility.

[0007] Secondly, network configuration is complex and highly dependent on manual intervention. To achieve network connectivity between virtual and physical nodes, technicians need to manually configure tedious network parameters at multiple levels, including physical switches, virtualized host machines, and virtual routers. These parameters include VLAN (Virtual Local Area Network) partitioning, IP address planning, and bridge settings. The entire process involves multiple network layers, with highly correlated parameters, making it prone to errors and inefficient. For example, the VLAN configuration of a physical switch port must precisely match the VLAN configuration in the virtual router or virtual switch; any slight error can lead to network failure. Troubleshooting requires logging into multiple devices one by one for verification, which is time-consuming and labor-intensive.

[0008] Furthermore, there is a serious disconnect between topology design and actual configuration. In existing virtual simulation tools, the topology diagrams drawn by users typically only include virtual nodes. The physical devices and their connections need to be manually recorded and managed through external documents or tables, creating a disconnect between the "topology diagram" and the "actual network configuration." As the test range expands and the number of connected physical devices increases, this management method greatly increases the difficulty of network operation and maintenance, making it difficult to quickly locate fault points or adjust and expand the topology.

[0009] Finally, existing technical solutions rely heavily on simple VLAN technology for network connectivity, lacking support for more advanced network virtualization technologies such as VXLAN (Virtual Extensible Local Area Network). This makes them insufficient for simulating large-scale, multi-tenant data center networks or complex industrial internet scenarios, unable to achieve cross-subnet Layer 2 network virtual-physical interoperability, thus limiting the application scope and scenario complexity of the test range.

[0010] In summary, the current field of virtual-real hybrid test range technology urgently needs a new technical solution to address the technical problems of insufficient realism in virtual networks and difficulties in integrating virtual and real networks. This solution should effectively address key technical challenges in existing technologies, such as non-standardized access of physical devices, cumbersome and error-prone network configuration, disconnect between topology and configuration, and insufficient support for complex network scenarios. This would improve the efficiency, reliability, and fidelity of test range construction and scenario simulation. Summary of the Invention

[0011] The purpose of this invention is to provide a method and system for constructing a virtual-physical network range simulation environment, so as to solve the technical problems in the prior art that when physical devices are integrated with virtual environments, the network configuration process is complex, the degree of automation is low, errors are easy to occur, and operation and maintenance management is difficult.

[0012] To achieve this objective, one aspect of the present invention provides a method for constructing a virtual-physical hybrid network range simulation environment. This method first receives user-defined network range topology information through a graphical topology editing interface. This information serves as a blueprint for the constructed environment, including not only virtual nodes such as virtual machines or containers, but also abstract representations of real physical devices—i.e., abstract shadow components of physical nodes—and clearly defines the logical connections between these virtual and physical nodes.

[0013] Next, the core step of this method is to parse the received connection relationships and automatically and in tandem trigger a series of network parameter configurations based on this. This automated, synergistic configuration process works collaboratively at both the physical and virtual network levels. At the physical network level, for physical switches used to connect physical nodes, the method automatically configures the physical ports connected to specific physical devices in Access Mode and binds them with a first network isolation identifier, thereby achieving physical isolation of traffic to that physical device. At the virtualized network level, the method automatically configures basic virtual network components such as software routers and first software bridges on the virtualized host machines hosting virtual nodes. Crucially, to interface with the physical network, the method creates a second network isolation identifier interface within the software router, corresponding to the aforementioned first network isolation identifier. Simultaneously, to achieve traffic isolation and large-scale networking within the virtualized network, the method also creates a third network isolation identifier interface within the software router. Finally, to bridge the physical and virtual domains, the method configures a second software bridge and bridges the aforementioned second and third network isolation identifier interfaces to this second software bridge. This bridging operation establishes a transparent data forwarding tunnel connecting virtual nodes and physical nodes, enabling virtual nodes and physical nodes that were originally located in different network domains to be in the same network address space and achieve seamless communication between them.

[0014] Preferably, the first network isolation identifier is a Virtual Local Area Network (VLAN) identifier, the second network isolation identifier interface is a VLAN tag interface, the third network isolation identifier is a Virtual Extensible Local Area Network (VXLAN) Network Identifier (VNI), and the third network isolation identifier interface is a VXLAN tunnel endpoint interface.

[0015] Preferably, after configuring the software router and the first software bridge on the virtualization host, the method further includes:

[0016] A Linux bridge is created on the virtualized host machine as the first software bridge, and its VLAN awareness function is enabled.

[0017] The physical network port of the virtualized host is bridged to the first software bridge, and the first software bridge is configured to allow data frames carrying the first network isolation identifier to pass through.

[0018] Preferably, the abstract shadow component of the entity node is a standardized data structure pre-generated based on the entity device port information entered by the user. The data structure includes the device type, physical port identifier, and the identifier of the port associated with it on the physical switch.

[0019] Preferably, the method further includes:

[0020] Based on the network range topology information, network address information is automatically assigned or configured for the virtual node and the physical node. The network address information includes IP address, subnet mask and gateway address; wherein, the software router serves as the default gateway for the virtual node and the physical node.

[0021] Another aspect of the present invention provides a system for constructing a virtual-physical network range simulation environment. This system includes a topology information receiving module for receiving network range topology information defined by the user through a graphical topology editing interface. The system also includes a network configuration engine as the control core, responsible for parsing the connection relationships in the aforementioned topology information and coordinating other modules for automated network configuration. The system includes a physical network configuration unit connected to the network configuration engine, specifically responsible for performing configuration tasks on physical switches, such as setting port modes and binding a first network isolation identifier. Simultaneously, the system also includes a virtual network configuration unit, also connected to the network configuration engine, responsible for configuring a software router and a first software bridge on the virtualized host. Furthermore, the system includes a core tunnel construction module, responsible for creating second and third network isolation identifier interfaces within the software router and configuring a second software bridge to bridge these two interfaces, thereby constructing a transparent data forwarding tunnel connecting the virtual and physical worlds, ensuring that virtual nodes and physical nodes are in a unified network address space and achieve seamless communication.

[0022] Preferably, the first network isolation identifier is a Virtual Local Area Network (VLAN) identifier, the second network isolation identifier interface is a VLAN tag interface, the third network isolation identifier is a Virtual Extensible Local Area Network (VXLAN) Network Identifier (VNI), and the third network isolation identifier interface is a VXLAN tunnel endpoint interface.

[0023] Preferably, the virtual network configuration unit is further configured to:

[0024] A Linux bridge is created on the virtualized host machine as the first software bridge, and its VLAN awareness function is enabled.

[0025] The physical network port of the virtualized host is bridged to the first software bridge, and the first software bridge is configured to allow data frames carrying the first network isolation identifier to pass through.

[0026] Preferably, it also includes a component management module, used to generate an abstract shadow component of the entity node based on the entity device port information entered by the user. The component is a standardized data structure, which includes the device type, physical port identifier, and the identifier of the port associated with it on the physical switch.

[0027] Preferably, the system further includes:

[0028] The network address management module is used to automatically allocate or configure network address information for the virtual nodes and the physical nodes based on the network range topology information. The network address information includes IP address, subnet mask and gateway address; wherein the software router serves as the default gateway for the virtual nodes and the physical nodes.

[0029] In summary, the core of the technical solution provided in this application lies in directly translating the user's topology design intent on the graphical interface into precise and coordinated network configurations on physical switches, virtualized hosts, and software routers through an automated workflow. By innovatively constructing a software bridge at the software router level that bridges VLAN and VXLAN interfaces, this application creates a transparent Layer 2 tunnel connecting the physical network domain and the virtual network domain. This mechanism allows data packets to flow freely between VLAN and VXLAN, two heterogeneous network isolation technologies, thereby achieving seamless Layer 2 communication between virtual and physical nodes.

[0030] Compared to existing technologies, this application offers significant advantages. First, it achieves a high degree of automation and intelligence in configuration. Users only need to perform simple drag-and-drop connection operations through a graphical interface, and the system can automatically complete the configuration of complex and highly interconnected network parameters across multiple layers, including physical switches, virtualized hosts, and software routers. This reduces the manual configuration process, which previously took hours or even days and was prone to errors, to minutes, greatly improving the efficiency of environment construction. Second, it achieves deep integration of topology and configuration, providing a WYSIWYG (What You See Is What You Get) experience. The connections seen by the user on the topology diagram are the actual network configuration generated by the system backend; the network topology diagram is the true configuration view. This greatly reduces the difficulty of network operation and maintenance and troubleshooting. When a network failure occurs, maintenance personnel can directly trace data links on the topology diagram to quickly locate the problem node. Third, through a standardized shadow component design, various heterogeneous physical devices are uniformly encapsulated at the logical level, achieving universal compatibility and plug-and-play functionality for various physical devices. The system does not require customized driver development for specific devices, improving system compatibility and access efficiency. Fourth, the combination of VLAN and VXLAN enables the simulation of large-scale, highly complex network scenarios, expanding the application scope of the technology. Finally, by shielding the complex underlying technical details and providing a simplified user interaction process, this application significantly lowers the barrier to entry for advanced network range technologies. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a general architecture diagram of a virtual-real combined target range simulation environment construction system provided in an embodiment of the present invention.

[0033] Figure 2 This is a technical architecture diagram of a virtual-real combined target range simulation environment construction system provided in an embodiment of the present invention.

[0034] Figure 3 This is an overall business process diagram for constructing a virtual-real combined target range, provided as an embodiment of the present invention.

[0035] Figure 4 This is a schematic diagram of a virtual-real combined network data plane forwarding logic provided in an embodiment of the present invention.

[0036] Figure 5 This is a flowchart illustrating a method for constructing a virtual-real combined network target range simulation environment, as provided in an embodiment of the present invention.

[0037] Figure 6 The diagram below shows the functional modules of a virtual-real combined network target range simulation environment construction system, which is provided in another embodiment of the present invention. Detailed Implementation

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

[0039] It should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0040] Example 1

[0041] This embodiment provides a system architecture and business process for constructing a virtual-real combined network target range simulation environment.

[0042] Please see Figure 1 This illustrates the overall system architecture of an embodiment of the present invention. The architecture adopts a layered design, consisting of an infrastructure layer, a resource management layer, a functional service layer, and an application interface layer from bottom to top.

[0043] The infrastructure layer forms the physical foundation of the entire system, providing hardware resource support. Specifically, this layer includes x86 or ARM architecture physical server clusters for providing computing power; distributed storage devices (such as Ceph cluster-based storage systems) for providing data storage capacity; and core switches, routers, and other network devices for providing physical network connectivity. A key feature of this invention is its ability to uniformly manage and schedule heterogeneous hardware resources.

[0044] The resource management layer, built on top of the infrastructure layer, is responsible for virtualizing and pooling physical hardware resources to achieve dynamic allocation and scheduling. Specifically, the virtualization service system (e.g., based on KVM technology) abstracts the computing resources of physical servers into virtual CPUs and memory resources. The storage resource pool integrates the physical disk space of distributed storage devices into a unified storage pool. The network resource pool abstracts physical network devices. Optionally, a Software-Defined Networking (SDN) controller can be used to uniformly manage network policies, enabling flexible scheduling of physical and virtual network resources.

[0045] The functional service layer is the core business logic layer of the system, providing the core functions for range construction and management. This layer mainly includes three modules: the range management platform, the virtual-physical networking system, and the monitoring and auditing module.

[0046] The range management platform is responsible for the full lifecycle management of range resources, including virtual machine image management, virtual machine / container creation and configuration, physical device access and information management, user access control and other functions.

[0047] The monitoring and auditing module is responsible for monitoring the system's performance metrics (such as CPU, memory, and network traffic) in real time, and recording user operation logs and system security audit information to ensure the stable and secure operation of the system.

[0048] The virtual-physical networking system is key to achieving virtual-physical integration in this invention. Its core function is to allow users to define a hybrid network topology containing virtual and physical nodes through a graphical interface, and automatically instantiate this topology into a real, communicable network environment. This module is responsible for handling all the complex configurations related to virtual-physical network connectivity and is the main carrier of the technical solution of this invention.

[0049] The application interface layer serves as the interface through which the system interacts with users or third-party systems. It provides a web interface, allowing users to perform visual drag-and-drop topology design, scene management, and other operations via a browser. Simultaneously, it offers standardized APIs (Application Programming Interfaces), supporting seamless integration and secondary development with third-party systems such as teaching management platforms and research data platforms, thereby empowering a broader application ecosystem. Users or third-party systems interact with the system through this layer.

[0050] Please see Figure 2 This paper demonstrates the microservice architecture of an embodiment of the present invention. All user requests, whether from a web interface or via API calls, first reach the API gateway. As the unified entry point of the system, the API gateway routes requests to the corresponding backend microservices based on the request type (e.g., image management request or network topology configuration request). Specifically, requests related to range resource management are distributed to the range management platform microservice, while requests related to network construction are distributed to the virtual-physical networking system microservice. These upper-layer services perform the final operations on computing, storage, and network resources by calling the underlying virtualization service system. For example, creating a virtual machine requires calling the virtualization service system's interface, while configuring a network may require communication with an SDN controller or directly with physical network devices. This microservice architecture ensures high availability, scalability, and high performance of the system.

[0051] Please see Figure 3 This is a general business process diagram of an embodiment of the present invention. The entire process can be divided into four main stages: component preparation, topology drawing, scene instantiation, and scene operation and management.

[0052] Phase 1: Component Preparation. This is the foundation for building the testbed. Components can come from standardized virtual components built into the system (such as virtual machine templates pre-installed with different operating systems, routers, firewalls, etc.) or user-defined components. Users can create new virtual machine templates by uploading ISO image files or importing virtual disk files of various formats. A key step is to standardize and encapsulate all components, forming component templates that include component metadata (such as type, recommended configuration, number of interfaces, etc.) and a read-only base image, facilitating unified drag-and-drop and invocation during the topology drawing phase. For physical devices that need to be connected, users need to enter their information in the component management module, and the system will generate an "abstract shadow component" for them, which represents the physical device on the topology diagram.

[0053] Phase Two: Topology Drawing. Users create network nodes in the visual topology editor by dragging and dropping components (including virtual components and shadow components of physical devices) from the component library onto the canvas. Then, they define network connections by connecting the nodes. During the connection process, users can specify the network ports to connect and configure network parameters such as IP addresses and DHCP services. After drawing, the entire topology diagram and its configuration information are saved as a JSON-formatted topology data file. This JSON file provides a complete and structured description of the target environment the user intends to build.

[0054] Phase Three: Scenario Instantiation. This is a crucial step from design diagram to physical entity. The user selects a saved JSON topology data and clicks the "Instantiate" button. The virtual-physical networking system in the system backend parses this JSON file. The parsing process is parallel: on the one hand, the system efficiently clones virtual machines and container instances from the base image through the CoW (CoW) mechanism; on the other hand, which is the core of this invention, the system performs automated network configuration injection in parallel. This includes a series of operations mentioned in the preceding claims, such as configuring VLANs on physical switches, configuring Linux bridges on virtualized host machines, and configuring VLAN and VXLAN bridging tunnels on software routers. After all network configurations are completed, a simulation test environment that is completely consistent with the topology diagram, with network isolation between virtual and physical nodes and the ability to communicate with each other, is generated.

[0055] Phase Four: Scenario Operation and Management. After successful scenario instantiation, users can perform various operations on the test range, such as powering on, powering off, destroying, and taking snapshots. The system supports parallel operation of multiple scenarios without interference. During operation, maintenance personnel can monitor the scenario's running status and resource usage in real time. After the exercise or test is completed, users can choose to destroy the instance to release resources or retain the base image for future reuse.

[0056] Example 2

[0057] This embodiment elaborates in detail the core technologies of the virtual-real combined network range simulation environment construction method described in Embodiment 1, especially the forwarding logic of the data plane and the process of achieving automated configuration.

[0058] Please see Figure 4 This figure details the end-to-end forwarding path of a data packet from a virtual node (VM) to a physical node (Physical Device) in the virtual-physical network environment constructed by this invention. This is key to understanding the working principle of the data plane of this invention.

[0059] The entire environment can be divided into two domains: the upper virtualization domain and the lower physical domain. The virtualization domain runs on one or more virtualization hosts, while the physical domain consists of physical switches and various connected physical devices.

[0060] Inside the virtualization host, user virtual machines (VMs) or containers run. To achieve large-scale scaling and isolation of the virtual network, VMs are connected to a specific VXLAN network via a virtual switch (vSwitch). For example, the VM in the diagram is assigned to the VXLAN 10001 network. The data packets sent by this VM are destined for a physical device within the same network address space.

[0061] The data packet transmission process is as follows:

[0062] 1-2. From VM to VXLAN Tunnel: The raw Ethernet frame sent by the VM is first received by the vSwitch on the virtualization host. The vSwitch, according to its configuration, encapsulates this raw frame with VXLAN, adding a VXLAN header (containing VNI=10001) and external IP and UDP headers. The encapsulated packet is then sent to the designated VXLAN tunnel endpoint (VTEP). In this invention, this VTEP is the VXLAN interface (e.g., vxlan10001) on the software router (Vyos).

[0063] 3. VXLAN Decapsulation and Bridge Forwarding: The encapsulated data packet arrives at the vxlan10001 interface of the software router Vyos. Vyos, acting as a VTEP, decapsulates the data packet, stripping away the external IP / UDP header and VXLAN header to restore the original Ethernet frame sent by the VM. This original frame is then sent to a crucial logical component—the software bridge, referred to as br0.

[0064] 4. Key to the Tunnel: Forwarding within the Bridge and VLAN Tagging in the Hypervisor: The software bridge br0 is the core of achieving seamless virtual-physical connectivity. It bridges two key interfaces: one is the vxlan10001 interface facing the virtual network, and the other is the physical interface eth0 directly facing the virtualized host. According to the bridge's operating principle, the raw Ethernet frame obtained after decapsulation from the vxlan10001 interface is directly forwarded by br0 to the eth0 interface. When this untagged raw Ethernet frame is sent from the eth0 interface, it does not leave the virtual machine. It first arrives at the first software bridge (e.g., vmbr1) on the virtualized host. Based on the system's pre-configured automation, the vmbr1 bridge has already configured a VLAN ID (e.g., 100) for this virtual port connecting the Vyos virtual machine. Therefore, the vmbr1 bridge automatically adds an 802.1Q header to this data frame, marking the VLAN ID as 100. This data frame with the VLAN tag is then sent out from the host's physical network interface card (such as eno2np1) via the host machine bridged by vmbr1.

[0065] 5. Physical Switch Forwarding: A data frame tagged with VLAN 100 arrives at the physical switch. Based on its VLAN configuration table, the physical switch forwards this data frame only to all ports belonging to VLAN 100. Because the system has automatically configured the ports connecting to physical devices as access ports for VLAN 100, the data frame is accurately delivered to the target physical device.

[0066] Data packets returned from the physical device to the virtual machine are transmitted along the reverse path, making the process completely symmetrical. Through this "VXLAN-to-Bridge-to-VLAN" mechanism, this invention cleverly utilizes software routers and software bridges to construct a transparent Layer 2 tunnel, achieving seamless bridging between the VXLAN virtual network and the VLAN physical network. This allows devices at both ends to be unaware of whether the other is virtual or physical, as if they are under the same switch.

[0067] Please see Figure 5 The figure is a detailed flowchart of the method of the present invention. Step S501: Receive user-defined network range topology information. The network range topology information includes at least one virtual node, at least one abstract shadow component of a physical node, and the connection relationship between the virtual node and the physical node.

[0068] Users operate the system through a graphical topology editor on the system's web front end. Users can drag and drop virtual nodes (such as pre-installed Ubuntu VMs, Windows VMs, and virtual routers like VioS) and registered physical device shadow components (such as "PLC-01" and "Firewall-FW1000") from the component library on the left onto the central canvas. Then, users use the connection tool to establish connections between the virtual or physical network ports of these nodes. During connection establishment, the system may display a dialog box allowing users to configure static IPs or choose to have them dynamically assigned by a DHCP server within the scenario. All these operations are parsed in real-time by the front end and constructed into a structured JSON object. When the user clicks "Save" or "Installate," this JSON object is sent as topology information to the system back end.

[0069] Step S502: parse the connection relationship and trigger the linkage configuration.

[0070] After receiving the JSON topology information, the system's backend network configuration engine begins parsing it. It iterates through the "nodes" and "edges" lists in the JSON. For each "edge," it identifies the source and destination nodes of the connection. If the "from" end of a connection is a virtual node, and the "to" end is a shadow component of a physical node, the engine recognizes this as a virtual-physical connection requirement and extracts relevant parameters, such as the VXLAN network ID the virtual node connects to, the physical switch IP address and port number the physical device connects to, and the VLAN ID assigned to this connection. These parameters serve as input, triggering subsequent automated configuration processes.

[0071] Step S503: Automatically configure the physical switch. Specifically, this includes configuring the physical port connected to the physical node in access mode on the physical switch used to connect the physical node, and binding it with a first network isolation identifier.

[0072] The network configuration engine logs into the target physical switch using the parsed parameters and a preset connection protocol (such as SSH or NETCONF). It executes a series of commands to configure the specified physical ports. For example, if the physical device "PLC-01" is connected to the GigabitEthernet1 / 0 / 1 port of the switch and has been assigned VLAN 100, the configuration engine will automatically execute the following command sequence:

[0073] configure terminal

[0074] vlan 100

[0075] name auto-scene-vlan-100

[0076] interface GigabitEthernet1 / 0 / 1

[0077] switchport mode access

[0078] switchport access vlan 100

[0079] end

[0080] write memory

[0081] In this way, the physical device is isolated in VLAN 100.

[0082] Step S504: Automatically configure the virtualization host network.

[0083] At the same time, the network configuration engine sends configuration commands to the virtualized host machine that hosts the relevant virtual nodes.

[0084] First, ensure that the underlying primary software bridge (e.g., vmbr1) exists and is configured correctly. This bridge needs to bridge the host machine's physical network port and be set to VLAN-aware mode to allow tagged traffic from multiple VLANs to pass through.

[0085] brctl addbr vmbr1

[0086] ip link set vmbr1 up

[0087] brctl addif vmbr1 eno2np1

[0088] ip link set vmbr1 type bridge vlan_filtering 1

[0089] Next, configure the network interface for the virtual machine running the software router (Vyos) on this host machine. One of the virtual network adapters of this virtual machine needs to be connected to vmbr1.

[0090] Step S505: Automatically configure the software router.

[0091] After the Viyos virtual machine starts, the network configuration engine configures Viyos through API or script injection, which is the key to building tunnels.

[0092] 1. Confirm physical interface connection:

[0093] In this step, the system does not need to create VLAN sub-interfaces within Viyos. The core task of the configuration engine is to ensure that the Viyos virtual network interface eth0 is correctly connected to the host machine's vmbr1 bridge, and that vmbr1 has assigned the correct VLAN ID (e.g., 100) to the connection according to the configuration in step S504. VLAN tagging / untagging operations are handled by the host machine's network stack.

[0094] 2. Create a VXLAN tunnel interface:

[0095] This step remains unchanged; the configuration engine creates a VXLAN interface within Viyos.

[0096] set interfaces vxlan vxlan10001 remote-port '4789'

[0097] set interfaces vxlan vxlan10001 vni '10001'

[0098] Set interfaces vxlan vxlan10001 source-address 'host IP'

[0099] Set interfaces vxlan vxlan10001 multicast-group '239.1.1.1' (or configure to unicast mode)

[0100] 3. Create and configure the core software bridge:

[0101] This is the core of achieving tunnel connection. The configuration engine will create a new bridge interface, such as br0, within Viyos.

[0102] set interfaces bridge br0

[0103] Subsequently, the Viyos physical interface eth0 and the VXLAN interface vxlan10001 created in the previous step are simultaneously bridged to br0.

[0104] set interfaces bridge br0 member interface ethernet eth0

[0105] set interfaces bridge br0 member interface vxlan vxlan10001

[0106] At this point, the transparent data forwarding tunnel is completed. Decapsulated traffic from vxlan10001 will be forwarded directly to eth0 via br0 and then marked with a VLAN ID at the host level; the reverse is also true.

[0107] Step S506: Complete instantiation and verify communication.

[0108] After all network configurations are complete, the system starts all virtual machines and containers defined in the topology. If DHCP service is configured, the software router (or another DHCP server within the scenario) will assign IP addresses from the same subnet to both virtual and physical nodes. Finally, users can directly access the IP addresses of physical devices from virtual nodes using the ping command or other network tools to verify that the entire hybrid virtual-physical environment has been successfully built and the network is functioning correctly.

[0109] Please see Figure 6This figure illustrates the system functional module block diagram of the present invention. The system 600 can be implemented as a standalone server or as a functional module of a cloud platform. The system includes: a topology information receiving module 600, used to receive user-constructed JSON-formatted topologies via a Web or API interface; a network configuration engine 610, serving as the core controller of the system, responsible for parsing the topology, generating configuration commands, and scheduling other modules; a physical network configuration unit 620, which has built-in drivers for interacting with various mainstream switches (such as Cisco, H3C, and Huawei), responsible for executing physical network configuration; a virtual network configuration unit 630, which interfaces with the APIs of virtualization platforms (such as Proxmox VE and OpenStack), responsible for the lifecycle management of virtual network components; and a tunnel construction module 640, which implements core functions and is specifically responsible for creating and managing VLAN-VXLAN bridging tunnels in the software router. Additionally, the system optionally includes a component management module 650 for managing virtual component templates and shadow components of physical devices; and a network address management module 660 for automatically planning and allocating IP addresses (IPAM) during scenario instantiation. These modules work together to implement the method described in this invention.

[0110] Example 3

[0111] This embodiment describes a specific application scenario of the present invention: its application in security attack and defense drills for industrial control systems (ICS).

[0112] A power company needs to set up a training range to test the defense capabilities and emergency response strategies of its substation monitoring system in the face of cyberattacks. This scenario needs to include real substation monitoring equipment (such as Siemens PLCs) and virtual attacker networks and dispatch center networks.

[0113] Using the construction process of this invention:

[0114] 1. Component preparation:

[0115] Physical Equipment Registration: Maintenance personnel connect a Siemens S7-300 PLC to the core physical switch at the test range (e.g., port g1 / 0 / 5) and enter the PLC's information using the "Physical Equipment Management" function on the system platform of this invention. The information includes: device name "Substation Main PLC," model "S7-300," and the switch port g1 / 0 / 5 to which it is connected. The system generates a shadow component named "Substation Main PLC" for this purpose.

[0116] Virtual component preparation: The system has built-in virtual machine templates for Kali Linux (as the attacker's host), Windows Server 2019 (as the dispatch center server), and Vyos (as the scenario router).

[0117] 2. Topology drawing:

[0118] The organizer of the security drill logs into the system and creates a new scenario called "Substation Attack and Defense Drill".

[0119] In the topology editor, he dragged it in from the component library:

[0120] A Kali Linux virtual machine named "Attacker".

[0121] A Windows Server virtual machine named "Dispatch Center".

[0122] A Vyos virtual router serves as the gateway and core routing device for the entire scenario.

[0123] The registered "Substation Main PLC" shadow component.

[0124] Define network connection:

[0125] Connect the “attacker” to a virtual network segment (for example, the system automatically assigns it VXLAN 1001).

[0126] Connect the "Dispatch Center" to another virtual network segment (e.g., VXLAN 1002).

[0127] Connect the shadow component of the "Substation Main PLC" to the eth1 port of the Viyos router.

[0128] Connect the eth2 port of the Viyos router to the virtual network segment where the "attacker" is located.

[0129] Connect the eth3 port of the Viyos router to the virtual network segment where the "Dispatch Center" is located.

[0130] 3. Scene instantiation:

[0131] The organizer clicks the "One-Click Instantiation" button.

[0132] The system will execute automatically in the background:

[0133] Analysis: The system detected that the shadow component of "Substation Main PLC" is connected to the eth1 port of Vios.

[0134] Physical switch configuration: The system logs into the core switch and automatically configures port g1 / 0 / 5 to access mode and assigns it an unused VLAN, such as VLAN 200.

[0135] Vyos and host machine configuration:

[0136] On the host machine hosting the Voyos virtual machine, the system ensures that the virtual network card (corresponding to eth1 in Voyos) connected to the PLC side is bridged to the VLAN-aware Linux Bridge (vmbr1), and specifies VLAN 200 for this connection at the host level.

[0137] Within Viyos, the system automatically creates VXLAN interfaces vxlan1001 and vxlan1002.

[0138] The system creates a software bridge br_plc_tunnel and directly bridges the physical interface eth1 and the VXLAN interface corresponding to the virtual network where the PLC is located (assuming the PLC and the dispatch center are in the same network segment, i.e., vxlan1002).

[0139] Vyos also functions as a router, providing routing and DHCP services to both the attacker's network (192.168.10.0 / 24) and the dispatch center / PLC network (192.168.20.0 / 24).

[0140] Virtual machine creation: The system clones virtual machine instances of Kali and Windows Server in parallel.

[0141] 4. Drill Execution:

[0142] Once the scene is instantiated (approximately 3-5 minutes), the exercise begins.

[0143] Blue team members can log in to the "Dispatch Center" server via remote desktop and use industrial control host computer software to access and monitor the status of physical PLCs normally through IP address 192.168.20.50 (assigned by DHCP).

[0144] Red team members log into the "attacker's" virtual machine (IP 192.168.10.100). They can attempt to attack the real PLC located at 192.168.20.50 by bypassing the virtual router through network scanning, vulnerability exploitation, and other means.

[0145] Since the PLC is real hardware, the red team can try to exploit attack vectors that cannot be simulated in a purely virtual environment, such as firmware vulnerabilities and physical port protocol vulnerabilities.

[0146] The blue team can then test the effectiveness of its security policies on real PLC devices and virtual servers.

[0147] This invention simplifies the complex task of building a virtual-physical integrated environment, which originally required several days of collaboration between network engineers, virtualization engineers, and industrial control engineers, into a drag-and-drop operation by a security expert in a few minutes, greatly improving the efficiency and realism of the exercise.

[0148] Example 4

[0149] This embodiment will be combined with the appendix Figure 6 This paper elaborates in detail on the specific implementation method and internal functional modules of the virtual-real combined network target range simulation environment construction system provided by the present invention.

[0150] Please see Figure 6 The present invention provides a virtual-physical combined network range simulation environment construction system, which logically may include: a topology information receiving module 600, a network configuration engine 610, a physical network configuration unit 620, a virtual network configuration unit 630, a tunnel construction module 640, and optional component management module 650 and network address management module 660.

[0151] First, to enable users to conveniently use physical devices through a graphical interface, much like virtual components, this system optionally provides a component management module 650. This module's function is to digitize and standardize physical devices. Specifically, system administrators input information about the physical devices that need to be connected to the test range through the interface provided by this module. This information includes at least: a unique name assigned to the device (e.g., "Core Firewall A"), the device type (e.g., "Firewall," "PLC"), and the management IP address and specific physical port number of the physical switch to which the device is connected (e.g., G1 / 0 / 8 port of switch 10.0.0.1). After receiving this information, the component management module 650 creates a standardized data structure in the background, namely an "abstract shadow component." This data structure stores all the key metadata of the physical device in JSON or other formats and generates a unique ID for it. This shadow component is then loaded into the component library of the graphical topology editing interface and displayed to the user as a visual icon. In this way, a specific piece of hardware in the physical world is logically abstracted into a standardized, draggable software object, laying the foundation for subsequent automated configuration.

[0152] When a user builds a target range, the first thing they interact with is the topology information receiving module 600. This module, typically part of the system's web front-end, provides a graphical topology editing interface. On this interface, users can drag and drop physical device shadow components generated by the component management module 650, as well as various pre-built virtual nodes (such as virtual machines and container templates), onto the canvas. Users define the connections between nodes through connection operations. The topology information receiving module 600 converts these graphical operations into a structured network target range topology in real time. Preferably, this information is organized in JSON format, clearly recording the type, ID, configuration parameters of each node, and the connection relationships (edges) between nodes. Each connection relationship clearly identifies the source node, the target node, and the ports they use. When the user completes the design and triggers scenario instantiation, this JSON-formatted topology information is submitted to the system's backend.

[0153] The network configuration engine 610 receives JSON topology information from the topology information receiving module 600 and performs deep parsing. The core task of this engine is to traverse all connections within the topology information. When it identifies an abstract shadow component where both ends of a connection are virtual nodes and physical nodes, it determines that this is a "virtual-physical connection" requirement. At this point, the engine extracts all necessary parameters from the topology information and the metadata of the shadow component, such as the physical switch IP and port to which the physical device is connected, the network isolation identifier assigned to the connection, and the IP of the virtualization host where the virtual node resides. Then, based on these parameters, the network configuration engine 610 generates a series of specific configuration instructions and distributes these instructions to the corresponding execution units.

[0154] The physical network configuration unit 620 is the execution module responsible for communicating with physical network devices. It connects to the network configuration engine 610 and receives instructions from the latter. Specifically, this unit has built-in drivers or adapters for different network device vendors (such as Cisco, Huawei, H3C, etc.) and can programmatically log in to a specified physical switch via protocols such as SSH, Telnet, or NETCONF. When it receives the engine's instruction to "configure VLAN 200 for port G1 / 0 / 8", the physical network configuration unit 620 translates it into a specific command-line interface (CLI) command or API call for the corresponding vendor's device and sends it to the physical switch for execution. Preferably, in this invention, the first network isolation identifier is specifically the Virtual Local Area Network (VLAN) ID. Therefore, the main responsibility of this unit is to configure the physical ports connected to the physical devices in Access mode and bind them to the VLAN ID assigned by the engine.

[0155] The virtual network configuration unit 630 is responsible for performing configuration tasks in the virtualization environment. It also receives instructions from the network configuration engine 610 and completes the creation and configuration of virtual network components by calling the API of the virtualization management platform (such as Proxmox VE, vSphere, OpenStack) or by directly executing commands on the KVM host via SSH. According to the present invention, its responsibilities include at least: deploying and starting a virtual machine instance (such as Vyos) of a software router on the virtualization host that hosts the virtual nodes; and configuring a first software bridge on the host. Preferably, the first software bridge is a Linux Bridge (e.g., named vmbr1) with VLAN awareness enabled, and the unit bridges one or more physical network ports of the host to this vmbr1 bridge as an uplink to the physical switch.

[0156] The tunnel construction module 640 typically works closely with the virtual network configuration unit 630, or as a subset of its advanced functionality. This module is specifically responsible for building transparent data forwarding tunnels connecting the virtual and physical domains within the software router. Its specific workflow is as follows:

[0157] First, according to the instructions of the network configuration engine, within the software router (Vyos), a corresponding second network isolation identifier interface is created for the VLAN ID (e.g., VLAN 200) used by the aforementioned physical network configuration unit 620. Specifically, this interface is a VLAN tag interface (e.g., eth1.200), which is attached to the virtual network interface card (eth1) that connects the software router to the first software bridge (vmbr1).

[0158] Second, also according to the instructions, a third network isolation identifier interface is created within the software router for the virtual network in the test range. Specifically, this virtual network uses Virtual Extensible Local Area Network (VXLAN) technology for isolation, and the third network isolation identifier is the VXLAN Network Identifier (VNI). Therefore, this interface is a VXLAN tunnel endpoint interface (e.g., vxlan10001).

[0159] Third, and most crucially, the tunnel building module 640 creates and configures a second software bridge (e.g., br_tunnel) within the software router. Then, it bridges both the newly created VLAN tag interface (eth1.200) and the VXLAN tunnel endpoint interface (vxlan10001) to this br_tunnel bridge. This operation directly connects the VLAN domain of the physical network and the VXLAN domain of the virtual network at the Layer 2 network level, allowing data packets to be seamlessly forwarded between them, thus successfully constructing a transparent data forwarding tunnel.

[0160] Finally, the system may optionally include a network address management module 660. This module is used to implement automated IP address management (IPAM). When the scenario is instantiated, the network configuration engine 610 can call this module to automatically assign IP addresses, subnet masks, and gateway addresses to all nodes in the topology (whether virtual or physical nodes) from a preset address pool. Preferably, this module configures the corresponding interface of the software router (e.g., the IP address of the br_tunnel interface) as the default gateway for that subnet and can enable DHCP service on the software router to provide dynamic address allocation for each node. This further enhances the automation of system deployment and avoids conflicts and errors that may result from manual IP address configuration.

[0161] In summary, the system of the present invention, through the close collaboration of the above modules, transforms the user's simple drag-and-drop operation on the graphical interface into a series of precise, automatic, and interconnected background configurations, ultimately achieving the rapid and reliable construction of a virtual-real combined target range environment.

[0162] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program can be transferred from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0163] Those skilled in the art will understand that the various numerical designations such as "first," "second," etc., used in this disclosure are merely for the convenience of description and are not intended to limit the scope of the embodiments of this disclosure, nor do they indicate the order of events.

[0164] At least one of the features described in this disclosure can also be described as one or more, and multiple features can be two, three, four or more, and this disclosure does not impose any limitations. In the embodiments of this disclosure, for a technical feature, the technical features in that technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", etc., and there is no sequential order or size order among the technical features described by "first", "second", "third", "A", "B", "C" and "D".

[0165] The correspondences shown in the tables of this disclosure can be configured or predefined. The values ​​of the information in each table are merely examples and can be configured to other values; this disclosure is not limiting. When configuring the correspondences between information and parameters, it is not necessarily required to configure all the correspondences shown in each table. For example, the correspondences shown in some rows of the tables in this disclosure may not be configured. Furthermore, appropriate modifications and adjustments can be made based on the above tables, such as splitting, merging, etc. The names of the parameters shown in the headers of the above tables can also use other names that the communication device can understand, and the values ​​or representations of the parameters can also use other values ​​or representations that the communication device can understand. In the implementation of the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables, etc.

[0166] The predefined terms in this disclosure can be understood as defined, pre-defined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned. Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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 disclosure.

[0167] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0168] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for constructing a virtual-real hybrid network target range simulation environment, characterized in that, include: Receive network range topology information defined by the user through a graphical topology editing interface. The network range topology information includes at least one virtual node, at least one abstract shadow component of a physical node, and the connection relationship between the virtual node and the physical node. The connection relationship is parsed, and the network parameter linkage configuration is automatically triggered based on the connection relationship. The linkage configuration includes: On the physical switch used to connect the physical node, the physical port connected to the physical node is configured in access mode and bound to a first network isolation identifier. On the virtualized host machine that carries the virtual node, a software router and a first software bridge are configured, and a second network isolation identifier interface corresponding to the first network isolation identifier is created in the software router; A third network isolation identifier interface is created within the software router. The third network isolation identifier is used to isolate the traffic of the virtual node within the virtualized network. as well as, Configure a second software bridge and bridge the second network isolation identifier interface and the third network isolation identifier interface to the second software bridge, thereby constructing a transparent data forwarding tunnel connecting the virtual node and the physical node, so that the virtual node and the physical node are in the same network address space and achieve seamless communication.

2. The method according to claim 1, characterized in that, The first network isolation identifier is a Virtual Local Area Network (VLAN) identifier, the second network isolation identifier interface is a VLAN tag interface, the third network isolation identifier is a Virtual Extensible Local Area Network (VXLAN) Network Identifier (VNI), and the third network isolation identifier interface is a VXLAN tunnel endpoint interface.

3. The method according to claim 2, characterized in that, Following the step of configuring the software router and the first software bridge on the virtualized host, the method further includes: A Linux bridge is created on the virtualized host machine as the first software bridge, and its VLAN awareness function is enabled. The physical network port of the virtualized host is bridged to the first software bridge, and the first software bridge is configured to allow data frames carrying the first network isolation identifier to pass through.

4. The method according to claim 1, characterized in that, The abstract shadow component of the entity node is a standardized data structure pre-generated based on the entity device port information entered by the user. The data structure includes the device type, physical port identifier, and the identifier of the port associated with it on the physical switch.

5. The method according to claim 1, characterized in that, The method further includes: Based on the network range topology information, network address information is automatically assigned or configured for the virtual node and the physical node. The network address information includes IP address, subnet mask and gateway address; wherein, the software router serves as the default gateway for the virtual node and the physical node.

6. A system for constructing a virtual-real hybrid network target range simulation environment, characterized in that, include: The topology information receiving module is used to receive network range topology information defined by the user through a graphical topology editing interface. The network range topology information includes at least one virtual node, at least one abstract shadow component of a physical node, and the connection relationship between the virtual node and the physical node. A network configuration engine is used to parse the connection relationship and automatically trigger the linked configuration of network parameters based on the connection relationship; A physical network configuration unit, connected to the network configuration engine, is used to configure the physical port connected to the physical node in access mode on the physical switch used to connect the physical node, and bind a first network isolation identifier to it. A virtual network configuration unit, connected to the network configuration engine, is used to configure a software router and a first software bridge on the virtualized host machine that hosts the virtual node; The tunnel building module is used for: Create a second network isolation identifier interface corresponding to the first network isolation identifier within the software router; A third network isolation identifier interface is created within the software router. The third network isolation identifier is used to isolate the traffic of the virtual node within the virtualized network. as well as Configure a second software bridge and bridge the second network isolation identifier interface and the third network isolation identifier interface to the second software bridge, thereby constructing a transparent data forwarding tunnel connecting the virtual node and the physical node, so that the virtual node and the physical node are in the same network address space and achieve seamless communication.

7. The system according to claim 6, characterized in that, The first network isolation identifier is a Virtual Local Area Network (VLAN) identifier, the second network isolation identifier interface is a VLAN tag interface, the third network isolation identifier is a Virtual Extensible Local Area Network (VXLAN) Network Identifier (VNI), and the third network isolation identifier interface is a VXLAN tunnel endpoint interface.

8. The system according to claim 7, characterized in that, The virtual network configuration unit is also used for: A Linux bridge is created on the virtualized host machine as the first software bridge, and its VLAN awareness function is enabled. The physical network port of the virtualized host is bridged to the first software bridge, and the first software bridge is configured to allow data frames carrying the first network isolation identifier to pass through.

9. The system according to claim 6, characterized in that, It also includes a component management module, which generates an abstract shadow component of the entity node based on the entity device port information entered by the user. The component has a standardized data structure, which includes the device type, physical port identifier, and the identifier of the port associated with it on the physical switch.

10. The system according to claim 6, characterized in that, The system also includes: The network address management module is used to automatically allocate or configure network address information for the virtual nodes and the physical nodes based on the network range topology information. The network address information includes IP address, subnet mask and gateway address; wherein the software router serves as the default gateway for the virtual nodes and the physical nodes.

Images