Message forwarding method and device based on network segment mapping, equipment, storage medium and program product
Patent Information
- Application Number
- CN202611110034.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-10-13
AI Technical Summary
[0019]上述基于网段映射的报文转发方法、装置、计算机设备、存储介质和计算机程序产品,演练请求报文进入宿主机命名空间后,以演练请求报文的目的IP地址进行宿主机命名空间中的路由决策;在演练请求报文的目的IP地址属于生产网段对应的伪装网段的情况下,通过宿主机命名空间中的路由决策,确定演练请求报文的下一跳指向传输隧道的隔离侧网卡绑定的IP地址;在演练请求报文的下一跳指向传输隧道的隔离侧网卡绑定的IP地址的情况下,通过传输隧道的与隔离侧网卡对应的宿主机侧网卡发出演练请求报文,使得演练请求报文经由传输隧道传输至隔离侧网卡,从而可以将演练请求报文送入隔离命名空间,演练请求报文进入隔离命名空间后,在演练请求报文的目的IP地址属于伪装网段的情况下,命中隔离命名空间中的网段还原映射规则,并根据网段还原映射规则,将演练请求报文中的目的IP地址的网络位替换为生产网段的网络位;以演练请求报文中的网络位替换后的目的IP地址进行隔离命名空间中的路由决策,确定通过生产网段对应的生产网卡发出演练请求报文,使得演练请求报文传输至网络位替换后的目的IP地址对应的演练虚拟机,保证可达性;这一过程中,演练虚拟机的对应生产网段的真实IP地址在隔离命名空间中被还原和路由,宿主机命名空间仅存在对应伪装网段的IP地址,避免演练虚拟机的对应生产网段的真实IP地址被暴露在生产网络中,实现演练虚拟机的隔离;而且在此过程中,在宿主机命名空间维护伪装网段这一条汇总路由指向传输隧道即可,无需将伪装网段绑定在宿主机命名空间中的网卡,避免对宿主机命名空间的IP配置造成过多污染。
Smart Images

Figure CN122909196A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data backup and disaster recovery drill technology, and in particular to a packet forwarding method, apparatus, computer equipment, storage medium and computer program product based on network segment mapping. Background Technology
[0002] Enterprise-level backup and disaster recovery systems generally require recovery drill / SureBackup capabilities. This involves realistically launching the backup virtual machine (hereinafter referred to as the drill virtual machine) in an isolated environment, and having automated scripts (Ping, SQL Check, HTTP health check, etc.) on the management end perform business-level verification of the drill virtual machine to prove the availability of the backup data. This places demands on the reachability of the drill virtual machine. During the drill, the drill virtual machine needs to retain the exact same IP configuration as the production environment (otherwise, the IP in the database and application configuration files will become invalid). To avoid IP conflicts with running production virtual machines and to prevent production service interruptions, the drill virtual machine must be isolated from the production network. Therefore, a solution that can balance the reachability and isolation of the drill virtual machine is urgently needed. Summary of the Invention
[0003] Therefore, it is necessary to provide a packet forwarding method, apparatus, computer equipment, storage medium, and computer program product based on network segment mapping to address the aforementioned technical problems.
[0004] This application provides a packet forwarding method based on network segment mapping, the method comprising:
[0005] After the exercise request message enters the host namespace, the routing decision in the host namespace is made using the destination IP address of the exercise request message;
[0006] If the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment, the next hop of the exercise request message is determined to be the IP address bound to the isolation side network card of the transmission tunnel through the routing decision in the host namespace;
[0007] When the next hop of the exercise request message points to the IP address bound to the isolated side network card of the transmission tunnel, the exercise request message is sent through the host side network card of the transmission tunnel corresponding to the isolated side network card, so that the exercise request message is transmitted to the isolated side network card via the transmission tunnel.
[0008] After the exercise request message enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request message belongs to the fake network segment, the network segment restoration mapping rule in the isolation namespace is matched, and the network bit of the destination IP address in the exercise request message is replaced with the network bit of the production network segment according to the network segment restoration mapping rule;
[0009] The routing decision in the isolated namespace is made using the destination IP address with the network bit replaced in the exercise request message, and it is determined that the exercise request message is sent through the production network card corresponding to the production network segment, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address with the network bit replaced; the exercise virtual machine runs in the isolated namespace.
[0010] This application provides a packet forwarding device based on network segment mapping, the device comprising:
[0011] The routing decision module is used to make routing decisions in the host namespace based on the destination IP address of the exercise request message after it enters the host namespace.
[0012] The IP address determination module is used to determine the IP address bound to the isolation side network card of the transmission tunnel by means of routing decisions in the host namespace when the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment.
[0013] The message sending and processing module is used to send the exercise request message through the host-side network card of the transmission tunnel corresponding to the isolated-side network card when the next hop of the exercise request message points to the IP address bound to the isolated-side network card of the transmission tunnel, so that the exercise request message is transmitted to the isolated-side network card via the transmission tunnel.
[0014] The network segment restoration module is used to, after the exercise request packet enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request packet belongs to the fake network segment, match the network segment restoration mapping rule in the isolation namespace, and replace the network part of the destination IP address in the exercise request packet with the network part of the production network segment according to the network segment restoration mapping rule;
[0015] The message sending processing module is further configured to perform routing decisions in the isolated namespace using the destination IP address after the network bit in the exercise request message is replaced, and determine to send the exercise request message through the production network card corresponding to the production network segment, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address after the network bit is replaced; the exercise virtual machine runs in the isolated namespace.
[0016] This application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.
[0017] This application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.
[0018] This application provides a computer program product having a computer program stored thereon, which, when executed by a processor, implements the above-described method.
[0019] The aforementioned packet forwarding method, apparatus, computer equipment, storage medium, and computer program product based on network segment mapping, after the exercise request packet enters the host namespace, performs routing decisions within the host namespace based on the destination IP address of the exercise request packet. If the destination IP address of the exercise request packet belongs to the masquerading network segment corresponding to the production network segment, the routing decisions within the host namespace determine the next hop of the exercise request packet to the IP address bound to the isolation-side network interface card (NIC) of the transmission tunnel. If the next hop of the exercise request packet also points to the IP address bound to the isolation-side NIC of the transmission tunnel, the host-side NIC corresponding to the isolation-side NIC of the transmission tunnel sends the exercise request packet, allowing it to be transmitted via the transmission tunnel to the isolation-side NIC. This enables the exercise request packet to enter the isolation namespace. After entering the isolation namespace, if the destination IP address of the exercise request packet belongs to the masquerading network segment, the network segment mapping within the isolation namespace is restored. The rules are applied, and based on the network segment restoration mapping rules, the network bits of the destination IP address in the exercise request message are replaced with the network bits of the production network segment. The routing decision in the isolation namespace is then made using the destination IP address with the replaced network bits, determining that the exercise request message is sent through the production network interface card corresponding to the production network segment. This ensures that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address with the replaced network bits, guaranteeing reachability. During this process, the real IP address of the corresponding production network segment of the exercise virtual machine is restored and routed in the isolation namespace. The host namespace only contains the IP address of the corresponding masquerading network segment, preventing the real IP address of the corresponding production network segment of the exercise virtual machine from being exposed in the production network, thus achieving isolation of the exercise virtual machine. Furthermore, in this process, only one summary route pointing to the transmission tunnel needs to be maintained in the host namespace for the masquerading network segment; there is no need to bind the masquerading network segment to the network interface card in the host namespace, avoiding excessive pollution of the IP configuration of the host namespace. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is a flowchart illustrating a packet forwarding method based on network segment mapping in one embodiment;
[0022] Figure 2 This is a schematic diagram of the access process from an external network to a training virtual machine in one embodiment;
[0023] Figure 3 This is a schematic diagram of an end-to-end request-response data flow processing in one embodiment;
[0024] Figure 4 This is a schematic diagram illustrating the process of building an isolated network masquerading environment from initialization to completion in one embodiment.
[0025] Figure 5 This is a schematic diagram of the modules related to network isolation and address masquerading in the host agent management service in one embodiment, and their calling relationships.
[0026] Figure 6 This is a structural block diagram of a packet forwarding device based on network segment mapping in one embodiment;
[0027] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0029] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the solutions, or any combination of multiple solutions.
[0030] The following introduces the technical terms:
[0031] 1. NETMAP: A stateless 1:1 network address mapping target module provided by Linux Netfilter, which maps one IP network segment to another network segment of the same size bit by bit, without relying on connection tracking.
[0032] 2. NAT (Network Address Translation): A general term for technologies that modify the source / destination IP address of an IP packet as it passes through a forwarding node.
[0033] 3. SNAT (Source NAT) / DNAT (Destination NAT): Modify the NAT subclass of the source IP and destination IP of the packet respectively.
[0034] 4. Conntrack (Connection Tracking): A connection table mechanism used by Linux Netfilter to maintain bidirectional NAT / stateful firewall rules; it is a stateful mechanism.
[0035] 5. Network Namespace: A network resource isolation mechanism provided by the Linux kernel. Each namespace has its own independent network interface card, routing table, Netfilter table, socket table, etc. This application uses NS to refer to the isolated namespace.
[0036] 6. VETH (Virtual Ethernet): A pair of virtual network interface cards provided by Linux, often used to connect different Network Namespaces.
[0037] 7. RFC 3927 Link-Local Address: Reserved address range 169.254.0.0 / 16, valid only on local links, routers do not forward by default, commonly used for auto-configuration and point-to-point tunnels.
[0038] 8. RFC 1918: Defines private network addresses 10.0.0.0 / 8, 172.16.0.0 / 12, and 192.168.0.0 / 16.
[0039] 9. PREROUTING / POSTROUTING: These are two hook points in Linux Netfilter, located before and after the routing decision, respectively. This application performs inbound address rewriting in PREROUTING and outbound address rewriting in POSTROUTING.
[0040] 10. VirtualLabs / Masquerade IP Addressing: The recovery drill isolation environment and its masquerading IP function provided in the backup product.
[0041] 11. DHCP (Dynamic Host Configuration Protocol): A protocol used to automatically assign IP addresses to hosts.
[0042] 12. dnsmasq: A commonly used lightweight open-source DNS / DHCP server.
[0043] 13. Drill VM: A virtual machine pulled from backup data during the backup and recovery drill process. It needs to be run in an isolated environment to verify the availability of the backup.
[0044] The packet forwarding method based on network segment mapping provided in this application may include: Figure 1 The steps are shown.
[0045] Step S101: After the exercise request message enters the host namespace, the routing decision in the host namespace is made using the destination IP address of the exercise request message.
[0046] Specifically, the host namespace (i.e., the default root network namespace, serving as an isolated runtime environment for the network protocol stack) internally hosts a dedicated network protocol stack instance independent of other namespaces. This network protocol stack includes at least a routing table, a neighbor subsystem (ARP cache and neighbor discovery cache), and the Netfilter filtering framework (i.e., a set of packet filtering and modification hooks in the kernel). There is a one-to-one correspondence between the network protocol stack and the host namespace: each network namespace has its own independent network protocol stack instance, and the protocol stacks in different namespaces are isolated from each other and do not interfere with each other.
[0047] When the exercise request message enters the host namespace, a route lookup operation is performed in the host namespace's routing table using the destination IP address carried in the exercise request message as the lookup key to make a routing decision. The exercise request message is a message sent by the test source, with its destination IP address pointing to a specific IP address within the masquerading network segment. The exercise request message is used to trigger reachability checks and service availability verification for the exercise virtual machine corresponding to that specific IP address in the isolated environment. The destination IP address in the exercise request message is a specific IP address within the aforementioned masquerading network segment. The masquerading network segment is a pre-specified virtual address pool that establishes a one-to-one correspondence with the real production network segment, and can be denoted as M / 24.
[0048] Beforehand, execute a routing configuration command within the host namespace (e.g., `ip route add M / 24 via NS_TIP`) to write a static route entry into the routing table of the host namespace. The destination network of this route entry is the masquerading network segment M / 24, corresponding to the real production network segment, and the next-hop address is the IP address bound to the isolated-side network interface card (NIC). The isolated-side NIC (can be denoted as `veth_ns`) is the NIC on the isolated side that forms the transmission tunnel between the host namespace and the isolated namespace. The IP address bound to this NIC can be denoted as `NS_TIP`, with an example of `NS_TIP` being 169.254.100.2. The NIC on the host side that forms the transmission tunnel is called the host-side NIC (can be denoted as `veth_host`), and the IP address bound to this NIC can be denoted as `HOST_TIP`, with an example of `HOST_TIP` being 169.254.100.1.
[0049] Step S102: If the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment, the next hop of the exercise request message is determined to be the IP address bound to the isolation side network card of the transmission tunnel through the routing decision in the host namespace.
[0050] Since the destination IP address in the exercise request message is a specific IP address within the aforementioned masquerading network segment, the destination IP address in the exercise request message belongs to the masquerading network segment. Through routing decisions in the host machine's namespace, the aforementioned pre-written routing entry can be hit, thereby determining that the next-hop address of the exercise request message is the IP address bound to the isolation side network card of the transmission tunnel (i.e., NS_TIP).
[0051] Step S103: If the next hop of the exercise request message points to the IP address bound to the isolated side network card of the transmission tunnel, the exercise request message is sent through the host side network card of the transmission tunnel corresponding to the isolated side network card, so that the exercise request message is transmitted to the isolated side network card through the transmission tunnel.
[0052] When the next hop of the exercise request message points to the IP address (i.e., NS_TIP) bound to the isolated side network card of the transmission tunnel, the exercise request message is sent through the host side network card corresponding to the isolated side network card of the transmission tunnel, so that the exercise request message is transmitted to the isolated side network card via the transmission tunnel.
[0053] Step S104: After the exercise request message enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request message belongs to the masquerading network segment, the network segment restoration mapping rule in the isolation namespace is hit, and the network bit of the destination IP address in the exercise request message is replaced with the network bit of the production network segment according to the network segment restoration mapping rule.
[0054] In the exercise request message, the host bits of the destination IP address remain unchanged.
[0055] By configuring the command `iptables -t nat -A PREROUTING -d M / 24 -j NETMAP --toR / 24` in advance, network segment restoration mapping rules can be written to the isolated namespace. The network segment restoration mapping rules are the inbound mapping rules in the NETMAP mapping policy engine, specifically the PREROUTING chain rules of the iptables nat table within the isolated namespace. This network segment restoration mapping rule indicates that when the destination IP address of a packet entering the isolated namespace falls within the address range of the masquerading network segment M / 24, this rule is triggered at the PREROUTING hook point. A 1:1 bitwise replacement operation is performed on the destination IP address—replacing the network bits (prefix) of the destination IP address from those of the masquerading network segment M / 24 with those of the production network segment R / 24, while the host bits (suffix) remain unchanged. This restores the destination IP address from the masquerading address to the corresponding real production address (e.g., replacing 192.168.119.100 with 192.168.88.100). This replacement operation does not rely on connection tracking entries, performs address restoration statelessly, and occurs before routing decisions within the isolated namespace. This allows the restored destination IP address to directly participate in subsequent route looks, ensuring that exercise request packets can be routed to the exercise virtual machine corresponding to the real production address.
[0056] When the exercise request message arrives at the isolated network interface card, it is delivered to the isolated network namespace. At this time, the source IP address and destination IP address carried in the exercise request message remain unchanged: the source IP address is still the real IP address of the test source, and the destination IP address is still the IP address within the masquerading network segment M / 24, meaning that no address translation processing has been performed.
[0057] After the exercise request message enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request message belongs to the masquerading network segment M / 24, the network segment restoration mapping rule written in the isolation namespace beforehand will be matched. According to the network segment restoration mapping rule, the destination IP address in the exercise request message can be mapped from the address in the masquerading network segment M / 24 to the corresponding address in the production real network segment R / 24, while the host bits remain unchanged. For example, 192.168.119.100 can be replaced with 192.168.88.100.
[0058] Step S105: Using the destination IP address with the network bit replaced in the exercise request message, a routing decision is made in the isolated namespace to determine that the exercise request message is sent through the production network card, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address with the network bit replaced; the exercise virtual machine runs in the isolated namespace.
[0059] The production network interface card (which can be denoted as eth1) corresponding to the production network segment is configured with the gateway IP address of the production network segment after being moved into the isolation namespace, such as 192.168.88.1 / 24. This network interface card serves as the exit interface connecting the isolation namespace and the virtual switch where the training virtual machine is located.
[0060] The destination IP address in the exercise request message, after the network bit is replaced, is, for example, 192.168.88.100 as mentioned above. This is used to perform a route lookup operation in the routing table of the isolated namespace. Specifically, when the production network interface eth1 is moved to the isolated namespace and configured with a gateway IP address (i.e., 192.168.88.1 / 24), the routing table in the isolated namespace can automatically generate a direct route entry corresponding to the production network segment (i.e., 192.168.88.0 / 24). This direct route entry (a route entry generated when the destination network is directly connected to the outgoing interface, and its next-hop address is the destination address itself, without needing to be forwarded through an intermediate gateway) uses the destination IP address after the network bit is replaced (i.e., 192.168.88.100 in the example above) as the lookup key to match the destination IP address in the routing table of the isolated namespace. Since the destination IP address 192.168.88.100 falls within the address range of the production network segment 192.168.88.0 / 24, and this production network segment is directly connected to the production network card eth1, the routing decision hits the directly connected route entry.
[0061] Based on the forwarding information indicated by the directly connected route entry, the routing decision determines that the exit point for the exercise request packet is the production network interface card (NIC) eth1. Then, according to this routing decision, the exercise request packet is sent from the production NIC eth1, and transmitted via the corresponding port group of the virtual switch (vSwitch, a Layer 2 forwarding device in the virtualization platform that connects the virtual network interface card of a virtual machine to the physical network) connected to the production NIC eth1, to the virtual network interface card of the exercise virtual machine with IP address 192.168.88.100. This establishes a forwarding path for the exercise request packet from the test source to the exercise virtual machine. Throughout the entire route lookup and forwarding process, the destination IP address of the exercise request packet is restored from the masqueraded network segment address to the production network segment address, allowing the exercise virtual machine to process the packet according to the standard protocol stack without being aware of any address translation or masquerading operations.
[0062] In the aforementioned packet forwarding method based on network segment mapping, after the exercise request packet enters the host namespace, routing decisions are made in the host namespace based on the destination IP address of the exercise request packet. If the destination IP address of the exercise request packet belongs to the masquerading network segment corresponding to the production network segment, the routing decisions in the host namespace determine that the next hop of the exercise request packet points to the IP address bound to the isolation-side network interface card (NIC) of the transmission tunnel. If the next hop of the exercise request packet points to the IP address bound to the isolation-side NIC of the transmission tunnel, the exercise request packet is sent through the host-side NIC corresponding to the isolation-side NIC of the transmission tunnel, allowing the exercise request packet to be transmitted to the isolation-side NIC via the transmission tunnel. This enables the exercise request packet to enter the isolation namespace. After the exercise request packet enters the isolation namespace, if the destination IP address of the exercise request packet belongs to the masquerading network segment, the network segment restoration mapping rule in the isolation namespace is matched, and the mapping is performed according to the network segment restoration mapping. The routing rules replace the network bits of the destination IP address in the exercise request message with the network bits of the production network segment. Using the destination IP address with the replaced network bits, routing decisions are made in the isolation namespace to determine that the exercise request message is sent through the production network interface card corresponding to the production network segment. This ensures that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address with the replaced network bits, guaranteeing reachability. During this process, the real IP address of the exercise virtual machine corresponding to the production network segment is restored and routed in the isolation namespace. The host namespace only contains the IP address of the corresponding masquerading network segment, preventing the real IP address of the exercise virtual machine corresponding to the production network segment from being exposed in the production network, thus achieving isolation of the exercise virtual machine. Furthermore, in this process, only one summary route pointing to the transmission tunnel needs to be maintained in the host namespace for the masquerading network segment; there is no need to bind the masquerading network segment to the network interface card in the host namespace, avoiding excessive pollution of the IP configuration in the host namespace.
[0063] In one exemplary embodiment, the method provided in this application further includes:
[0064] After the exercise response message sent by the exercise virtual machine to the exercise request message enters the isolation namespace, the routing decision in the isolation namespace is performed based on the destination IP address of the exercise response message to determine that the exercise response message needs to be sent through the isolation-side network interface card (NIC). If the exercise response message needs to be sent through the isolation-side NIC and the source IP address in the exercise response message belongs to the production network segment, the network segment masquerading mapping rule in the isolation namespace is matched, and the network bits of the source IP address in the exercise response message are replaced with the network bits of the masquerading network segment according to the network segment masquerading mapping rule. After the network bits are replaced, the exercise response message is sent through the isolation-side NIC, so that the exercise response message is transmitted through the transmission tunnel to the host-side NIC and then transmitted to the requester who sent the exercise request message.
[0065] Beforehand, the network segment masquerading mapping rules are written into the isolated namespace by configuring the command iptables -t nat -A POSTROUTING -o veth_ns -s R / 24 -jNETMAP --to M / 24. The network segment masquerading mapping rules are the outbound mapping rules in the NETMAP mapping policy engine, specifically the POSTROUTING chain rules of the iptables nat table in the isolated namespace. The network segment masquerading mapping rule is used to characterize the following: When the source IP address of a packet originating from the isolated namespace and exiting via the isolated network interface card veth_ns falls within the address range of the production network segment R / 24, this rule is triggered at the POSTROUTING hook point. A 1:1 bitwise replacement operation is performed on the source IP address; that is, the network bits of the source IP address are replaced from those of the production network segment R / 24 to those of the masquerading network segment M / 24, while the host bits remain unchanged. This maps the source IP address from its real IP address to the corresponding masquerading IP address (e.g., mapping 192.168.88.100 to 192.168.119.100). This replacement operation occurs before the exercise reply packet is sent via the isolated network interface card veth_ns. Furthermore, this operation is mathematically strictly symmetrical with the network segment restoration mapping rule (i.e., the PREROUTING chain rule): the network segment restoration mapping rule is an inbound rule used to map the destination address from the masquerading network segment M / 24 to the production network segment R / 24; the network segment masquerading mapping rule is an outbound rule used to reverse-map the source address from the production network segment R / 24 to the masquerading network segment M / 24. The network segment restoration mapping rule and the network segment masquerading mapping rule together constitute a complete bidirectional 1:1 address mapping function, thereby ensuring that the bidirectional communication between the test source and the training virtual machine is completely transparent at the IP address level, so that the source / destination IP addresses of the round-trip packets match each other, and communication can be completed correctly without relying on connection tracking entries; at the same time, the network segment masquerading mapping rule limits the condition `-o `veth_ns` strictly limits its scope to packets leaving the isolated namespace via the isolated network interface card `veth_ns`. For traffic communicating between virtual machines within the isolated namespace (whose exit point is the production network interface card `eth1` instead of `veth_ns`), the network segment masquerading mapping rule does not match, thus not affecting lateral communication between virtual machines within the isolated namespace. Furthermore, this replacement operation does not rely on connection tracking (conntrack) entries and completes address masquerading statelessly. Even if the conntrack module is disabled or its entries overflow, the rule can still complete the mapping bit by bit, avoiding state table resource consumption and performance bottlenecks. The zero-binding design with the host network interface card together ensures the lightweight and highly scalable nature of the entire address masquerading system.
[0066] After receiving the exercise request message, the exercise virtual machine can generate a corresponding exercise response message. The source IP address of the exercise response message is the real IP address of the exercise virtual machine in the production network segment, and the destination IP address is the real IP address of the test source.
[0067] Using the destination IP address of the exercise reply message (i.e., the real IP address of the test source) as the lookup key, a route lookup operation is performed in the routing table within the isolated namespace. Since the test source is located outside the isolated namespace and does not belong to any directly connected network segment within the isolated namespace, and the isolated namespace has a pre-configured default route as `defaultvia HOST_TIP` (HOST_TIP is the IP address bound to the host-side network interface card of the transmission tunnel, such as 169.254.100.1), the routing decision fails to find any non-default matching entries in the routing table of the isolated namespace, thus hitting the aforementioned default route entry `defaultvia HOST_TIP`. Based on the indication of this default route entry, the routing decision determines that the exit point of the exercise reply message is the isolated-side network interface card `veth_ns`, and the next-hop address is `HOST_TIP` (i.e., 169.254.100.1), thus determining that the exercise reply message must be sent through the isolated-side network interface card to return to the host namespace.
[0068] Before the routing decision is completed and the drill reply packet is about to be sent from the isolated network interface veth_ns, the drill reply packet is passed to the POSTROUTING hook point (i.e., the kernel hook point in the Netfilter framework located after the routing decision and before the packet is sent). Since the drill reply packet needs to be sent from the isolated network interface veth_ns and the source IP address in the drill reply packet belongs to the production network segment, the pre-configured network segment masquerading mapping rule can be triggered and hit at the POSTROUTING hook point. According to the network segment masquerading mapping rule, the network bits of the source IP address in the drill reply packet are replaced from the network bits of the production network segment R / 24 to the network bits of the masquerading network segment M / 24, while the host bits of the source IP address remain unchanged. This maps the source IP address of the drill reply packet from the real production address (e.g., 192.168.88.100) to the corresponding masquerading address (e.g., 192.168.119.100).
[0069] After the network bits of the source IP address are replaced, the exercise response message exits the POSTROUTING hook point and is sent out via the isolated network interface card veth_ns. The exercise response message is then transmitted through the transport tunnel to the host-side network interface card veth_host, thus entering the host namespace.
[0070] After the exercise response message enters the host namespace, a routing decision is performed using the destination IP address of the exercise response message (i.e., the real IP address of the test source) as the lookup key. The routing entry pointing to the network where the test source is located is matched, determining the exit point to the host's external ingress network interface eth0. The exercise response message is then sent to the test source via eth0. At this point, the source IP address of the exercise response message has been replaced with a spoofed address in the masquerading network segment M / 24, which is completely consistent with the destination IP address pointed to by the exercise request message sent by the test source. This allows the test source to correctly identify the exercise response message as a reply to its previously sent exercise request message based on the symmetric matching of IP addresses, completing a full end-to-end communication process. Throughout this process, no IP address in the masquerading network segment M / 24 is bound to any physical or virtual network interface in the host namespace, and no entries related to the masquerading network segment are generated in the host namespace's ARP cache and neighbor table, thus achieving zero pollution of the host namespace network.
[0071] In an exemplary embodiment, when the requester is an external device, the method provided in this application further includes: after the exercise response message enters the host namespace through the host-side network card, the exercise response message is sent through the host's external entry network card, so that the exercise response message is transmitted to the requester.
[0072] The requester (i.e., the aforementioned test source) can be an external device, which is a device located outside the host machine, and the IP address of the external device does not belong to the local area network where the host machine is located.
[0073] In this scenario, after the exercise reply message enters the host namespace through the host-side network interface card veth_host, a route lookup operation is performed in the routing table of the host namespace using the destination IP address of the exercise reply message (i.e., the real IP address of the external device) as the lookup key. Since the external device is located in a network outside the host machine, the routing decision hits the route entry pointing to the network where the external device is located, thus determining that the exit point of the exercise reply message is the host machine's external entry network interface card (i.e., the physical network interface card of the host machine connecting to the external physical network, denoted as eth0, which is configured with an IP address that can be reached by the external network route), and the next-hop address is the IP address of the external device.
[0074] Based on the routing decision within the host namespace, the exercise response message is sent via the external ingress network interface eth0, and transmitted to the requester (i.e., the external device) through the external physical network. At this point, the source IP address of the exercise response message has been replaced by a masquerading address in the masquerading network segment M / 24 within the isolated namespace (i.e., an IP address identical to the destination IP address pointed to by the exercise request message sent by the requester), and the destination IP address is the real IP address of the requester. This combination of source and destination IP addresses enables the requester to correctly match the exercise response message with the previously sent exercise request message, based on the IP address information in the five-tuple (source IP, source port, destination IP, destination port, protocol type), thus completing a full end-to-end request-response communication.
[0075] Throughout the process, standard Layer 3 IP forwarding operations (i.e., finding the interface based on the routing table and forwarding) are performed on the exercise response messages within the host namespace. No Network Address Translation (NAT) processing is required for the source or destination IP address of the exercise response messages, nor are any connection tracking entries established for the exercise response messages in the conntrack table of the host namespace. This further reduces the resource consumption of the host namespace network protocol stack and maintains the lightweight and purity of the host network protocol stack.
[0076] In one exemplary embodiment, the production network interface card (NIC) and the training virtual machine are connected via a port group; after the training request message is sent by the production NIC, it is transmitted to the training virtual machine via the port group.
[0077] A port group is a collection of logical ports defined on a virtual switch (vSwitch) in a virtualization platform. It is used for unified network policy management (including VLAN segmentation, traffic shaping, security policies, etc.) of multiple virtual network interface cards (NICs) connected to the same virtual switch. Logically, a port group is equivalent to a virtual Layer 2 broadcast domain. All virtual NICs connected to the same port group are in the same Layer 2 network and can communicate with each other via MAC addresses.
[0078] The production network interface card (NIC) eth1 is a virtual NIC device within the isolated namespace. It can be connected to the host machine via the hot-swappable mechanism of the virtualization platform and moved into the isolated namespace by system management commands (such as `ip link set dev eth1 netns NS`). This production NIC is configured with the gateway IP address of the production network segment (e.g., 192.168.88.1 / 24) within the isolated namespace. Essentially, it is a virtual Ethernet interface that connects to a port (i.e., a member port of a port group) of a virtual switch at the host machine's virtualization layer.
[0079] The virtual network interface card (NIC) of the training virtual machine (i.e., a virtual machine instance restored from backup data and running in an isolated environment) is also connected to the port group as a virtual port of the virtual switch. This virtual NIC is configured with a production IP address (e.g., 192.168.88.100 / 24) in the production network segment through the guest operating system inside the training virtual machine. No network configuration needs to be modified, and the IP configuration is completely consistent with that in the production environment.
[0080] The specific physical / virtual link connecting the production network interface card (eth1) and the training virtual machine via a port group is as follows: The production network interface card eth1 corresponds to a virtual switch port at the host virtualization layer, and this port is configured as a member of the port group; the virtual network interface card of the training virtual machine corresponds to another virtual switch port at the virtualization layer, and is also configured as a member of the same port group. The two are connected through the Layer 2 forwarding mechanism (based on MAC address learning and forwarding) within the virtual switch, without needing to go through an external physical network.
[0081] Based on this connection, when a drill request packet (whose destination IP address has been replaced by the network segment restoration mapping rules within the isolated namespace with an address in the real production network segment R / 24, such as 192.168.88.100) determines its exit point as the production network interface card (NIC) eth1 via routing decisions within the isolated namespace, the drill request packet is sent from NIC eth1 and enters the port group connected to NIC eth1 in the virtual switch. The virtual switch performs Layer 2 forwarding within the port group based on the destination MAC address of the drill request packet (obtained through ARP resolution, i.e., the MAC address of the drill virtual machine's virtual NIC), sending the drill request packet out from the corresponding virtual switch port connected to the drill virtual machine. This transparently transmits the drill request packet via the port group to the drill virtual machine's virtual NIC. The entire transmission process is completed within the Layer 2 domain of the virtual switch, without passing through any external physical network devices, ensuring effective isolation between drill traffic and the production network.
[0082] In one exemplary embodiment, the IP address bound to the isolated network interface card belongs to a network segment that does not conflict with the production network segment.
[0083] The IP address bound to the isolated network interface card (NS_TIP, example 169.254.100.2) and the IP address bound to the host network interface card (HOST_TIP, example 169.254.100.1) share the same network prefix; for example, both have the network prefix 169.254.0.0 / 16. The network prefixes of the IP addresses bound to the isolated and host network interface cards do not overlap or intersect with the production network segment (R / 24, example 192.168.88.0 / 24) or the masquerading network segment (M / 24, example 192.168.119.0 / 24).
[0084] To better understand the above method, the following details an application example of the packet forwarding method based on network segment mapping proposed in this application. The solution provided in this embodiment belongs to the fields of computer network communication, network virtualization, and data backup and disaster recovery. It can be used in data backup and recovery drills (disaster recovery drills) to implement a simulated network with Layer 2 isolation and Layer 3 interconnection by utilizing the Linux Network Namespace and iptables NETMAP modules.
[0085] Related technologies, such as Masquerade IP Addressing, can handle the masquerading and forwarding of an entire network segment on a dedicated proxy virtual machine. Each IP address in the masqueraded segment is configured with an alias address (IP Alias) on the proxy network card or bound to the entire network segment. Then, stateful NAT (SNAT / DNAT connection tracking table) or application layer proxy is used to complete the bidirectional traffic translation. A whole-segment mapping scheme based on stateful NAT (Netfilter conntrack) involves establishing a conntrack entry for each access connection on the border device, with conntrack maintaining the bidirectional translation relationship. A Layer 2 isolation scheme based on bridges / VLANs involves dividing the training environment into independent VLANs or private vSwitch on a virtual switch, with access only relayed through a dedicated proxy device.
[0086] The related technologies have the following drawbacks:
[0087] (1) High deployment cost and serious pollution of host resources: Usually, it is necessary to configure an alias address (IP Alias) for each IP in the masquerading network segment on the physical / virtual network card of the proxy host (or host machine), or bind the entire masquerading network segment to the host machine's network card. A / 24 network segment means a potential 254 IP configuration items. When the customer has multiple isolation jobs and multiple masquerading network segments, thousands of IP aliases will be stacked on the host machine's network card, which not only consumes a lot of kernel resources (each IP will trigger ARP broadcast reply and neighbor table entry management), but also pollutes the host machine's routing table and interferes with the host machine's own production business traffic.
[0088] (2) Stateful NAT is not suitable for connectionless protocols and has a connection tracking bottleneck: Traditional SNAT / DNAT relies on the Netfilter conntrack connection tracking table to maintain bidirectional translation relationships, which is essentially a connection-level mapping. For connectionless or one-way packets such as ICMP (Ping), UDP single-packet probing, and SNMP Trap, there are often cases where the return packets cannot be matched or are dropped due to timeout. At the same time, there is a hard constraint on the upper limit of the number of entries in the conntrack table. When the number of training virtual machines and concurrent connections increases, the conntrack table is very easy to overflow, causing access avalanche.
[0089] (3) Poor scalability and high operation and maintenance costs: For each new masquerading network segment, almost a set of NAT rules must be rebuilt and new IP bindings must be added. The expansion process is complicated and it is difficult to make a tunnel carry any network segment.
[0090] (4) It is difficult to balance isolation and interconnection: Although it is secure to adopt a two-layer isolation (VLAN / independent vSwitch), the management end cannot perform automated health checks on VMs; after interconnection, it is difficult to scale due to the aforementioned IP alias explosion problem.
[0091] The solution provided in this embodiment can achieve stateless, bidirectional, ICMP-friendly 1:1 transparent access from the external network to the entire production network segment in the isolation zone without polluting the host machine's network card IP configuration, and enable the mapping mechanism to be horizontally infinitely expanded.
[0092] This embodiment provides a NETMAP-based 1:1 stateless masquerading mapping scheme for the entire network segment. It completely decouples the traditional IP binding and NAT behavior located on the host network card. The host does not bind any IPs of the masquerading network segment, nor does it establish any conntrack NAT rules on the host side. Instead, it maintains a / 24 whole segment redirection route pointing to the isolated namespace in the host namespace (the next hop of the route is the RFC 3927 Link-Local tunnel address). The 1:1 mapping at the network segment level is completed by the iptables NETMAP module located in the isolated Network Namespace (i.e., the isolated namespace). It achieves arithmetic stateless address replacement (bitwise mapping, without relying on the conntrack connection table) for inbound "masquerading network segment → real network segment" and outbound "real network segment → masquerading network segment" through the PREROUTING+POSTROUTING bidirectional NETMAP rules.
[0093] This ensures zero IP pollution on the host network interface card (NIC), maintaining the same number of IP addresses regardless of the number of masquerading network segments mounted. Furthermore, since NETMAP is a stateless address rewriting protocol, it natively supports any IP protocol such as ICMP and UDP single packets, and return packets can be strictly restored according to symmetrical rules. Adding a masquerading network segment requires only "one route + two NETMAP rules," and all rules are pushed down into the isolated namespace, resulting in zero intrusion into the host machine and achieving the horizontal scaling capability of "one VETH tunnel carrying N masquerading network segments."
[0094] The solution provided in this embodiment can run on a virtualized host managed by backup agent software, and logically includes the following parts:
[0095] (1) Host Network Stack: Responsible for carrying backup proxy and external access traffic;
[0096] (2) Drill Namespace: An independent TCP / IP protocol stack instance built by Linux Network Namespace technology, used to accommodate the logical gateway interfaces corresponding to all the training VMs;
[0097] (3) VETH Pair Link-Local Tunnel (i.e., the transmission tunnel mentioned above): A pair of veth virtual Ethernet devices veth_host and veth_ns, with their ends placed in the host namespace and the isolated namespace respectively, and configured with RFC 3927 Link-Local addresses (169.254.100.1 / 24 and 169.254.100.2 / 24) respectively, serving as the only transmission channel between the host namespace and the isolated namespace;
[0098] (4) Production network card (Drill VM NIC): The virtual network card that is connected via VMware hot-plugging or other methods is moved into an isolated namespace and configured with the gateway IP address of the production network segment (such as 192.168.88.1 / 24). dnsmasq provides DHCP service so that the drill VM can obtain the production IP without modifying any configuration.
[0099] (5) NETMAP Mapping Engine: A collection of iptables rules located inside the isolated namespace, which implements a 1:1 bidirectional stateless mapping between the masquerading network segment and the real network segment.
[0100] The host namespace is directly connected to the isolated namespace's veth_ns via veth_host, forming the first link. The production network interface card (e.g., eth1) in the isolated namespace is connected to the training virtual machine via a vSwitch port group, forming the second link. The two links are logically linked within the isolated namespace through kernel IP forwarding and NETMAP rules. External user access traffic passes through the following sequence: external host → host eth0 → host routing table → veth_host → veth_ns → PREROUTING NETMAP in NS (inbound 1:1 rewrite) → routing table in NS → eth1 (production gateway) → training virtual machine.
[0101] The following describes the process of this solution, with the following settings: the real isolated production network segment is R / 24 (example 192.168.88.0 / 24), the user-specified masquerading network segment is M / 24 (example 192.168.119.0 / 24), the IP address bound to the host machine's network card is HOST_TIP (169.254.100.1), and the IP address bound to the isolated network card is NS_TIP (169.254.100.2).
[0102] Step S1: Infrastructure Initialization. Create an isolated namespace on the host machine, create the veth_host / veth_ns pair, configure the Link-Local tunnel IP, and move the isolated physical / virtual network interface eth1 from the host namespace into the isolated namespace. Configure the gateway IP address of the production network segment R / 24 (e.g., 192.168.88.1 / 24) on eth1, thus making eth1 a production network interface for the production network segment, with DHCP provided by dnsmasq. Enable net.ipv4.ip_forward=1 on both sides. Set the default route within the isolated namespace to "default via HOST_TIP". This step is performed once and remains unchanged during any subsequent additions or deletions of masquerading mappings.
[0103] Step S2: "Single Route Traffic Generation" on the Host Side. When a user requests to expose the masquerading network segment M / 24, execute the following configuration command in the host namespace: `ip route add M / 24 via NS_TIP`. This configuration command writes a corresponding route entry into the host namespace. The meaning of this route entry is: packets destined for the masquerading network segment M / 24 will be sent to the isolation namespace via veth_host with the next hop being NS_TIP. During this process, no IP address from the masquerading network segment M / 24 is bound to the host network interface card. The host is unaware of the mapping between M / 24 and R / 24, and the host protocol stack does not participate in any NAT translation or maintain any conntrack entries.
[0104] Step S3: Stateless rewriting of inbound PREROUTING NETMAP within the isolated namespace. Execute the following configuration command within the isolated namespace: `iptables -t nat -A PREROUTING -d M / 24 -j NETMAP --to R / 24`. This configuration command writes the corresponding network segment restoration mapping rules within the isolated namespace. The mathematical behavior of the NETMAP module is a bit-by-bit replacement: for any destination IP address m∈M / 24, its host bits remain unchanged, and the network bits are replaced with the network bits of the masquerading network segment R / 24, resulting in the corresponding r∈R / 24 (e.g., 192.168.119.100 → 192.168.88.100). This rewriting occurs at the PREROUTING hook point within the isolated namespace, i.e., before the routing decision. Therefore, subsequent route lookups use the real IP address r, and traffic naturally passes through eth1 (the gateway of R / 24) to reach the corresponding training virtual machine.
[0105] Step S4: Rewrite outbound POSTROUTING NETMAP symmetric return packets within the isolated namespace. Execute the following configuration command within the isolated namespace: `iptables -t nat -A POSTROUTING -o veth_ns -s R / 24 -jNETMAP --to M / 24`. This configuration command writes the corresponding network segment masquerading mapping rule within the isolated namespace. The key constraint for the network segment masquerading mapping rule is "-o veth_ns", ensuring that the rule applies to traffic leaving the isolated namespace via veth_ns (i.e., returning to the host machine), without affecting lateral communication between virtual machines within the isolated namespace. The network segment masquerading mapping rule replaces the network bits of the real production network segment R / 24 in the source IP address of the packet with the network bits of the masquerading network segment M / 24, ensuring that the source IP of the return packet received by the external initiator is completely consistent with the masquerading IP it initially accessed, thus correctly matching its local connection / session state.
[0106] Step S5: Bidirectional stateless symmetric mapping. The network segment restoration mapping rule in Step S3 and the network segment masquerading mapping rule in Step S4 together constitute a pair of mathematically strictly symmetric 1:1 functions f(m)=r and f^{-1}(r)=m. The mapping process is entirely determined by bitwise operations on the source / destination IP addresses and does not rely on conntrack connection tracking entries, therefore it naturally supports:
[0107] (a) ICMP Echo Request / Reply: Ping probe requests and responses can be strictly symmetrically reconstructed;
[0108] (b) UDP single-packet communication: connectionless messages such as DNS, SNMP Trap, and syslog;
[0109] (c) TCP connection: Three-way handshake, half-open connection, and long connection can all be forwarded correctly;
[0110] (d) Probing of non-IANA standard ports and unconventional protocol numbers (such as GRE, ESP).
[0111] Step S6: Horizontal Expansion (Multiple Masked Network Segments). If the user subsequently adds a new masked network segment M' / 24→R' / 24 (e.g., 10.0.99.0 / 24→10.0.0.0 / 24), there is no need to create new VETH pairs or configure any new IPs on the host network interface card. Simply repeat steps S2 to S4 to overlay new 1:1 network segment mappings on the same transmission tunnel. Theoretically, any number of network segment mappings can be carried within the same isolated namespace, with zero infrastructure changes during expansion.
[0112] This will be illustrated with a specific access example (end-to-end data flow):
[0113] Forward: External host X (IP=10.20.30.40) initiates a Ping request to the masquerading address 192.168.119.100.
[0114] ① The external host X makes a routing decision based on its own routing table and determines that the Ping request message destined for IP address 192.168.119.100 needs to be forwarded through the network to the host machine H where the backup agent is located.
[0115] ② After the host machine H receives the Ping request message (its source IP address is 10.20.30.40 and its destination IP address is 192.168.119.100), the network protocol stack in the host machine's namespace performs a route lookup operation in the routing table using the destination IP address of the message as the lookup key. The route lookup hits the pre-configured static route entry "M / 24 via NS_TIP". Based on this route entry, the network protocol stack sends the Ping request message through the host machine's network card veth_host to the IP address NS_TIP (i.e., 169.254.100.2) bound to the isolated network card.
[0116] ③ After the Ping request packet arrives at the isolated network interface veth_ns in the isolated namespace NS, it enters the PREROUTING hook point of the Netfilter framework in the isolated namespace. The destination IP address of the packet (192.168.119.100) falls within the address range of the masquerading network segment M / 24, and hits the pre-configured inbound NETMAP rule (-d M / 24 -j NETMAP --to R / 24). The PREROUTING hook point rewrites the destination IP address of the packet statelessly to the corresponding real production address 192.168.88.100 according to the rule.
[0117] ④ After the Ping request message with the destination address rewritten exits the PREROUTING hook point, the network protocol stack in the isolated namespace performs a route lookup operation in the routing table with the rewritten destination IP address (192.168.88.100). The route lookup hits the route entry directly connected to the production network card eth1. Based on this, the network protocol stack determines that the outgoing interface is the production network card eth1, and sends the Ping request message through eth1, which is then transmitted through the virtual switch port group to the training virtual machine with the destination IP address of 192.168.88.100.
[0118] Reverse: The virtual machine in the exercise returns a Ping response message (i.e., a reply packet) to the external host X.
[0119] ⑤ After receiving the Ping request message, the training virtual machine processes the message according to the standard TCP / IP protocol stack and generates a corresponding Ping response message. The source IP address of the response message is the production real address of the training virtual machine, 192.168.88.100, and the destination IP address is the real IP address of the external host X, 10.20.30.40. The response message returns to the production network interface eth1 in the isolated namespace via the virtual switch port group. The network protocol stack in the isolated namespace performs a route lookup operation in the routing table with the destination IP address (10.20.30.40). This route lookup hits the default route entry "default via HOST_TIP", determining that the exit point is the isolated network interface veth_ns. Before the response message is sent via veth_ns, the response message enters the POSTROUTING hook point. Its source IP address (192.168.88.100) falls within the address range of the production real network segment R / 24 and the outgoing interface is veth_ns. This hits the pre-configured outgoing NETMAP rule (-o veth_ns -s R / 24 -j NETMAP --to M / 24). According to this rule, the POSTROUTING hook point rewrites the source IP address of the response message statelessly to the corresponding masquerading address 192.168.119.100.
[0120] ⑥ The response message, after being rewritten from the source IP address, exits the POSTROUTING hook point and is sent by the network protocol stack in the isolated namespace via the isolated side network interface veth_ns. It is then transmitted to the host side network interface veth_host through the VETH Pair link local tunnel and enters the host namespace. The network protocol stack in the host namespace performs a route lookup operation in the routing table using the destination IP address (10.20.30.40) of the response message. It finds the route entry pointing to the network where the external host X is located, determines that the exit is the host physical network interface eth0, and sends the response message to the external host X via eth0.
[0121] Any physical or virtual network interface card in the host namespace only needs to hold its own real IP address, without needing to hold any IP address in the masquerading network segment M / 24 or the production network segment R / 24; the conntrack table entry in the host namespace does not allocate any entry for this data stream, thereby achieving "zero pollution and zero state" in the host namespace network.
[0122] like Figure 2 As shown, Figure 2This illustrates the access flow from the external network to the training virtual machine. Specifically, the requesting terminal in the external network (e.g., an administrator or automated test host) first initiates an access request, with its destination address pointing to a specific IP address within the masquerading network segment 192.168.119.0 / 24 (e.g., 192.168.119.100). This request packet is transmitted through the physical network to the physical network interface card (production network interface) of the physical host system. Then, according to the pre-configured static routing within the host namespace (i.e., `ip route add 192.168.119.0 / 24 via`), the request is routed to the physical network interface card (production network interface) of the physical host system. The server (IP address 169.254.100.2) performs route matching and determines that the packet needs to be sent into the transmission tunnel via the VETH tunnel endpoint (IP address 169.254.100.1) on the host side. The packet is then transmitted through the Link-Local transmission tunnel to the VETH tunnel peer (IP address 169.254.100.2) in the isolated namespace, thus entering the isolation zone. Subsequently, the packet arrives at the NETMAP address translation module (iptablesPREROUTING chain) in the isolated namespace, where the inbound NETMAP rules translate the packet into IP address 169.254.100.2. The destination IP address is restored bit-by-bit from the masquerading network segment 192.168.119.0 / 24 to the corresponding address (192.168.88.100) in the production real network segment 192.168.88.0 / 24. After routing decision, the packet is forwarded internally at Layer 2 via the virtual gateway (i.e., the production network card eth1, whose IP address is 192.168.88.1), and then transmitted to the destination training virtual machine (whose real IP address is 192.168.88.100) via the virtual switch port group in the virtualization resource pool, thus completing the entire access link.
[0123] like Figure 3 As shown, Figure 3This illustrates the end-to-end request-response data flow processing. Specifically, an external network initiates a request packet with a destination IP belonging to the masquerading network segment 192.168.119.x. After transmission through the physical network, the packet is received by the host machine. The host machine queries its namespace routing table, matches the pre-configured static redirection route, and forwards the request packet to the host machine within the VETH virtual tunnel. Once the packet enters the isolated namespace through the VETH tunnel, the iptables engine within the isolated namespace intercepts the packet at the PREROUTING hook point and executes the inbound NETMAP mapping rules, replacing the destination IP of the packet from the masquerading network segment 119.x with the corresponding address in the production network segment 88.x bit-by-bit. Subsequently, the virtual gateway (i.e., the production network interface card) performs Layer 2 forwarding based on the restored real destination IP, thus... The message is delivered to the isolated virtual machine; after receiving the request message, the isolated virtual machine generates a response message according to the standard protocol stack, with its source IP being an address in the production real network segment 192.168.88.x; the response message is returned to the virtual gateway, and after routing decision, it is sent to the VETH tunnel isolation end; before the response message is sent out through the VETH tunnel, the iptables engine intercepts the message at the POSTROUTING hook point, executes the outbound NETMAP mapping rule, and replaces the source IP from the production real network segment 88.x with the corresponding address in the masquerading network segment 119.x bit by bit; the response message returns to the host kernel protocol stack through the VETH tunnel, and is forwarded by the host machine according to normal Layer 3, returning to the requester in the external network via the physical network card, thus completing a complete bidirectional communication.
[0124] like Figure 4 As shown, Figure 4This demonstrates the process of building an isolated network masquerading environment from initialization. Specifically, after job initialization begins, an independent network namespace is created as the isolation namespace, and a pair of VETH virtual Ethernet devices are created, with interface names assigned to each end. Then, one end of the VETH device is retained in the host namespace, while the other end is moved to the isolation namespace, and RFCs are configured for each interface. The 3927 link local tunnel IP address is configured (e.g., 169.254.100.1 on the host machine and 169.254.100.2 on the isolated namespace). IP forwarding is enabled in both the host and isolated namespaces (net.ipv4.ip_forward=1), and a default route is configured in the isolated namespace pointing to the host machine's VETH interface IP. Next, the production network interface card (NIC) corresponding to the training virtual machine is moved into this isolated namespace, and a gateway IP address for the production network segment is configured on the NIC. The built-in DHCP service (dnsmasq) is started to automatically assign real IP addresses consistent with the production environment to the training virtual machines in the isolated namespace. Then, a static route rule pointing to the masquerading network segment is added to the host namespace, redirecting traffic destined for the masquerading network segment to the isolated namespace via the VETH tunnel. Finally, iptables is injected into the isolated namespace. With the NETMAP bidirectional conversion rules (including the incoming network segment restoration rules of the PREROUTING chain and the outgoing network segment masquerading rules of the POSTROUTING chain), the overall network isolation and masquerading environment is now complete and can be used for subsequent recovery drills.
[0125] like Figure 5 As shown, Figure 5This diagram illustrates the modules related to network isolation and address masquerading in the host agent management service and their call relationships. Specifically, the management service includes four core classes: NamespaceManager, NamespaceEntry, NatStrategy, and NetlinkExecutor. NamespaceManager, as the top-level management class, maintains a namespace dictionary and provides high-level interfaces such as creating and destroying isolated environments and issuing NETMAP policies. NamespaceManager manages zero or more NamespaceEntry instances, each corresponding to an independent isolated network namespace. Internally, it records the network identifier, VETH tunnel configuration, and DHCP service handle of the isolated environment, and holds the NatStrategy translation policy object associated with that isolated environment. NatStrategy is responsible for generating specific NETMAP inbound and outbound rules and injecting these rules into iptables by calling underlying interfaces. NetlinkExecutor, as the lowest-level infrastructure class, encapsulates the execution capabilities of kernel-mode configuration, including performing kernel-mode configuration operations and switching namespace contexts, providing underlying support for the issuance of upper-level policies. Overall, the management and control end uses this four-layer architecture to achieve the creation of isolated namespaces, configuration of VETH tunnels, lifecycle management of DHCP services, and atomic issuance and revocation of NETMAP bidirectional mapping policies, forming a layered and decoupled system from high-level business logic to low-level kernel operations.
[0126] (a) The solution in this embodiment only requires adding a static route in the host machine's namespace. The command `ip route add 192.168.119.0 / 24 via 169.254.100.2` will route packets whose destination IP address belongs to the masquerading network segment 192.168.119.0 / 24 to the next-hop address 169.254.100.2 (i.e., the IP address NS_TIP bound to the isolated network card).
[0127] (ii) The solution in this embodiment only requires adding two NETMAP rules within the isolated namespace. This is achieved by using the command `ip netns exec drill iptables -t nat -A PREROUTING -d 192.168.119.0 / 24 -jNETMAP --to 192.168.88.0 / 24` to add an inbound network segment restoration mapping rule to the PREROUTING chain of the iptables nat table in the isolated namespace. This rule is used to replace the destination IP address of packets sent to the masquerading network segment 192.168.119.0 / 24 with the corresponding address in the real network segment 192.168.88.0 / 24, bit by bit, in a 1:1 ratio. The command `ip netnsexec drill iptables -t nat -A POSTROUTING -o veth_ns -s 192.168.88.0 / 24 -jNETMAP --to 192.168.119.0 / 24` adds an outbound network segment masquerading mapping rule to the POSTROUTING chain of the iptables nat table in the isolated namespace. This rule is used to replace the source IP address of packets originating from the isolated network interface `veth_ns`, whose source address belongs to the real network segment 192.168.88.0 / 24, with the corresponding address in the masquerading network segment 192.168.119.0 / 24 bit by bit, 1:1.
[0128] When a second set of network segment mappings needs to be added (for example, mapping the masquerading network segment 10.0.99.0 / 24 to the production real network segment 10.0.0.0 / 24), there is no need to recreate the VETH link tunnel or configure any new IP address on the host network card. Simply repeat the configuration operations in (I) and (II) above:
[0129] Execute the command `ip route add 10.0.99.0 / 24 via 169.254.100.2` within the host namespace to add a second static route pointing to the isolated network interface card, thereby redirecting packets destined for the masquerading network segment 10.0.99.0 / 24 to the isolated namespace.
[0130] Within the isolated namespace, execute the command `ip netns exec drill iptables -t nat -A PREROUTING-d 10.0.99.0 / 24 -j NETMAP --to 10.0.0.0 / 24` to add a second incoming network segment restoration mapping rule. This rule replaces the destination IP address of packets sent to the masquerading network segment 10.0.99.0 / 24 with the corresponding address in the real production network segment 10.0.0.0 / 24, bit by bit, in a 1:1 ratio.
[0131] Within the isolated namespace, execute the command `ip netns exec drill iptables -t nat -APOSTROUTING -o veth_ns -s 10.0.0.0 / 24 -j NETMAP --to 10.0.99.0 / 24` to add a second outbound network segment masquerading mapping rule. This rule replaces the source IP address of packets originating from the isolated network interface `veth_ns`, whose source address belongs to the real network segment 10.0.0.0 / 24, with the corresponding address in the masquerading network segment 10.0.99.0 / 24, bit by bit, in a 1:1 ratio.
[0132] With the above configuration, the system can simultaneously carry multiple network segment mapping relationships on the same VETH Pair link local tunnel. Each mapping is independent of the others and does not interfere with each other, achieving horizontal expansion with zero infrastructure changes.
[0133] The Backup Agent defines an abstract base class `Nat_Strategy`, whose derived class `Masquerade_Strategy` encapsulates the methods provided in this embodiment. `Masquerade_Strategy` holds a `Masquerade_Config` configuration object (containing two network segments: `real_network` and `masquerade_network`). Its `apply()` method sequentially issues "host-side routing" and "bidirectional NETMAP rules" within the Namespace Manager (NS); the `remove()` method reverts these rules in reverse order, implementing policy-level lifecycle management. This Strategy is held by a singleton of `Namespace_Manager` and can coexist with other strategies (such as `Static_Mapping_Strategy`) within the same isolated namespace without interfering with each other.
[0134] The `ip route add M / 24 via NS_TIP` command in step S2 can be replaced with an equivalent implementation based on policy-based routing, that is, using the `ip rule` command in conjunction with an independent routing table to direct specified traffic to a specific route; or, if the host machine has multiple uplink physical interfaces, `-i` can be appended to the redirecting route.<ingress_dev> The parameters are used to specify the entry interface. All the above implementations are essentially the same: redirecting packets destined for the masquerading network segment M / 24 to the host machine's network interface card veth_host.
[0135] The tunnel address range mentioned above uses the 169.254.100.0 / 24 address range. This range can be replaced with any private network address range in RFC 1918 that does not conflict with the customer's production network segment, or with the shared address range 100.64.0.0 / 10 defined in RFC 6598, as long as the selected address range does not overlap with the customer's actual production network segment. The Link-Local address range defined in RFC 3927 can be used as the allocation range for IP addresses at both ends of the tunnel.
[0136] In addition to using the iptables NETMAP module in the Linux Netfilter framework to implement bitwise address mapping, the equivalent NAT table in nftables can be used in conjunction with snat to ip prefix expressions and dnat to ip prefix expressions to achieve the same stateless address replacement function; alternatively, a bitwise address rewriting program can be written based on eBPF / XDP technology to achieve an equivalent 1:1 stateless mapping.
[0137] The aforementioned isolation protocol stack carrier can be implemented using Linux Network Namespace, or it can be replaced by other equivalent mechanisms with network protocol stack isolation capabilities, such as lightweight container network namespaces of other operating systems, or dedicated virtual routing forwarding instances (VRFs), as long as the mechanism can carry independent routing tables and independent Netfilter filtering tables.
[0138] DHCP service can be provided using dnsmasq, or it can be replaced by any standard DHCP server such as ISC DHCP or Kea; or, if the virtual machine in the exercise has been configured with a fixed IP address and does not require dynamic allocation, the deployment of DHCP service can be completely omitted.
[0139] This embodiment can coexist with the Host Route Bypass ARP-based single-machine static mapping method within the same isolated namespace. The two have different granularities of operation. The solution in this embodiment operates on the entire network segment (i.e., batch mapping based on the network segment), while the single-machine static mapping method operates on a single IP address (i.e., fine mapping based on a single machine). Therefore, the two can be used together to meet address mapping requirements of different granularities without interfering with each other.
[0140] This embodiment can achieve zero IP pollution on the host machine. No matter how many spoofed network segments the user configures, the host machine's network card only needs to retain its own real IP and a single Link-Local tunnel IP, which will not cause IP alias explosion and avoid the problem of the number of Proxy network card IP aliases growing linearly with the spoofed network segments in related technologies.
[0141] This embodiment features statelessness and ICMP friendliness. NETMAP is an arithmetic bitwise mapping that does not rely on the conntrack state table. It treats ICMP, UDP, TCP, and any other IP protocol equally, completing bidirectional 1:1 restoration and solving the problem of traditional NAT's inability to match connectionless packet responses.
[0142] This embodiment enables horizontal scaling and minimizes configuration. Adding a new masquerading network segment requires only "one traffic redirection route + two NETMAP rules" and does not consume any VETH / IP resources, overcoming the operational challenges of rebuilding infrastructure for expansion.
[0143] This embodiment can naturally avoid IP conflicts. The transmission tunnel uses the RFC 3927 link local address. The router does not forward this network segment by default, which ensures high security and will not conflict with the customer's production intranet.
[0144] This embodiment can achieve strict Layer 2 isolation and Layer 3 interconnection. The virtual machine runs in an independent NetworkNamespace, which is physically isolated from the host machine and the production network. At the same time, the management end can perform arbitrary automated tests on it by masquerading the network segment, thus achieving the dual goals of isolation and accessibility.
[0145] This embodiment has performance advantages. By avoiding conntrack entry allocation and lookup, the forwarding overhead of a single data stream is significantly reduced. In actual tests, it can achieve near-line-speed forwarding performance on a 10 Gbps link.
[0146] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.
[0147] Based on the same inventive concept, this application also provides a packet forwarding device based on network segment mapping for implementing the packet forwarding method based on network segment mapping described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations in one or more embodiments of the packet forwarding device based on network segment mapping provided below can be found in the limitations of the packet forwarding method based on network segment mapping described above, and will not be repeated here.
[0148] In one exemplary embodiment, such as Figure 6 As shown, a packet forwarding device based on network segment mapping is provided, comprising:
[0149] The routing decision module 601 is used to make routing decisions in the host namespace based on the destination IP address of the exercise request message after it enters the host namespace.
[0150] IP address determination module 602 is used to determine the IP address bound to the isolation side network card of the transmission tunnel by means of routing decision in the host namespace when the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment.
[0151] The message sending and processing module 603 is used to send the exercise request message through the host-side network card of the transmission tunnel corresponding to the isolated-side network card when the next hop of the exercise request message points to the IP address bound to the isolated-side network card of the transmission tunnel, so that the exercise request message is transmitted to the isolated-side network card via the transmission tunnel.
[0152] The network segment restoration module 604 is used to, after the exercise request packet enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request packet belongs to the fake network segment, hit the network segment restoration mapping rule in the isolation namespace, and replace the network part of the destination IP address in the exercise request packet with the network part of the production network segment according to the network segment restoration mapping rule;
[0153] The message sending processing module 603 is further configured to perform routing decisions in the isolated namespace using the destination IP address after the network bit in the exercise request message is replaced, and determine that the exercise request message is sent through the production network card corresponding to the production network segment, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address after the network bit is replaced; the exercise virtual machine runs in the isolated namespace.
[0154] In one exemplary embodiment, the apparatus further includes:
[0155] The isolation-side routing decision module is used to determine the routing within the isolation namespace after the exercise response message sent by the exercise virtual machine in response to the exercise request message enters the isolation namespace, based on the destination IP address of the exercise response message, and to determine whether the exercise response message needs to be sent through the isolation-side network card.
[0156] The network segment masquerading module is used to, when the exercise response message needs to be sent through the isolated side network card and the source IP address in the exercise response message belongs to the production network segment, hit the network segment masquerading mapping rule in the isolated namespace, and replace the network part of the source IP address in the exercise response message with the network part of the masquerading network segment according to the network segment masquerading mapping rule;
[0157] The message sending and processing module 603 is also used to send the exercise response message through the isolation-side network card after the network bit is replaced, so that the exercise response message is transmitted to the host-side network card through the transmission tunnel to be transmitted to the requester who sent the exercise request message.
[0158] In an exemplary embodiment, when the requester is an external device, the message sending processing module 603 is further configured to:
[0159] After the exercise response message enters the host namespace through the host-side network card, it is sent out through the host's external entry network card, so that the exercise response message is transmitted to the requesting party.
[0160] In one exemplary embodiment, the production network interface card (NIC) is connected to the training virtual machine via a port group; after the training request message is sent by the production NIC, it is transmitted to the training virtual machine via the port group.
[0161] In one exemplary embodiment, the host bits of the destination IP address in the exercise request message remain unchanged.
[0162] In one exemplary embodiment, the IP address bound to the isolated network interface card belongs to a network segment that does not conflict with the production network segment.
[0163] Each module in the aforementioned packet forwarding device based on network segment mapping can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.
[0164] In one exemplary embodiment, a computer device is provided, the internal structure of which can be as shown in the figure. Figure 7 As shown, the computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores the data involved in the aforementioned methods. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a packet forwarding method based on network segment mapping.
[0165] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0166] In one exemplary embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps in the various method embodiments described above.
[0167] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the various method embodiments described above.
[0168] In one exemplary embodiment, a computer program product is provided having a computer program stored thereon, the computer program being executed by a processor of the steps described in the various method embodiments above.
[0169] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0170] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0171] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0172] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A packet forwarding method based on network segment mapping, characterized in that, The method includes: After the exercise request message enters the host namespace, the routing decision in the host namespace is made using the destination IP address of the exercise request message; If the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment, the next hop of the exercise request message is determined to be the IP address bound to the isolation side network card of the transmission tunnel through the routing decision in the host namespace; When the next hop of the exercise request message points to the IP address bound to the isolated side network card of the transmission tunnel, the exercise request message is sent through the host side network card of the transmission tunnel corresponding to the isolated side network card, so that the exercise request message is transmitted to the isolated side network card via the transmission tunnel. After the exercise request message enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request message belongs to the fake network segment, the network segment restoration mapping rule in the isolation namespace is matched, and the network bit of the destination IP address in the exercise request message is replaced with the network bit of the production network segment according to the network segment restoration mapping rule; The routing decision in the isolated namespace is made using the destination IP address with the network bit replaced in the exercise request message, and it is determined that the exercise request message is sent through the production network card corresponding to the production network segment, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address with the network bit replaced; the exercise virtual machine runs in the isolated namespace.
2. The method according to claim 1, characterized in that, The method further includes: After the exercise response message sent by the exercise virtual machine in response to the exercise request message enters the isolation namespace, the routing decision in the isolation namespace is made based on the destination IP address of the exercise response message to determine that the exercise response message needs to be sent through the isolation side network card; If the exercise response message needs to be sent through the isolated network card and the source IP address in the exercise response message belongs to the production network segment, the network segment masquerading mapping rule in the isolated namespace is hit, and the network bit of the source IP address in the exercise response message is replaced with the network bit of the masquerading network segment according to the network segment masquerading mapping rule; After the network bit replacement, the exercise response message is sent through the isolated network card, so that the exercise response message is transmitted through the transmission tunnel to the host network card and then to the requester who sent the exercise request message.
3. The method according to claim 2, characterized in that, When the requester is an external device, the method further includes: After the exercise response message enters the host namespace through the host-side network card, it is sent out through the host's external entry network card, so that the exercise response message is transmitted to the requesting party.
4. The method according to claim 1, characterized in that, The production network interface card (NIC) is connected to the training virtual machine via a port group; after the training request message is sent by the production NIC, it is transmitted to the training virtual machine via the port group.
5. The method according to claim 1, characterized in that, The host bits of the destination IP address in the exercise request message remain unchanged.
6. The method according to claim 1, characterized in that, The IP address bound to the isolated network card belongs to a network segment that does not conflict with the production network segment.
7. A packet forwarding device based on network segment mapping, characterized in that, The device includes: The routing decision module is used to make routing decisions in the host namespace based on the destination IP address of the exercise request message after it enters the host namespace. The IP address determination module is used to determine the IP address bound to the isolation side network card of the transmission tunnel by means of routing decisions in the host namespace when the destination IP address of the exercise request message belongs to the masquerading network segment corresponding to the production network segment. The message sending and processing module is used to send the exercise request message through the host-side network card of the transmission tunnel corresponding to the isolated-side network card when the next hop of the exercise request message points to the IP address bound to the isolated-side network card of the transmission tunnel, so that the exercise request message is transmitted to the isolated-side network card via the transmission tunnel. The network segment restoration module is used to, after the exercise request packet enters the isolation namespace via the isolation side network card, if the destination IP address of the exercise request packet belongs to the fake network segment, match the network segment restoration mapping rule in the isolation namespace, and replace the network part of the destination IP address in the exercise request packet with the network part of the production network segment according to the network segment restoration mapping rule; The message sending processing module is further configured to perform routing decisions in the isolated namespace using the destination IP address after the network bit in the exercise request message is replaced, and determine to send the exercise request message through the production network card corresponding to the production network segment, so that the exercise request message is transmitted to the exercise virtual machine corresponding to the destination IP address after the network bit is replaced; the exercise virtual machine runs in the isolated namespace.
8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.