A communication method for virtual machine elastic public network IP based on multi-network card isolation

Abstract

The application relates to the field of network communication and discloses a communication method for virtual machine elastic public network IP based on multi-network card isolation, which comprises the following steps: constructing a management plane logical domain and a business plane logical domain in a cloud management platform, dynamically mounting two virtual network cards for a target virtual machine to access two logical domains; deploying a policy routing daemon in the virtual machine, establishing a two-way communication channel with the cloud platform, and not containing a preset routing script in a virtual machine image; in response to an elastic public network IP binding request, establishing one-to-one NAT mapping in a network node, generating a structured parameter and delivering the structured parameter to the daemon; the daemon dynamically adds a routing entry in a kernel routing table, maintains a connection tracking table, forces an established communication flow to use an initial exit network card, and dynamically adjusts a timeout or cleans up a connection record according to a binding or unbinding event. The application realizes physical isolation of management flow and business flow, session maintenance and zero-dependence on-demand configuration, and improves cloud platform security and operation and maintenance efficiency.

Description

Technical Field

[0001] This invention relates to the field of network communication, and in particular to a communication method based on a virtual machine elastic public IP address with multiple network interface card isolation. Background Technology

[0002] Cloud computing platforms (or cloud platforms for short) abstract physical resources into dynamically allocable computing, storage, and network resources through virtualization technology, providing users with elastic services. In a cloud platform, a virtual machine (VM) is the basic unit carrying user services. Each VM is typically configured with a virtual network interface card (vNIC), which connects to a subnet of a Virtual Private Cloud (VPC) through a virtual switch and obtains a private IP address. When a VM needs to communicate with the public network, the cloud platform uses Network Address Translation (NAT) technology on network nodes to map the VM's private IP address one-to-one with an Elastic IP address (EIP), enabling the forwarding of internal and external network traffic. Furthermore, cloud platforms typically have separate management networks (for operations personnel to manage physical nodes and VMs) and business networks (for carrying tenant business traffic), which are physically or logically isolated to ensure security.

[0003] In cloud computing practices, some application scenarios require virtual machines to possess both management and business functions. For example, a virtual machine may need to receive SSH maintenance commands from the management network while also providing HTTP business services. In traditional solutions, virtual machines are configured with only a single virtual network interface card (NIC) to handle both management and business traffic, resulting in both types of traffic sharing the same network channel. This architecture poses a security risk: if the business port is compromised, the attacker can use the same NIC to listen for or hijack management traffic, thereby gaining lateral control over the entire cloud platform. Furthermore, when multiple EIPs need to be bound to a virtual machine to cope with multi-line or high-bandwidth demands, the single NIC multi-IP alias method is prone to asymmetric routing problems due to the uniqueness of the operating system's default gateway, leading to abnormal TCP connection resets. Additionally, a single NIC cannot set independent bandwidth limiting policies for management and business traffic; high-traffic services may consume management bandwidth, causing congestion in the maintenance channel.

[0004] To address the aforementioned issues, existing technologies have proposed several improvements. For example, Chinese patent CN105872129B discloses a method for implementing external network communication for a Linux virtual machine with multiple network cards. This method adds multiple internal network cards to the virtual machine via a cloud platform, binds a floating IP to each network card and performs DNAT (Depth-In-Time) routing, then uses qemu-agent to control the virtual machine to execute a pre-set script. After scanning all network card information, it creates an independent routing table for each network card and adds policy routing rules based on the source IP (iprule add from). <ip>table <name>This approach enables multi-NIC external network communication. However, this solution has the following drawbacks: First, the virtual machine image must have pre-configured scripts and routing table files, resulting in a high degree of image customization, making it difficult to manage and upgrade uniformly in large-scale cloud platforms. Second, the routing configuration uses a batch full method, requiring a rescan and reconfiguration of all NICs each time a NIC is added or an EIP is bound, which is inefficient and cannot achieve incremental updates on demand. Third, this solution only addresses the communication problem after multiple NICs are bound to floating IPs, without considering the security isolation between the management plane and the business plane, nor providing a session persistence mechanism for established communication flows, which may lead to the interruption of existing long connections when the routing policy changes. Fourth, this solution relies on policy routing rules based on source IPs, but the number of policy routing rules in the Linux kernel has an upper limit (approximately 32,768), limiting scalability in large-scale scenarios (such as when a virtual machine acts as a gateway and needs to be bound to tens of thousands of EIPs).

[0005] Another Chinese patent, CN108965094A, discloses a virtual machine network connection method. This method creates an internal type virtual network interface card (NIC) on a virtual switch, associates gateways from different subnets with this NIC, and utilizes network namespaces to achieve cross-subnet communication. This method primarily addresses the interoperability problem between virtual machines in different subnets, without involving the binding and management of elastic public IP addresses or providing a dynamic configuration mechanism for internal virtual machine routing. Chinese patent CN116346536B discloses a method for virtual machines to access the cloud platform management network. This method creates a virtual bridge and performs VLAN translation, allowing the virtual machine to access the physical node's management network at Layer 2. This method focuses on how the virtual machine securely accesses the management network, rather than the virtual machine's own public network communication and the isolation of management / service traffic.

[0006] In summary, the existing technology lacks a method that can simultaneously achieve physical isolation between the management and business planes, on-demand routing configuration with zero image dependency, session persistence during EIP binding, and highly scalable virtual machine elastic public IP communication. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation, which addresses the shortcomings of existing technologies such as the inability to physically isolate management traffic and business traffic, security risks and asymmetric routing vulnerabilities caused by single-NIC solutions for virtual machines, as well as the need for pre-configured scripts, low efficiency of batch configuration, lack of session persistence mechanism and limited scalability in multi-NIC solutions.

[0008] Specifically, this invention provides a communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation, the method comprising the following steps: S1. Construct management plane logical domains and business plane logical domains on the cloud management platform, and allocate independent private IP address ranges and gateways to each logical domain; S2. Dynamically mount the first virtual network card to the management plane logical domain and the second virtual network card to the service plane logical domain for the target virtual machine; S3. Deploy a policy routing daemon process inside the target virtual machine. The daemon process establishes a two-way communication channel with the cloud management platform, and the image of the target virtual machine does not contain any pre-set routing configuration scripts or policy routing rules. S4. In response to the request to bind an elastic public IP to the target virtual machine, the cloud management platform establishes a one-to-one NAT mapping between the elastic public IP and the private IP of the second virtual network card at the network node, and generates structured routing configuration parameters and sends them to the daemon process. S5. The daemon process dynamically adds corresponding route entries to the kernel routing table of the target virtual machine according to the configuration parameters; S6. The daemon process maintains the connection tracking table, forces established communication flows to continue using the initial egress network card; and, in response to the binding event of the elastic public IP, extends the timeout of communication flows in the connection tracking table whose source address or destination address is the private IP of the second virtual network card to a preset threshold; in response to the unbinding event of the elastic public IP, actively deletes all connection records in the connection tracking table related to the private IP of the second virtual network card.

[0009] Furthermore, the specific methods for constructing the management plane logical domain and the business plane logical domain in step S1 include: S11. Configure the management plane logical domain to correspond to the management plane, allocate the first IP address pool and associate it with the management gateway, and only allow SSH, ICMP and SNMP operation and maintenance management protocol messages to pass through; S12. Configure the business plane corresponding to the business plane logical domain, allocate the second IP address pool and associate it with the business gateway, and allow HTTP, HTTPS and TCP business application protocol messages to pass through; S13. Configure different virtual LAN labels or virtual extended LAN network identifiers for the management plane logical domain and the service plane logical domain on the underlying distributed virtual switch to achieve physical isolation of the data link layer.

[0010] Furthermore, the specific methods for dynamically adding route entries in step S5 include: S51. After receiving the configuration parameters, the daemon process calls the operating system kernel's route addition command or equivalent route management interface to dynamically add a route entry for the target service network segment to the kernel master routing table of the target virtual machine. The next hop of the route entry is the gateway of the second virtual network card, and the metric value is a preset priority. S52. Before adding the route entry, the daemon process first checks whether there are already route entries with the same destination network segment in the kernel routing table. If they exist and have different priorities, they are merged or skipped according to a preset strategy to avoid routing conflicts. S53. In response to the command to unbind the elastic public IP or remove the virtual network card issued by the cloud management platform, the daemon process calls the route deletion command or equivalent interface to automatically delete the corresponding single route entry without performing a full scan or script.

[0011] Furthermore, the specific methods by which the daemon process maintains the connection tracking table and forces established communication flows to continue using the initial egress network card in step S6 include: S61. The daemon process obtains and maintains a connection tracking table through the conntrack subsystem of the netfilter framework. The connection tracking table records the five-tuple information of each communication flow and the corresponding egress network card identifier. S62. When the target virtual machine sends an outbound message, the daemon process or kernel module intercepts the message, extracts its source IP address, destination IP address, source port, destination port, and protocol type 5-tuple information, and queries the connection tracking table. S63. If a matching record is found, the message is forced to be sent from the egress network card specified in the record, without re-performing the routing table lookup, so as to ensure the symmetry of the established communication flow. S64. If no matching record is found, perform a routing table lookup based on the destination IP to determine the egress network interface card (NIC), and then associate the 5-tuple with the selected egress NIC and write it into the connection tracking table.

[0012] Furthermore, the specific methods for dynamically adjusting the timeout parameters or actively clearing connection records in response to the binding or unbinding event of the elastic public IP in step S6 include: S65. In response to the binding event of the elastic public IP, the daemon process queries all communication flows in the connection tracing table whose source address or destination address is the private IP of the second virtual network card, calls the connection tracing update command or equivalent interface, and extends the timeout of the matched communication flow from the system default value to a preset first threshold. S66. The first threshold is a value greater than the system default TCP connection establishment timeout, used to avoid unexpected interruption of long connections due to EIP binding operations; S67. In response to the unbinding event of the elastic public IP, the daemon process queries all communication flows in the connection tracing table whose source address or destination address is the private IP of the second virtual network card, calls the connection tracing delete command or equivalent interface, actively deletes the matching connection record, releases kernel resources, and restores the timeout time of the corresponding routing entry to the default value. S68. The daemon process records each timeout parameter adjustment and connection cleanup operation to the local audit log, and supports remote querying by the cloud management platform.

[0013] Furthermore, the method also includes specific steps S7 for link health detection, automatic fault switching, and failover: S71. The daemon process sends ARP requests or ICMP echo request probe packets to their respective gateways through the first virtual network card and the second virtual network card at a preset period T. S72. The daemon process maintains a continuous packet loss counter for each network card. If it fails to receive a response from the gateway corresponding to the second virtual network card for N consecutive times, it determines that the service plane link is faulty, where N is an integer greater than or equal to 3. S73. In response to the link failure determination, the daemon process automatically calls the route replacement command or equivalent interface to modify the next hop of the corresponding route entry of the target service network segment, points it to the gateway of the first virtual network card, and reports alarm information including the failure time and the fault network card identifier to the cloud management platform. S74. During a link failure, the daemon process continues to send probe packets through the second virtual network card at a period of T. S75. When the response from the gateway corresponding to the second virtual network card is received M times consecutively, it is determined that the service plane link has been restored, where M is an integer greater than or equal to 2. S76. In response to link recovery, the daemon automatically switches the next hop of the routing entry back to the original gateway of the second virtual network interface card and notifies the cloud management platform that the link has been restored.

[0014] Furthermore, when the second virtual network interface card is bound to multiple elastic public IPs, the specific methods for achieving multi-EIP bandwidth aggregation include: The daemon process obtains the bandwidth quota and currently used bandwidth corresponding to each elastic public IP bound to the second virtual network interface from the cloud platform. For newly established outbound traffic, the daemon process selects one source IP address from the plurality of elastic public IPs according to a weighted round-robin or least connections algorithm. The daemon process dynamically adds a policy routing rule based on the destination IP. S84. When the elastic public IP is unbound or the bandwidth quota is changed, the daemon process automatically deletes the corresponding policy routing rules and recalculates the load sharing policy.

[0015] Furthermore, the target virtual machine adopts a multi-routing table forwarding mechanism based on the destination IP and does not configure any policy routing rules based on the source IP, so as to avoid the impact of the policy routing rule limit on scalability in large-scale multi-NIC scenarios; wherein, the outbound packet queries the kernel routing table according to its destination IP address, and after matching the routing entry added in step S5, it is sent from the second virtual NIC.

[0016] A storage medium storing instructions and data for implementing a communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation.

[0017] A communication device for virtual machine elastic public IP based on multi-NIC isolation includes: a processor, a storage medium, and an edge computing acceleration module; the processor loads and executes instructions and data in the storage medium to implement a communication method for virtual machine elastic public IP based on multi-NIC isolation.

[0018] The beneficial effects provided by this invention are: 1. Enhanced security: By constructing independent management plane logical domains and business plane logical domains, and implementing physical isolation at the data link layer, the security of the cloud platform is significantly improved by effectively preventing unauthorized access to management traffic after the business network card is compromised.

[0019] 2. Improved communication reliability: By maintaining the connection tracking table through a daemon process, established communication flows are forced to use the initial egress network card, avoiding connection interruptions caused by asymmetric routing; at the same time, the timeout time of related communication flows is extended in response to EIP binding events to avoid unexpected interruptions of long connections; and connection records are actively cleaned up in response to unbinding events to release kernel resources.

[0020] 3. Improved operational efficiency: Virtual machine images do not contain any pre-built routing scripts or rules. All routing entries are delivered by the cloud platform in real time as needed. The daemon process dynamically adds or deletes individual routing entries incrementally without full scanning, achieving unified management of images and atomic and event-driven configuration.

[0021] 4. Improved business continuity: The daemon periodically probes the link status. When a business link fails, it automatically switches traffic to the management link and automatically switches back after recovery, achieving second-level fault switching and ensuring business continuity.

[0022] 5. Improved bandwidth utilization: When a service network card is bound to multiple elastic public IPs, the daemon process distributes new service flows using a weighted round-robin or least-connection algorithm based on bandwidth quotas, achieving linear superposition of bandwidth from multiple EIP exits.

[0023] 6. Enhanced Scalability: It adopts a main routing table forwarding mechanism based on the destination IP and does not configure any policy routing rules based on the source IP. This avoids the limitation on the number of policy routing rules in the Linux kernel and has significant scalability advantages in large-scale scenarios that require binding a large number of EIPs. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the method flow of the present invention; Figure 2 This is a schematic diagram of the hardware device operation according to an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0026] Before formally describing the present invention, a general description of the solution of the present invention will be given first to facilitate understanding.

[0027] Example 1 Please refer to Figure 1 The present invention provides a communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation, comprising the following steps: S1. Construct management plane logical domains and business plane logical domains on the cloud management platform, and allocate independent private IP address ranges and gateways to each logical domain; It should be noted that the specific methods for constructing the management plane logical domain and the business plane logical domain in step S1 include: S11. Configure the management plane logical domain to correspond to the management plane, allocate the first IP address pool and associate it with the management gateway, and only allow SSH, ICMP and SNMP operation and maintenance management protocol messages to pass through; S12. Configure the business plane corresponding to the business plane logical domain, allocate the second IP address pool and associate it with the business gateway, and allow HTTP, HTTPS and TCP business application protocol messages to pass through; S13. Configure different virtual LAN labels or virtual extended LAN network identifiers for the management plane logical domain and the service plane logical domain on the underlying distributed virtual switch to achieve physical isolation of the data link layer.

[0028] As one embodiment, in step S11, the management plane logical domain only allows operation and maintenance management protocol messages such as SSH (port 22), ICMP (ping), and SNMP (port 161) to pass through. For example, configure an ACL rule on the virtual router to allow TCP packets with source IP of management network segment 10.10.0.0 / 24 and destination port 22 / 161, and discard the rest.

[0029] In step S12, the business plane logical domain allows HTTP (80), HTTPS (443), and any TCP business port (such as 8080) to pass through without imposing strict restrictions on the protocols.

[0030] In step S13, different VLAN tags are configured for the management domain and the service domain on the underlying distributed virtual switch (such as Open vSwitch). For example, the management domain uses VLAN 100, and the service domain uses VLAN 200. Trunk mode is set on the physical switch ports to allow VLANs 100 and 200 to pass through, achieving physical isolation at the data link layer. For example, packets sent from eth0 of virtual machine web-server-01 will be tagged with VLAN 100, and packets sent from eth1 will be tagged with VLAN 200, making them completely isolated on the physical network.

[0031] S2. Dynamically mount the first virtual network card to the management plane logical domain and the second virtual network card to the service plane logical domain for the target virtual machine; As one embodiment, in step S2 of the present invention, when a tenant creates a virtual machine (e.g., named web-server-01), the cloud management platform dynamically creates and hot-plugs two virtual network cards for the virtual machine by calling a virtualization driver (such as libvirt).

[0032] The first virtual network interface (e.g., eth0) is bound to the management plane logical domain mgmt-vpc and obtains a management private IP address, such as 10.10.0.10, via DHCP or static configuration; the second virtual network interface (e.g., eth1) is bound to the service plane logical domain biz-vpc and obtains a service private IP address, such as 192.168.1.10. The hot-plugging process is completed without shutting down the virtual machine and requires no restart.

[0033] S3. Deploy a policy routing daemon process inside the target virtual machine. The daemon process establishes a two-way communication channel with the cloud management platform, and the image of the target virtual machine does not contain any pre-set routing configuration scripts or policy routing rules. It should be noted that the specific implementation of establishing a two-way communication channel between the policy routing daemon and the cloud management platform in step S3 includes: S31. The bidirectional communication channel is implemented based on a virtio-serial virtual serial port or a management network TCP connection independent of the business network; S32. The daemon process runs as a native operating system service, listens to a specified port or virtual serial port, and communicates with the cloud management platform through a TLS encrypted channel. S33. When the target virtual machine image is created, no routing configuration scripts, policy routing rules or routing table entries need to be pre-set. All routing configurations are pushed down by the cloud management platform in real time as needed, achieving zero image dependency.

[0034] As one embodiment, in step S3 of this invention, a custom daemon process (e.g., named eip-route-agent) is installed and run inside the virtual machine's operating system (e.g., CentOS 7.9). This daemon process establishes a bidirectional TLS encrypted channel with the cloud management platform's API service through the management network (e.g., using the IP address 10.10.0.10 of the management plane logical domain). The original image of the virtual machine does not contain any pre-installed routing configuration scripts, policy routing rules, or static route entries; all routing configurations rely entirely on subsequent dynamic distribution from the cloud platform.

[0035] For example, the / etc / sysconfig / network-scripts / directory in the image only contains basic network card configurations (such as ONBOOT=yes), and does not contain files such as route-eth1, nor does it contain custom table entries in / etc / iproute2 / rt_tables.

[0036] S4. In response to the request to bind an elastic public IP to the target virtual machine, the cloud management platform establishes a one-to-one NAT mapping between the elastic public IP and the private IP of the second virtual network card at the network node, and generates structured routing configuration parameters and sends them to the daemon process. It should be noted that the specific method of the structured routing configuration parameters in step S4 includes: the structured routing configuration parameters adopt JSON or Protobuf format and include the target service network segment, the next-hop gateway address, the egress network card identifier, and the routing priority field.

[0037] As one embodiment, in step S4 of this invention, when a tenant binds an elastic public IP (e.g., 203.0.113.10) to the business network interface eth1 of the virtual machine web-server-01 via the cloud platform console, the cloud management platform first creates a 1:1 DNAT / SNAT rule on the network node (e.g., a router using OpenStack Neutron) to map the public IP 203.0.113.10 to the business private IP 192.168.1.10. Simultaneously, the cloud management platform generates a structured JSON configuration parameter based on a predefined business network segment (e.g., the network segment 0.0.0.0 / 0 that needs to provide services externally, or a specific peer network segment), for example: json { "action": "add", "destination": "0.0.0.0 / 0", "gateway": "192.168.1.1", "device": "eth1", "metric": 100 } Then, through the bidirectional channel established in step S3, the parameter is sent to the eip-route-agent daemon process inside the virtual machine.

[0038] S5. The daemon process dynamically adds corresponding route entries to the kernel routing table of the target virtual machine according to the configuration parameters; In one embodiment, in step S5 of this invention, after the daemon process eip-route-agent receives the above JSON configuration, it calls the Linux kernel's routing management interface (e.g., via netlinksocket or by executing the ip routeadd command) to dynamically add a route entry to the virtual machine's main routing table: default via 192.168.1.1 dev eth1 metric 100. This entry is only added when the EIP is bound and will not affect the original routes of the management network interface eth0 (e.g., routes for the management network segment 10.10.0.0 / 24 still go through eth0). When the EIP is unbound, the daemon process receives a deletion command and executes ip route del default via 192.168.1.1 dev eth1 to precisely delete the entry without scanning the entire routing table.

[0039] It should be noted that the specific methods for dynamically adding route entries in step S5 include: S51. After receiving the configuration parameters, the daemon process calls the operating system kernel's route add command (ip route add) or an equivalent route management interface to dynamically add a route entry for the target service network segment to the kernel master routing table of the target virtual machine. The next hop of the route entry is the gateway of the second virtual network card, and the metric value is a preset priority. In one embodiment, in step S51, the daemon calls ip route add 0.0.0.0 / 0 via192.168.1.1 dev eth1 metric 100, where metric 100 is a preset priority, lower than the default route of the management network card (metric 0), to ensure that service traffic takes priority through the service network card.

[0040] S52. Before adding the route entry, the daemon process first checks whether there are already route entries with the same destination network segment in the kernel routing table. If they exist and have different priorities, they are merged or skipped according to a preset strategy to avoid routing conflicts. In step S52, before adding the route, the daemon executes `ip route show` to check if a route to 0.0.0.0 / 0 already exists. If it exists and the metric is different (e.g., there is already a route like `default via 10.10.0.1 dev eth0 metric 0`), the new entry is added directly, and the kernel selects the route with higher priority based on the metric value. If the same destination network segment and the same metric value exist, the addition is skipped and logged to avoid conflicts.

[0041] S53. In response to the command to unbind the elastic public IP or remove the virtual network card issued by the cloud management platform, the daemon process calls the route deletion command (ip-route-del) or equivalent interface to automatically delete the corresponding single route entry without performing a full scan or script.

[0042] In step S53, when unbinding the EIP, the cloud platform issues a deletion command, and the daemon process executes ip-route -del0.0.0.0 / 0 via 192.168.1.1 dev eth1, without needing to perform full operations such as ip-route-flush-table.

[0043] S6. The daemon process maintains the connection tracking table, forces established communication flows to continue using the initial egress network card; and, in response to the binding event of the elastic public IP, extends the timeout of communication flows in the connection tracking table whose source address or destination address is the private IP of the second virtual network card to a preset threshold; in response to the unbinding event of the elastic public IP, actively deletes all connection records in the connection tracking table related to the private IP of the second virtual network card.

[0044] It should be noted that the specific methods by which the daemon process maintains the connection tracking table and forces established communication flows to continue using the initial egress network card in step S6 include: S61. The daemon process obtains and maintains a connection tracking table through the conntrack subsystem of the netfilter framework. The connection tracking table records the five-tuple information of each communication flow and the corresponding egress network card identifier. In one embodiment, in step S61, the daemon process reads the connection tracking table through the / proc / net / nf_conntrack or libnetfilter_conntrack library. Each record in the table contains: a five-tuple for the original direction (source IP, destination IP, source port, destination port, protocol) and a five-tuple for the response direction, as well as a timeout. The daemon process also maintains an additional mapping table in memory, recording the egress network interface (e.g., eth1) corresponding to each five-tuple.

[0045] S62. When the target virtual machine sends an outbound message, the daemon process or kernel module intercepts the message, extracts its source IP address, destination IP address, source port, destination port, and protocol type 5-tuple information, and queries the connection tracking table. In step S62, when the virtual machine sends an outbound packet, the daemon intercepts the packet through iptables NFQUEUE or netfilter hook and extracts the 5-tuple.

[0046] S63. If a matching record is found, the message is forced to be sent from the egress network card specified in the record, without re-performing the routing table lookup, so as to ensure the symmetry of the established communication flow. In step S63, if a matching record is found in the mapping table, skb->dev is forcibly set to the network card in the record, and then the packet is allowed to pass without performing a route lookup.

[0047] S64. If no matching record is found, perform a routing table lookup based on the destination IP to determine the egress network interface card (NIC), and then associate the 5-tuple with the selected egress NIC and write it into the connection tracking table.

[0048] In step S64, if the packet is not found, the kernel standard route lookup (ip_route_output_key) is called to determine the egress network card. After that, the 5-tuple and the network card are stored in the mapping table, and then the packet is sent.

[0049] For example, a virtual machine establishes an SSH connection with 203.0.113.20 via eth1 (source IP 192.168.1.10, source port 50001). The five-tuple of this connection is recorded. Subsequently, even if the routing of the service network interface eth1 is temporarily modified, all subsequent packets of this connection will still be sent from eth1 and will not incorrectly exit through eth0, causing the connection to be interrupted.

[0050] It should be noted that the specific methods for dynamically adjusting the timeout parameters or actively clearing connection records in response to the binding or unbinding event of the elastic public IP in step S6 include: S65. In response to the binding event of the elastic public IP, the daemon process queries the connection tracking table for all communication flows whose source address or destination address is the private IP of the second virtual network card, and calls the connection tracking update command (conntrack -U --orig-src $PRIVATE_IP --timeout $NEW_TIMEOUT) or equivalent interface to extend the timeout of the matched communication flow from the system default value to a preset first threshold. As one embodiment, in step S65, after the binding event is triggered, the daemon process executes: conntrack -U--orig-src 192.168.1.10 --timeout 864000. Here, 864000 seconds (10 days) is a preset first threshold, which is much greater than the system's default TCP established timeout (432000 seconds).

[0051] S66. The first threshold is a value greater than the system default TCP connection established timeout period, used to avoid unexpected interruption of long connections due to EIP binding operations; In step S66, the threshold can be configured according to business needs. For example, it can be set to 1,728,000 seconds (20 days) for long database connections.

[0052] S67. In response to the unbinding event of the elastic public IP, the daemon process queries all communication flows in the connection tracking table whose source address or destination address is the private IP of the second virtual network card, calls the connection tracking deletion command (conntrack -D --orig-src $PRIVATE_IP) or equivalent interface, actively deletes the matching connection record, releases kernel resources, and restores the timeout of the corresponding routing entry to the default value. In step S67, after the unbinding event is triggered, the daemon process executes: `conntrack -D --orig-src192.168.1.10`, deleting all connection records with source addresses that are business private IPs. Simultaneously, for connections with destination addresses of 192.168.1.10, it executes: `conntrack -D --orig-dst 192.168.1.10`. After deletion, the corresponding `nf_conn` structure in the kernel is released.

[0053] S68. The daemon process records each timeout parameter adjustment and connection cleanup operation to the local audit log, and supports remote querying by the cloud management platform.

[0054] In step S68, the daemon writes all operations (including adding routes, deleting routes, modifying timeouts, and deleting connections) to / var / log / eip-route-agent.log in JSON format and exposes an HTTP API for the cloud platform to query and audit.

[0055] For example, suppose there is a persistent TCP connection between the virtual machine and the database server. If only the NAT rule is deleted during EIP unbinding without cleaning up the conntrack entry, this connection entry may remain for several days. This solution proactively deletes it, freeing up kernel memory and avoiding resource waste.

[0056] It should be noted that the method also includes specific steps S7 for link health detection, automatic fault switching, and failover: S71. The daemon process sends ARP requests or ICMP echo request probe packets to their respective gateways through the first virtual network card and the second virtual network card at a preset period T. In one embodiment, in step S71, the daemon process sends an ARP request to the management gateway 10.10.0.1 via eth0 every 30 seconds (period T), and sends an ARP request to the service gateway 192.168.1.1 via eth1.

[0057] S72. The daemon process maintains a continuous packet loss counter for each network card. If it fails to receive a response from the gateway corresponding to the second virtual network card for N consecutive times, it determines that the service plane link is faulty, where N is an integer greater than or equal to 3. In step S72, two counters, fail_cnt_eth0 and fail_cnt_eth1, are maintained. If no ARP response is received from the service gateway for three consecutive times (N=3), the service link is determined to be faulty.

[0058] S73. In response to the link failure determination, the daemon process automatically calls the route replacement command (ip-route-replace) or equivalent interface to modify the next hop of the corresponding route entry of the target service network segment, pointing it to the gateway of the first virtual network card, and reports alarm information including the failure time and the fault network card identifier to the cloud management platform. In step S73, the daemon executes `ip route replace default via 10.10.0.1 dev eth0metric 100`, temporarily redirecting the next hop of service traffic to the management gateway. Simultaneously, it reports an alarm to the cloud platform via API: {"time": "2025-04-15T10:00:00Z", "fault_device": "eth1"}.

[0059] S74. During a link failure, the daemon process continues to send probe packets through the second virtual network card at a period of T. In step S74, a probe is still sent to the service gateway every 30 seconds during the fault period.

[0060] S75. When the response from the gateway corresponding to the second virtual network card is received M times consecutively, it is determined that the service plane link has been restored, where M is an integer greater than or equal to 2. In step S75, when the service gateway response is received twice consecutively (M=2), the link is determined to be restored.

[0061] S76. In response to link recovery, the daemon automatically switches the next hop of the routing entry back to the original gateway of the second virtual network interface card and notifies the cloud management platform that the link has been restored.

[0062] In step S76, execute `ip route replace default via 192.168.1.1 dev eth1metric 100` to switch back and notify the cloud platform.

[0063] For example, when the physical switch connected to the service network card eth1 fails, the virtual machine service traffic is automatically switched to the management network card eth0. Although the bandwidth is lower, service continuity is guaranteed; it automatically switches back after recovery.

[0064] It should be noted that when the second virtual network interface card is bound to multiple elastic public IPs, the specific methods for achieving multi-EIP bandwidth aggregation include: The daemon process obtains the bandwidth quota and currently used bandwidth corresponding to each elastic public IP bound to the second virtual network interface from the cloud platform. For newly established outbound traffic, the daemon process selects one source IP address from the plurality of elastic public IPs according to a weighted round-robin or least connections algorithm. The daemon process dynamically adds a policy routing rule based on the destination IP using the command ip-rule-add-from $SELECTED_EIP_IP table $CUSTOM_TABLE, where the default egress configured in $CUSTOM_TABLE is the second virtual network interface card. When the elastic public IP is unbound or the bandwidth quota is changed, the daemon process automatically deletes the corresponding policy routing rules and recalculates the load balancing policy.

[0065] As one example, assume that the service network interface eth1 is bound to three EIPs: 203.0.113.10 (bandwidth 100Mbps), 203.0.113.11 (bandwidth 200Mbps), and 203.0.113.12 (bandwidth 100Mbps). The daemon obtains the bandwidth quota and real-time used bandwidth of each EIP from the cloud platform (through the monitoring interface).

[0066] For newly established outbound TCP traffic, the daemon uses a weighted round-robin algorithm with a weight ratio of 1:2:1, selecting EIPs as source IPs in sequence. For example, the first connection selects 203.0.113.10, the second and third connections select 203.0.113.11, the fourth selects 203.0.113.12, and the fifth connection is re-rounded.

[0067] The daemon dynamically adds policy routing rules based on the destination IP: `ip rule add from 203.0.113.10 table 100`, and sets the default route `default via 192.168.1.1 deveth1` in table 100. Similarly, corresponding tables and rules are created for other EIPs.

[0068] When an EIP is unbound or the bandwidth changes, the daemon executes `ip rule del from 203.0.113.10 table100` and recalculates the load balancing strategy.

[0069] For example, using the above method, the total outbound bandwidth of the three EIPs reaches 400Mbps, realizing bandwidth aggregation of multiple EIPs on a single network card.

[0070] It should be noted that the target virtual machine adopts a multi-routing table forwarding mechanism based on the destination IP and does not configure any policy routing rules based on the source IP, so as to avoid the impact of the number of policy routing rules on the scalability of large-scale multi-NIC scenarios; wherein, the outbound packet queries the kernel routing table according to its destination IP address, and after matching the routing entry added in step S5, it is sent from the second virtual NIC.

[0071] As one embodiment, the virtual machine kernel of this invention only uses the main routing table and does not use `ip rule` to add any `from` rules. For example, by viewing the system using the `ip rule show` command, only three default rules are visible (0: from all lookup local, 32766: from all lookup main, 32767: from all lookup default). All outbound packets query the main routing table based on the destination IP.

[0072] Because it avoids source IP-based policy routing rules and is not limited by the Linux kernel's FIB_RULES limit (typically around 32,768 rules), it can still function normally in large-scale scenarios requiring the binding of hundreds or thousands of EIPs. For example, when a virtual machine acts as a gateway or NAT instance and needs to handle a large number of EIPs, the scalability of this solution is significantly better than traditional solutions.

[0073] Example 2: To verify the superiority of the present invention, experiments of varying degrees were conducted.

[0074] First, please refer to Table 1, which represents a comparison of the management / business isolation security of the solution of this invention and different solutions. You can intuitively see the differences in the solution of this application.

[0075] Table 1 Comparison of Management / Business Isolation Security of Different Solutions

[0076] Secondly, in order to prove that the present invention avoids the problem of long-term connection interruption when EIP binding occurs by extending the conntrack timeout, the present invention conducted the following experiments.

[0077] Experimental conditions: A long-lived TCP connection (MySQL database connection, port 3306) is established between virtual machine A (business IP 192.168.1.10) and external server B (203.0.113.20), continuously transmitting heartbeats. At 30 seconds after connection establishment, an EIP (203.0.113.100) is bound to virtual machine A. Whether the connection is interrupted is recorded. See Table 2 for the results.

[0078] Furthermore, in order to demonstrate the rapid recovery capability of the link health detection + automatic switching of this invention, this application also conducted corresponding experiments.

[0079] Experimental conditions: The physical switch port connected to the virtual machine's service network interface card eth1 was manually shut down. Record the time from the occurrence of the fault to the switch of service traffic to the management network interface card eth0. Refer to Table 3.

[0080] Table 2 Comparison of the impact of EIP binding on established long-lived connections

[0081] Table 3 Comparison of recovery times for different fault detection and switching schemes

[0082] As can be seen intuitively, the link detection cycle of this invention can be as low as 5 seconds, and a switch is triggered after 3 consecutive failures. The total switch time is about 15 seconds, which is much faster than the traditional script solution (minutes) and does not require manual intervention.

[0083] Finally, this invention conducted a multi-EIP bandwidth aggregation experiment.

[0084] The experiment is as follows: The virtual machine's service network interface card eth1 is bound to three EIPs: EIP1 (bandwidth 100Mbps), EIP2 (200Mbps), and EIP3 (100Mbps). Ten concurrent outbound TCP flows are initiated simultaneously using the iperf3 tool, each targeting a different public server. The total throughput is recorded.

[0085] The purpose is to demonstrate that by binding multiple EIPs to a single network interface card (NIC), a weighted round-robin / least connections algorithm can be used to linearly superimpose the total outbound bandwidth. See Table 4.

[0086] Table 4. Comparison of total throughput of different solutions in multi-EIP scenarios

[0087] It can be seen that the bandwidth of the proposed solution increases linearly with the number of EIPs.

[0088] Example 3: Please see Figure 2 , Figure 2 This is a schematic diagram of the hardware device operation according to an embodiment of the present invention. The hardware device specifically includes: a communication device 401 based on a virtual machine elastic public IP with multi-NIC isolation, a processor 402, and a storage medium 403.

[0089] A communication device 401 for virtual machines with multi-NIC isolation and elastic public IP addresses: The communication device 401 for virtual machines with elastic public IP addresses based on multi-NIC isolation and elastic public IP addresses implements the communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation and elastic public IP addresses.

[0090] Processor 402: The processor 402 loads and executes the instructions and data in the storage medium 403 to implement the communication method of virtual machine elastic public IP based on multi-NIC isolation.

[0091] Storage medium 403: The storage medium 403 stores instructions and data; the storage medium 403 is used to implement the communication method of virtual machine elastic public IP based on multi-NIC isolation.

[0092] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / name> < / ip>

Claims

1. A communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation, characterized in that: Includes the following steps: S1. Construct management plane logical domains and business plane logical domains on the cloud management platform, and allocate independent private IP address ranges and gateways to each logical domain; S2. Dynamically mount the first virtual network card to the management plane logical domain and the second virtual network card to the service plane logical domain for the target virtual machine; S3. Deploy a policy routing daemon process inside the target virtual machine. The daemon process establishes a two-way communication channel with the cloud management platform, and the image of the target virtual machine does not contain any pre-set routing configuration scripts or policy routing rules. S4. In response to the request to bind an elastic public IP to the target virtual machine, the cloud management platform establishes a one-to-one NAT mapping between the elastic public IP and the private IP of the second virtual network card at the network node, and generates structured routing configuration parameters and sends them to the daemon process. S5. The daemon process dynamically adds corresponding route entries to the kernel routing table of the target virtual machine according to the configuration parameters; S6. The daemon process maintains the connection tracking table and forces established communication flows to use the initial egress network card; Furthermore, in response to the binding event of the elastic public IP, the timeout period of communication flows whose source address or destination address in the connection tracking table is the private IP of the second virtual network card is extended to a preset threshold. In response to the unbinding event of the elastic public IP, all connection records related to the private IP of the second virtual network interface are actively deleted from the connection tracking table.

2. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 1, characterized in that: The specific methods for constructing the management plane logical domain and the business plane logical domain in step S1 include: S11. Configure the management plane logical domain to correspond to the management plane, allocate the first IP address pool and associate it with the management gateway, and only allow SSH, ICMP and SNMP operation and maintenance management protocol messages to pass through; S12. Configure the business plane corresponding to the business plane logical domain, allocate the second IP address pool and associate it with the business gateway, and allow HTTP, HTTPS and TCP business application protocol messages to pass through; S13. Configure different virtual LAN labels or virtual extended LAN network identifiers for the management plane logical domain and the service plane logical domain on the underlying distributed virtual switch to achieve physical isolation of the data link layer.

3. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 1, characterized in that: The specific methods for dynamically adding route entries in step S5 include: S51. After receiving the configuration parameters, the daemon process calls the operating system kernel's route addition command or equivalent route management interface to dynamically add a route entry for the target service network segment to the kernel master routing table of the target virtual machine. The next hop of the route entry is the gateway of the second virtual network card, and the metric value is a preset priority. S52. Before adding the route entry, the daemon process first checks whether there are already route entries with the same destination network segment in the kernel routing table. If they exist and have different priorities, they are merged or skipped according to a preset strategy to avoid routing conflicts. S53. In response to the command to unbind the elastic public IP or remove the virtual network card issued by the cloud management platform, the daemon process calls the route deletion command or equivalent interface to automatically delete the corresponding single route entry without performing a full scan or script.

4. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 1, characterized in that: The specific methods by which the daemon process maintains the connection tracking table and forces established communication flows to continue using the initial egress network card in step S6 include: S61. The daemon process obtains and maintains a connection tracking table through the conntrack subsystem of the netfilter framework. The connection tracking table records the five-tuple information of each communication flow and the corresponding egress network card identifier. S62. When the target virtual machine sends an outbound message, the daemon process or kernel module intercepts the message, extracts its source IP address, destination IP address, source port, destination port, and protocol type 5-tuple information, and queries the connection tracking table. S63. If a matching record is found, the message is forced to be sent from the egress network card specified in the record, without re-performing the routing table lookup, so as to ensure the symmetry of the established communication flow. S64. If no matching record is found, perform a routing table lookup based on the destination IP to determine the egress network interface card (NIC), and then associate the 5-tuple with the selected egress NIC and write it into the connection tracking table.

5. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 4, characterized in that: The specific methods for dynamically adjusting the timeout parameters or actively clearing connection records in response to the binding or unbinding event of the elastic public IP in step S6 include: S65. In response to the binding event of the elastic public IP, the daemon process queries all communication flows in the connection tracing table whose source address or destination address is the private IP of the second virtual network card, calls the connection tracing update command or equivalent interface, and extends the timeout of the matched communication flow from the system default value to a preset first threshold. S66. The first threshold is a value greater than the system's default TCP connection establishment timeout, used to avoid unexpected interruption of long connections due to EIP binding operations; S67. In response to the unbinding event of the elastic public IP, the daemon process queries all communication flows in the connection tracing table whose source address or destination address is the private IP of the second virtual network card, calls the connection tracing delete command or equivalent interface, actively deletes the matching connection record, releases kernel resources, and restores the timeout time of the corresponding routing entry to the default value. S68. The daemon process records each timeout parameter adjustment and connection cleanup operation to the local audit log, and supports remote querying by the cloud management platform.

6. The communication method for virtual machine elastic public IP based on multi-NIC isolation as described in claim 1, characterized in that: The method also includes specific steps S7 for link health detection, automatic fault switching, and failover: S71. The daemon process sends ARP requests or ICMP echo request probe packets to their respective gateways through the first virtual network card and the second virtual network card at a preset period T. S72. The daemon process maintains a continuous packet loss counter for each network card. If it fails to receive a response from the gateway corresponding to the second virtual network card for N consecutive times, it determines that the service plane link is faulty, where N is an integer greater than or equal to 3. S73. In response to the link failure determination, the daemon process automatically calls the route replacement command or equivalent interface to modify the next hop of the corresponding route entry of the target service network segment, points it to the gateway of the first virtual network card, and reports alarm information including the failure time and the fault network card identifier to the cloud management platform. S74. During a link failure, the daemon process continues to send probe packets through the second virtual network card at a period of T. S75. When the response from the gateway corresponding to the second virtual network card is received M times consecutively, it is determined that the service plane link has been restored, where M is an integer greater than or equal to 2. S76. In response to link recovery, the daemon automatically switches the next hop of the routing entry back to the original gateway of the second virtual network interface card and notifies the cloud management platform that the link has been restored.

7. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 1, characterized in that: When the second virtual network interface card is bound to multiple elastic public IPs, the specific methods for achieving multi-EIP bandwidth aggregation include: The daemon process obtains the bandwidth quota and currently used bandwidth corresponding to each elastic public IP bound to the second virtual network interface from the cloud platform. For newly established outbound traffic, the daemon process selects one source IP address from the plurality of elastic public IPs according to a weighted round-robin or least connections algorithm. The daemon process dynamically adds a policy routing rule based on the destination IP. When the elastic public IP is unbound or the bandwidth quota is changed, the daemon process automatically deletes the corresponding policy routing rules and recalculates the load balancing policy.

8. The communication method for virtual machines with elastic public IP addresses based on multi-NIC isolation as described in claim 1, characterized in that: The target virtual machine adopts a multi-routing table forwarding mechanism based on the destination IP and does not configure any policy routing rules based on the source IP, so as to avoid the impact of the number of policy routing rules on the scalability of large-scale multi-NIC scenarios; wherein, the outbound packet queries the kernel routing table according to its destination IP address, and after matching the routing entry added in step S5, it is sent from the second virtual NIC.

9. A storage medium, characterized in that: The storage medium stores instructions and data to implement the communication method of a virtual machine elastic public IP based on multi-NIC isolation as described in any one of claims 1 to 8.

10. A communication device based on virtual machine elastic public IP with multi-NIC isolation, characterized in that: include: Processor, storage media, and edge computing acceleration modules; The processor loads and executes instructions and data in the storage medium to implement the communication method of virtual machine elastic public IP based on multi-NIC isolation as described in any one of claims 1 to 8.

Images