CN112165432B

CN112165432B - Method for realizing communication between OpenStack virtual machine and outside

Info

Publication number: CN112165432B
Application number: CN202010929511.7A
Authority: CN
Inventors: 吴建亮; 胡鹏; 展艺
Original assignee: Guangzhou Jeeseen Network Technologies Co Ltd
Current assignee: Guangzhou Jeeseen Network Technologies Co Ltd
Priority date: 2020-09-07
Filing date: 2020-09-07
Publication date: 2021-06-04
Anticipated expiration: 2040-09-07
Also published as: CN112165432A

Abstract

The invention provides a method for realizing communication between an OpenStack virtual machine and the outside, and belongs to the field of network communication. According to the invention, by utilizing the vet path and iptables technologies, the network of the OpenStack host is added into the qrouter virtual router created by the OpenStack, one end of the vet path is added into the qrouter virtual router, and the IP address of the network outlet source where the virtual machine is located is disguised as the IP address of one end of the vet path added into the qrouter virtual router, so that the communication between the external network and the virtual machine created inside the external network is realized.

Description

Method for realizing communication between OpenStack virtual machine and outside

Technical Field

The invention relates to the technical field of network communication, in particular to a method for realizing communication between an OpenStack virtual machine and the outside.

Background

The OpenStack is an open source IaaS cloud service platform and comprises: nova, Neutron, Cinder, Keystone, Glance five large core components and several optional components. At present, OpenStack is widely applied to various industries, and private cloud, public cloud, leased private cloud and public-private mixed cloud can be rapidly established through OpenStack. Taking a stand-alone private cloud as an example, it means that all service components of OpenStack are installed and deployed in one hardware server, and all operations (virtual machine creation, network partition, and the like) are also completed in the hardware server, and in the following description, the hardware server constructed by the service in which OpenStack is deployed is referred to as an OpenStack host. Generally, if an external PC wants to access a virtual machine created in an OpenStack host, a floating IP address (i.e., an external IP address) needs to be bound for the virtual machine, so that the external PC can communicate with the bound floating IP address to access the virtual machine, as shown in fig. 1.

The above method of binding a floating IP address for external access has a problem, and if a plurality of virtual machines are deployed in an OpenStack host, and all the virtual machines need to be accessed by an external PC, a floating IP address accessible from the outside needs to be bound for each virtual machine, which wastes floating IP address resources. Generally, in a network of a production environment (client), only one working port (WAN) IP address is allocated to an OpenStack host, that is, only one IP address is allocated to access the OpenStack host. Therefore, there is no redundant floating IP address to bind to the multiple virtual machines created in the OpenStack host, and the external PC cannot access the multiple virtual machines created in the OpenStack host.

Chinese patent application document CN110636036A discloses a method for controlling network access of an OpenStack cloud host based on SDN, which includes the following steps: connecting the Linux bridge as a bypass to the OVS, and determining whether a data packet needs to utilize iptables in the Linux bridge to strengthen access control detection or not according to requirements; controlling flow table setting of a virtual switch in OpenStack by using an SDN controller; providing an interface for interaction between a user and a Linux bridge, wherein the user can interact with iptables through a remote programming interface library provided by the iptables, and directly adding, deleting or modifying a forwarding rule in the iptables according to requirements; an interface enabling a user to control access control rules through an SDN controller is provided, and the user can interact with the SDN controller through an SDN APP, so that the SDN controller makes a decision according to modified rules and determines which data packets need to be subjected to access control detection through a Linux bridge when being forwarded. The method uses the SDN to control the flow table setting of the virtual switch in the OpenStack, so that a user can interact with iptables, a forwarding rule is modified, and the control on the network access of a host is realized. According to the method, the access of an external host to the multiple virtual machines in the OpenStack can not be realized under the condition that the floating IP addresses are not distributed to the multiple virtual machines in the OpenStack.

Chinese patent application CN107547278A discloses a method for interfacing OpenStack with an enterprise virtualization environment. The method comprises the following steps: connecting OpenStack with virtualization system data by using a router and a physical switch; the virtualization system customizes a docking architecture corresponding to the OpenStack driver layer, customizes a docking architecture based on rest api, and performs directional docking on the docking architecture and the OpenStack driver layer; the method comprises the steps that an OpenStack driver layer creates a VXLAN network in a virtualization system environment, the OpenStack calls a customized docking architecture through the driver layer, and a neutron network layer in the OpenStack is moved down to the environment of a virtualization system; and a communication channel is created based on the virtual network switch, and network interaction is carried out between the network node in the virtualization system and the virtual machine of the OpenStack. The method carries out network docking with a bottom layer server virtualization environment through OpenStack, forms VXLAN network service in a neutron network docking virtualization environment in OpenStack, and solves the problems of ID number limitation of VLAN and cross-machine room intercommunication. However, in this method, access of an external host to multiple virtual machines in OpenStack cannot be achieved without allocating floating IP addresses to the multiple virtual machines in OpenStack.

The prior art has at least the following disadvantages:

1. under the condition that a plurality of virtual machines in the OpenStack are not allocated with floating IP addresses, the external host can not access the plurality of virtual machines in the OpenStack.

2. In the case of allocating floating IP addresses to multiple virtual machines in OpenStack, it is possible to implement OpenStack for external hosts

But waste floating IP addresses.

Disclosure of Invention

In order to solve the technical problems in the prior art, the method for realizing the communication between the OpenStack virtual machine and the outside is characterized in that by utilizing a vet path technology and an iptables technology under Linux, one end tap-in-host of the vet path is added into an OpenStack host, the other end tap-in-qrouter of the vet path is added into a qrouter virtual router, and the IP address of a network outlet source where the OpenStack virtual machine is located is disguised as the IP address of one end tap-in-qrouter of the vetouter path added into the qrouter virtual router, so that the communication between an external network and the virtual machine built in the external network through the OpenStack host is realized, and through the iptables DNAT technology in Linux, under the condition that a plurality of virtual machines in the OpenStack are not allocated with floating IP addresses, the access of the external host to the plurality of virtual machines in the OpenStack is realized, and the floating IP addresses are saved.

In the network architecture of the OpenStack, an OpenStack host cannot directly communicate with a virtual machine built in the OpenStack host, so that if the virtual machine is accessed by using an iptables DNAT form, the problem that the OpenStack host and the virtual machine built by the OpenStack host cannot communicate with each other needs to be solved. The OpenStack host and the virtual machine created by the OpenStack host cannot communicate with each other, the schematic diagram before and after the implementation of the invention is shown in fig. 3, the OpenStack host and the virtual machine cannot communicate with each other before the implementation of the invention, and after the implementation of the invention, the communication between the OpenStack host and the virtual machine is realized by adding one end of a veth pair into the OpenStack host and adding the other end of the veth pair into a qrouter virtual router of a current tenant.

In OpenStack, network isolation among different tenants is realized through a namespace mechanism under Linux, and OpenStack can create a namespace space for each network. The requirement that a plurality of different networks under the same tenant need to access each other can be realized by adding different networks into the same virtual route in a mode of adding the virtual route. In OpenStack, as shown in fig. 4, the virtual routing is also implemented by namespace of Linux.

As shown in fig. 4, the network card of the host is not added to any namespace, and therefore cannot communicate with the virtual machine in the OpenStack, as shown in fig. 4, a qrouter virtual router generally exists in the same tenant, and is used for connecting different networks, so that the different networks can be accessed to each other. Therefore, if it is desired to enable the OpenStack host to access the virtual machine created therein, the network of the host needs to be added to the qrounter virtual router, so that mutual access between the OpenStack host and the virtual machine created therein can be achieved, and communication between an external network and the virtual machine created therein through the OpenStack host is further achieved.

The OpenStack host is regarded as a softrouter, and the flow for accessing different ports on the OpenStack host is forwarded to a real virtual machine through the iptables DNAT rule in the OpenStack host, so that a plurality of virtual machines in the OpenStack host can be accessed externally under the condition of not binding floating IP addresses, the use of the floating IP addresses is reduced, the waste of the floating IP addresses is avoided, and the OpenStack host is closer to a real production environment (client) network. As shown in fig. 2.

The invention provides a method for realizing communication between an OpenStack virtual machine and the outside, which is applied to a system at least comprising an OpenStack host and an external network machine, wherein a plurality of OpenStack virtual machines are established in the OpenStack host, and the method comprises the following steps:

establishing a qrouter virtual router in an OpenStack host machine;

adding a default gateway of a network where an OpenStack virtual machine is located into a network of namespace where a qrouter virtual router is located, and generating a network card qr-eth0 in the namespace;

creating a pair of path pair, tap-in-qrouter and tap-in-host in an OpenStack host;

adding tap-in-qrouter at one end of a veth pair into the qrouter virtual router;

setting a default route in namespace where a qrouter virtual router is located, wherein the IP address of the default route is the same as the IP address of a tap-in-host at one end of a veth pair added into an OpenStack host;

setting an iptables outlet source address camouflage in namespace where a qrouter virtual router is located, and camouflage a network outlet source IP address where an OpenStack virtual machine is located as a path pair and adding the path pair into an IP address of tap-in-qrouter at one end of the qrouter virtual router;

and setting the system forwarding and iptables forwarding functions in namespace where the qrouter virtual router is located to be in an open state.

Preferably, the method further comprises setting that all default gateways of all OpenStack virtual machines point to a network card qr-eth0 in the qrouter virtual router.

Preferably, the method also comprises the step of configuring the IP addresses of the same network segment for the tap-in-qrouter and the tap-in-host at the two ends of the path pair.

Preferably, a mapping relationship between an OpenStack host iptables DNAT port and a plurality of ports of the OpenStack virtual machine created by the OpenStack host is established in the OpenStack host.

Preferably, the method further comprises the step of,

setting tap-in-qrouter at one end of a veth path virtual router as an enabled state;

setting tap-in-host of a veth path at one end of an OpenStack host machine as an enabled state.

Preferably, a routing rule is set in the OpenStack host, so that a data packet with a destination address of an intranet IP segment of the OpenStack virtual machine is routed to a tap-in-qrouter at one end of the veth pair added into the qrouter virtual router.

Preferably, after the OpenStack host creates the qrounter virtual router, adding a default gateway of a network where the OpenStack virtual machine is located to a network of a namespace where the qrounter virtual router is located, and searching information of the namespace where the qrounter virtual router is located by using a Linux command ip netns.

Preferably, the information of namespace where the qrouter virtual router is located includes: the unique identification id of namespace of the qrounter virtual router, the IP address of a network card in the qrounter virtual router, a default routing rule in the qrounter virtual machine router and an iptables rule in the qrounter virtual machine router are achieved.

Preferably, the setting of the iptables egress source address masquerading specifically comprises:

and setting a MASQUEERADE masquerading rule on a POSTROUTING chain of an NAT table in iptables, and masquerading a network outlet source IP where the OpenStack virtual machine is positioned as a path pair and adding an IP address of tap-in-qrouter at one end of a qrouter virtual router.

Preferably, a plurality of virtual machines created by the OpenStack host are located in the same namespace or in different namespaces, and the plurality of virtual machines created in the same namespace allocate internal IP addresses of the same network segment.

Compared with the prior art, the invention has the following beneficial effects:

(1) according to the invention, by utilizing the path pair and iptables technology under Linux, the OpenStack host computer network is communicated with the virtual machine network built inside the OpenStack host computer network, so that the mutual communication between the OpenStack host computer and the virtual machine built by the OpenStack host computer is realized, and further, the communication between the OpenStack virtual machine and the outside is realized.

(2) The invention reduces the number of bound floating IP addresses and saves floating IP address resources by utilizing the iptables DNAT technology under Linux.

(3) According to the invention, source address camouflage is carried out through the path pair and the iptables SNAT, and the OpenStack virtual machine realizes external communication under the condition that an external floating IP address is not bound.

Drawings

FIG. 1 is a diagram illustrating a prior art method for an external host to access a virtual machine in OpenStack;

FIG. 2 is a schematic diagram of mapping multiple ports of an OpenStack host machine with a virtual machine through iptables DNAT to enable the virtual machine to be externally accessed;

FIG. 3 is a schematic diagram of the communication between an OpenStack host and a virtual machine before and after the implementation of the present invention;

FIG. 4 is a schematic diagram of different network communications implemented by a virtual router;

FIG. 5 is a schematic diagram of a process of accessing a host by an OpenStack virtual machine according to the present invention; the following routes exist in the graph:

qrouter namespace routing table:

routing table in OpenStack host:

routing table in KVM virtual machine:

FIG. 6 is a schematic diagram of a process of accessing a virtual machine by an OpenStack host according to the present invention; there are routes as listed in the figure 5 illustration;

FIG. 7 is a diagram illustrating a packet stacking process according to the present invention; the external machine needs to access the virtual machine in the OpenStack: 10.10.10.10: 22;

among these are the following routes:

qrouter namespace routing table:

routing table in OpenStack host:

routing table in KVM virtual machine:

among them are the following port mappings:

the OpenStack host has iptables DNAT rules:

192.168.130.10:10000->10.10.10.10:22

FIG. 8 is a diagram illustrating a process of popping a packet according to the present invention; there are routes as listed in the figure illustration of figure 7;

Detailed Description

The following detailed description of the embodiments of the present invention is provided in conjunction with the accompanying drawings of fig. 1-8.

establishing a qrouter virtual router in an OpenStack host machine; the qrouter virtual router is realized by a namespace technology under Linux.

the OpenStack virtual machine network is assumed as follows: 10.10.10.0/24, gateway specified: 10.10.10.1, when a qrounter virtual router is created and a default gateway of a network where an OpenStack virtual machine is located is added to the qrounter virtual router, the IP of a qr-eth0 network card is: 10.10.10.1.

creating a pair of path pair, tap-in-qrouter and tap-in-host in an OpenStack host; creating the path, using the command as: ip link add tap-in-host type drive name tap-in-qrouter.

The veth Pair is a short for Virtual Ethernet Pair, and is a Pair of ports, and all data packets entering from one end of the Pair of ports will come out from the other end, and vice versa.

commands may be employed: ip netns exec xec qroute-57 dae5f9-e424-4996-b1cd-b08b5df373c0 route add default gw 192.168.40.10; wherein the 'qrouter-57 dae5f9-e424-4996-b1cd-b08b5df373c 0' is the unique identifier of namespace of the qrouter virtual router, and the 192.168.40.10 is the IP address of a tap-in-host at one end of the veth pair added to the OpenStack host.

Setting an iptables outlet source address camouflage in namespace where a qrouter virtual router is located, and camouflage a network outlet source IP address where an OpenStack virtual machine is located as a path pair and adding the path pair into an IP address of tap-in-qrouter at one end of the qrouter virtual router; used for communicating with the default route (the same as the IP address of the end tap-in-host of the veth pair joining the OpenStack host) in namespace where the qrouter virtual router is located.

Through the above setting, all data packets arriving at the network card qr-eth0 can be added into a tap-in-qrounter at one end of the qrounter virtual router through the veth path, and arrive at a tap-in-host at the other end of the veth path added into the OpenStack host.

The following command can be adopted to perform the spoofing of the iptables egress source address in the namespace where the qrouter virtual router is located: ip netns exec qroute-57 dae5f9-e424-4996-b1cd-b08b5df373c0 iptables-t nat-A POSTROUTING-s 10.10.10.0/24-j MASQUERIADE; wherein "10.10.10.0/24" is an iptables to-be-disguised source address in namespace where the qrouter virtual router is located, namely, the OpenStack virtual machine network, "qrouter-57 dae5f9-e424-4996-b1cd-b08b5df373c 0" is a unique identifier of the namespace of the qrouter virtual router, and the disguised source IP address is an IP address of a tap-in-qrouter at one end of the vetouter pair added to the qrouter virtual router.

As a preferred embodiment, the method further includes setting that all default gateways of all OpenStack virtual machines point to a network card qr-eth0 in the qrouter virtual router. With this setting, the packets sent by the OpenStack virtual machine will be forwarded through qr-eth 0. In addition, the data packet sent by the OpenStack virtual machine can reach a tap-in-host at one end of the path _ path.

As a preferred embodiment, configuring the IP addresses of the same network segment for the tap-in-qrouter and the tap-in-host at the two ends of the path pair.

Setting a path to be added into an IP address of a tap-in-host at one end of an OpenStack host, and adopting a command: ip addr 192.168.40.10/24dev tap-in-host; specifying an IP address of 192.168.40.10/24;

setting an IP address of a tap-in-qrouter at one end of a veth path added into a qrouter virtual router, and adopting a command: ip netns exec qrounter-57 dae5f9-e424-4996-b1cd-b08b5df373c0 ip addr add 192.168.40.20/24dev tap-in-qrounter; specifying an IP address of 192.168.40.20/24; wherein, the 'qrouter-57 dae5f9-e424-4996-b1cd-b08b5df373c 0' is the namespace unique identifier of the qrouter virtual router.

As a preferred embodiment, a mapping relationship between ports of OpenStack host iptables DNAT and ports of a plurality of OpenStack virtual machines created by OpenStack host is established in the OpenStack host.

The OpenStack host is regarded as a softrouter, the mapping between the port of the OpenStack host and the port of the OpenStack virtual machine is established through the iptables DNAT rule in the OpenStack host, and the flow for accessing different ports on the OpenStack host is forwarded to the real bound virtual machine, so that the multiple virtual machines in the OpenStack host can be accessed externally under the condition that the floating IP address is not bound, and the use of the floating IP address is reduced.

As a preferred embodiment, there is also included,

setting tap-in-qrouter at one end of a veth path virtual router as an enabled state; commands may be employed: ip netns exec qrouter-57dae5f9-e424-4996-b1cd-b08b5df373c0 ip link set tap-in-qrouter up.

Setting tap-in-host of a veth path at one end of an OpenStack host machine as an enabled state; commands may be employed: ip link set tap-in-host up.

As a preferred embodiment, the method further comprises the step of setting a routing rule in the OpenStack host, so that a data packet with a destination address of an intranet IP segment of the OpenStack virtual machine is routed to a port pair added to a port-in-qrouter of the qrouter virtual router.

Commands may be used: route add-net 10.10.10.0netmask 255.255.255.0gw 192.168.40.20; wherein "10.10.10.0" is an intranet IP segment of the OpenStack virtual machine, and "192.168.40.20" is an IP address of a tap-in-qrouter at one end of the vet pair added to the qrouter virtual router.

As a preferred embodiment, after the OpenStack host creates a qrounter virtual router, adding a default gateway of a network where the OpenStack virtual machine is located to a network of a namespace where the qrounter virtual router is located, and searching information of the namespace where the qrounter virtual router is located by using a Linux command ip netns;

as a preferred embodiment, the information of namespace where the qrouter virtual router is located includes: the unique identification id of namespace of the qrounter virtual router, the IP address of a network card in the qrounter virtual router, a default routing rule in the qrounter virtual machine router and an iptables rule in the qrounter virtual machine router are achieved.

The Linux command ip netns is in the form of namespace unique identification of the qrouter virtual router obtained through query: qrouter-57dae5f9-e424-4996-b1cd-b08b5df373c 0.

As a preferred embodiment, the setting of the iptables egress source address masquerading specifically includes:

As a preferred embodiment, multiple virtual machines created by an OpenStack host are located in the same namespace or in different namespaces, and multiple virtual machines created in the same namespace allocate internal IP addresses of the same network segment.

Example 1

The process provided by the present invention is described in detail with reference to FIGS. 1-8, according to one embodiment of the present invention. Fig. 5 shows the procedure of accessing the host by the OpenStack virtual machine, fig. 6 shows the procedure of accessing the OpenStack virtual machine by the OpenStack host, and the packet flow direction is opposite to that in fig. 5, but the routing table is the same as that listed in the figure description of fig. 5.

Take the following IP address configurations as examples:

IP address of tap-in-host: 192.168.40.10/24;

IP address of tap-in-qrounter: 192.168.40.20/24;

the network IP address field of the OpenStack virtual machine: 10.10.10.0/24;

OpenStack virtual machine network gateway address: 10.10.10.1;

OpenStack host IP address: 192.168.130.10/24;

the multiple virtual machines created by the OpenStack host are located in the same namespace or different namespaces, and the multiple virtual machines created in the same namespace are distributed with the internal IP address of the same network segment.

Searching information of namespace where the qrouter virtual router is located by using a Linux command ip netns;

the information of namespace where the qrouter virtual router is located comprises the following information: the unique identification id of namespace of the qrounter virtual router, the IP address of a network card in the qrounter virtual router, a default routing rule in the qrounter virtual machine router and an iptables rule in the qrounter virtual machine router are achieved.

and setting all default gateways of all OpenStack virtual machines to point to a network card qr-eth0 in the qrouter virtual router. With this setting, the packets sent by the OpenStack virtual machine will be forwarded through qr-eth 0.

configuring IP addresses of the same network segment for tap-in-qrouter and tap-in-host at two ends of veth pair:

Setting the spoofing of the iptables outlet source address specifically comprises the following steps:

Setting system forwarding and iptables forwarding functions in namespace where the qrouter virtual router is located to be in an open state;

and establishing a mapping relation between an OpenStack host iptables DNAT port and a plurality of ports of the OpenStack virtual machines established by the OpenStack host in the OpenStack host.

And setting a routing rule in the OpenStack host machine, so that a data packet with a destination address of an intranet IP (Internet protocol) segment of the OpenStack virtual machine is routed to a port pair added to one end of a qrouter virtual router.

EXAMPLE 2

By adopting the method of the invention, with reference to the attached figure 7, the OpenStack host, the virtual machine, the qrouter router, the veth pair and the routing rule are set as follows:

the IP address of the OpenStack host is as follows: 192.168.130.10/24, open port to the outside: 10000;

the IP address of the OpenStack virtual machine 1 is: 10.10.10.10/24, open port to the outside: 22;

the IP address of the OpenStack virtual machine 2 is: 10.10.10.11/24;

4. external PC IP Address: 192.168.128.11/24;

the following DNAT rules exist in iptables for an OpenStack host: DNAT tcp-0.0.0.0/0192.168.130.10 tcp dpt: 10000 to: 10.10.10.10:22, access 192.168.130.10: 10000 packets are forwarded to 10.10.10.10: 22;

6. the method comprises the steps that iptables FORWARD in an OpenStack host machine and system opening permission forwarding are set;

configuring IP addresses at two ends of the path: tap-in-host 192.168.40.10/24; tap-in-qrouter 192.168.40.20/24;

the default route setting in namespace where qrouter is located is 192.168.40.10/24;

9, the IP address of the network card q-eth0 in namespace where the qrouter is located is: 10.10.10.1/24;

the following POSTROUTING rule exists for iptables in namespace where qrouter is located: MASQUERED all- -10.10.10.0/240.0.0.0, i.e. Source IP 10.10.10.0/24 Access to any destination IP, MASQUERADE export Source IP (SNAT)

Iptables FORWARD and system open in namespace where the qrouter is located allow forwarding;

the default gateways of all the virtual machines in the OpenStack point to the IP address 10.10.10.1/24 of q-eth 0;

the following routing rules exist in the OpenStack hosts: 10.10.10.0192.168.40.20255.255.255.0U 000 tap-in-host, namely, the route (next hop) for accessing 10.10.10.0/24 is 192.168.40.20, and the route is sent through a tap-in-host network card;

the configuration is performed according to the method of the present invention, so that the access of the external machine to the OpenStack virtual machine can be realized, referring to fig. 7, the process of pushing the data packet from the external PC into the OpenStack virtual machine 1 is as follows:

1. the data packet transmitted from the external PC arrives at the OpenStack host first: 192.168.130.10: 10000, host iptables detects DNAT rules that a hit exists: access 192.168.130.10: 10000 packets are forwarded to 10.10.10.10: 22/24, so forwarding the packet to the OpenStack virtual machine 1: 10.10.10.10: 22/24, respectively;

2. when the data packet is forwarded to the OpenStack virtual machine 1: 10.10.10.10: 22/24, the OpenStack host inquires the system and the iptables forwarding table to determine whether to allow forwarding;

3. after confirming that forwarding is allowed, the OpenStack host checks the OpenStack virtual machine 1 in the system routing table: 10.10.10.10: 22/24 direction of the next hop of the package;

4. an OpenStack virtual machine 1 exists in a system routing table: 10.10.10.10: 22/24 the package next hop is described as: the next hop of the 10.10.10.0/24 package is 192.168.40.20/24 and is sent through a tap-in-host network card;

5. before sending, the user firstly passes through a POSTROUTING chain of iptables in the system, and the condition that no rule before sending needs to be matched is determined;

and 6, the OpenStack host forwards the data packet to a next hop 192.168.40.20/24 through a tap-in-host network card, and due to the presence of the veth pair, the tap-in-qrounter: 192.168.40.20/24 will receive the data packet;

tap-in-qrounter: 192.168.40.20/24, finding that the data packet is not for itself and needs to be forwarded after receiving the data packet, and the tap-in-qrounter inquiring the system in namespace and iptables forwarding table to see whether to allow forwarding;

8. after confirming that forwarding is allowed, the tap-in-qrounter looks at the OpenStack virtual machine 1 in the system routing table: 10.10.10.10: 22/24 direction of the next hop of the package;

9. an OpenStack virtual machine 1 exists in the system route: 10.10.10.10: 22/24 the package next hop is described as: the next hop of the 10.10.10.0/24 packet is 10.10.10.1/24 and is sent through a qr-eth0 network card;

10. before sending, the user firstly passes through a POSTROUTING chain of iptables in the system, and the condition that no rule before sending needs to be matched is determined;

after forwarding the data packet to the next hop qr-eth0 network card 10.10.10.1/24 by the tap-in-qrouter and receiving the data packet by the next hop qr-eth0 network card 10.10.10.1/24, finding that the data packet belongs to the same WLAN, then sending an ARP to the target virtual machine 1, and inquiring the target virtual machine 1: 10.10.10.10/24, the packet is delivered to the final destination virtual machine 1.

Example 3

According to the setting of the OpenStack host, the virtual machine, the qrouter router, the veth pair, and the routing rule in embodiment 2, the communication between the external PC and the OpenStack virtual machine can be realized, where the routing is the same as that in embodiment 2 when the packet is stacked, and the packet flow direction is opposite. Referring to fig. 8, the process of popping the data packet from the OpenStack virtual machine 1 to the external PC is as follows:

an OpenStack virtual machine 1: 10.10.10.10/24 loopback, destination IP: 192.168.128.11/24, searching the matching routing table (the destination IP and Genmask in the routing table do AND operation), and finally obtaining the next hop as: 10.10.10.1/24, sending through an eth0 network card, passing through a POSTROUTING chain of iptables in the system before sending, and finally sending the data packet to 10.10.10.1/24 through an eth0 network card of the OpenStack virtual machine 1 when no rule before sending needs to be matched;

qr-eth 0: 10.10.10.1/24, after receiving the data packet, finding that the target IP is not the self and needs to be forwarded out, and querying a system and an iptables forwarding table in the namespace by qr-eth 0to see whether forwarding is allowed or not;

3. after the forwarding is confirmed to be allowed, qr-eth0 searches a matching routing table, and finally the next hop is obtained as: 192.168.40.10/24, sending through a tap-in-qrounter network card, passing through a POSTROUTING chain of iptables in the system before sending, and seeing that no rule before sending needs matching processing;

4. there is one in the POSTROUTING chain at this time: MASQUERED all- -10.10.10.0/240.0.0.0, i.e. source IP 10.10.10.0/24 access any destination IP, masquerading export source IP (SNAT). And finally, the pseudo-source IP is the IP of a tap-in-qrounter network card, a data packet is sent to 192.168.40.10/24 through the tap-in-qrounter network card, and due to the presence of the path pair, the value of the tap-in-host: 192.168.40.10/24 will receive the data packet;

tap-in-host: 192.168.40.10/24 finds that the target IP is not self and needs to be forwarded after receiving the data packet, and the tap-in-host inquires a system and an iptables forwarding table in the OpenStack host to see whether forwarding is allowed or not;

6. after the forwarding is confirmed to be allowed, the tap-in-host searches a matching routing table, and finally the next hop is obtained as: 192.168.130.1/24, sending through an eth0 network card, passing through a POSTROUTING chain of iptables in the system before sending, and finally sending a data packet to 192.168.130.1/24 through an eth0 network card of an OpenStack host after seeing that no rule before sending needs to be matched;

7. the data packet is finally sent to a final destination IP by an 192.168.130.1/24 upper layer switch or router: 192.168.128.11/24

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for realizing communication between an OpenStack virtual machine and the outside is applied to a system at least comprising an OpenStack host and an external network machine, wherein a plurality of OpenStack virtual machines are established in the OpenStack host, and the method is characterized by comprising the following steps:

establishing a qrouter virtual router in an OpenStack host machine;

2. The method of claim 1, further comprising setting all default gateways of the OpenStack virtual machines to point to a network card qr-eth0 in a qrouter virtual router.

3. The method for enabling the OpenStack virtual machine to communicate with the outside as claimed in claim 1, further comprising configuring IP addresses of the same network segment for a tap-in-qrouter and a tap-in-host at both ends of a veth pair.

4. The method for enabling the OpenStack virtual machine to communicate with the outside as claimed in claim 1, further comprising establishing a mapping relationship between an OpenStack host iptables DNAT port and a plurality of ports of the OpenStack virtual machine created by an OpenStack host in the OpenStack host.

5. The method for enabling an OpenStack virtual machine to communicate with the outside of claim 1, further comprising,

6. The method for realizing the communication between the OpenStack virtual machine and the outside as claimed in claim 1, further comprising setting a routing rule in the OpenStack host machine, so that a data packet with a destination address of an Intranet IP segment of the OpenStack virtual machine is routed to a port-in-qrounter at one end of a veth pair joining a qrounter virtual router.

7. The method for realizing the communication between the OpenStack virtual machine and the outside as claimed in claim 1, further comprising, after the OpenStack host creates the qrouter virtual router, adding a default gateway of the network where the OpenStack virtual machine is located to the network of the namespace where the qrouter virtual router is located, and searching for the information of the namespace where the qrouter virtual router is located by using a Linux command ip netns.

8. The method of claim 7, wherein the information about namespace where the qrouter virtual router is located includes: the unique identification id of namespace of the qrounter virtual router, the IP address of a network card in the qrounter virtual router, a default routing rule in the qrounter virtual machine router and an iptables rule in the qrounter virtual machine router are achieved.

9. The method for realizing communication between an OpenStack virtual machine and the outside according to claim 1, wherein setting the iptables egress source address masquerading specifically includes:

10. The method of claim 1, wherein multiple virtual machines created by an OpenStack host are located in the same namespace or in different namespaces, and the multiple virtual machines created in the same namespace are assigned with internal IP addresses of the same network segment.