- 16 4月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Since: commit 9f4e35dc Author: Daniel P. Berrangé <berrange@redhat.com> Date: Mon Mar 18 17:31:21 2019 +0000 network: improve error report when firewall chain creation fails We cache an error when failing to create the top level firewall chains. This commit failed to account for fact that we may invoke networkPreReloadFirewallRules() many times while libvirtd is running. For example when firewalld is restarted. When this happens the original failure may no longer occurr and we'll successfully create our top level chains. We failed to clear the cached error resulting in us failing to start virtual networks. Reviewed-by: NLaine Stump <laine@laine.org> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 19 3月, 2019 2 次提交
-
-
由 Daniel P. Berrangé 提交于
During startup libvirtd creates top level chains for both ipv4 and ipv6 protocols. If this fails for any reason then startup of virtual networks is blocked. The default virtual network, however, only requires use of ipv4 and some servers have ipv6 disabled so it is expected that ipv6 chain creation will fail. There could equally be servers with no ipv4, only ipv6. This patch thus makes error reporting a little more fine grained so that it works more sensibly when either ipv4 or ipv6 is disabled on the server. Only the protocols that are actually used by the virtual network have errors reported. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
During startup we create some top level chains in which all virtual network firewall rules will be placed. The upfront creation is done to avoid slowing down creation of individual virtual networks by checking for chain existance every time. There are some factors which can cause this upfront creation to fail and while a message will get into the libvirtd log this won't be seen by users who later try to start a virtual network. Instead they'll just get a message saying that the libvirt top level chain does not exist. This message is accurate, but unhelpful for solving the root cause. This patch thus saves any error during daemon startup and reports it when trying to create a virtual network later. Reviewed-by: NAndrea Bolognani <abologna@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 02 2月, 2019 2 次提交
-
-
由 Laine Stump 提交于
Since we're setting the zone anyway, it will be useful to allow setting a different (custom) zone for each network. This will be done by adding a "zone" attribute to the "bridge" element, e.g.: ... <bridge name='virbr0' zone='myzone'/> ... If a zone is specified in the config and it can't be honored, this will be an error. Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
This patch restores broken guest network connectivity after a host firewalld is switched to using an nftables backend. It does this by adding libvirt networks' bridge interfaces to the new "libvirt" zone in firewalld. After this patch, the bridge interface of any network created by libvirt (when firewalld is active) will be added to the firewalld zone called "libvirt" if it exists (regardless of the firewalld backend setting). This behavior does *not* depend on whether or not libvirt has installed the libvirt zone file (set with "--with[out]-firewalld-zone" during the configure phase of the package build). If the libvirt zone doesn't exist (either because the package was configured to not install it, or possibly it was installed, but firewalld doesn't support rule priorities, resulting in a parse error), the bridge will remain in firewalld's default zone, which could be innocuous (in the case that the firewalld backend is iptables, guest networking will still function properly with the bridge in the default zone), or it could be disastrous (if the firewalld backend is nftables, we can be assured that guest networking will fail). In order to be unobtrusive in the former case, and informative in the latter, when the libvirt zone doesn't exist we then check the firewalld version to see if it's new enough to support the nftables backend, and then if the backend is actually set to nftables, before logging an error (and failing the net-start operation, since the network couldn't possibly work anyway). When the libvirt zone is used, network behavior is *slightly* different from behavior of previous libvirt. In the past, libvirt network behavior would be affected by the configuration of firewalld's default zone (usually "public"), but now it is affected only by the "libvirt" zone), and thus almost surely warrants a release note for any distro upgrading to libvirt 5.1 or above. Although it's unfortunate that we have to deal with a mandatory behavior change, the architecture of multiple hooks makes it impossible to *not* change behavior in some way, and the new behavior is arguably better (since it will now be possible to manage access to the host from virtual machines vs from public interfaces separately). Creates-and-Resolves: https://bugzilla.redhat.com/1650320 Resolves: https://bugzilla.redhat.com/1638342Signed-off-by: NLaine Stump <laine@laine.org> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 29 1月, 2019 3 次提交
-
-
由 Daniel P. Berrangé 提交于
The previous commit created new chains to hold the firewall rules. This commit changes the code that creates rules to place them in the new private chains instead of the builtin top level chains. With two networks running, the rules in the filter table now look like -N LIBVIRT_FWI -N LIBVIRT_FWO -N LIBVIRT_FWX -N LIBVIRT_INP -N LIBVIRT_OUT -A INPUT -j LIBVIRT_INP -A FORWARD -j LIBVIRT_FWX -A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.0.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWI -d 192.168.1.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr1 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -s 192.168.0.0/24 -i virbr0 -j ACCEPT -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -s 192.168.1.0/24 -i virbr1 -j ACCEPT -A LIBVIRT_FWO -i virbr1 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT -A LIBVIRT_FWX -i virbr1 -o virbr1 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr1 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr1 -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT While in the nat table: -N LIBVIRT_PRT -A POSTROUTING -j LIBVIRT_PRT -A LIBVIRT_PRT -s 192.168.0.0/24 -d 224.0.0.0/24 -j RETURN -A LIBVIRT_PRT -s 192.168.0.0/24 -d 255.255.255.255/32 -j RETURN -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.0.0/24 ! -d 192.168.0.0/24 -j MASQUERADE -A LIBVIRT_PRT -s 192.168.1.0/24 -d 224.0.0.0/24 -j RETURN -A LIBVIRT_PRT -s 192.168.1.0/24 -d 255.255.255.255/32 -j RETURN -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 -A LIBVIRT_PRT -s 192.168.1.0/24 ! -d 192.168.1.0/24 -j MASQUERADE And finally the mangle table: -N LIBVIRT_PRT -A POSTROUTING -j LIBVIRT_PRT -A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A LIBVIRT_PRT -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Historically firewall rules for virtual networks were added straight into the base chains. This works but has a number of bugs and design limitations: - It is inflexible for admins wanting to add extra rules ahead of libvirt's rules, via hook scripts. - It is not clear to the admin that the rules were created by libvirt - Each rule must be deleted by libvirt individually since they are all directly in the builtin chains - The ordering of rules in the forward chain is incorrect when multiple networks are created, allowing traffic to mistakenly flow between networks in one direction. To address all of these problems, libvirt needs to move to creating rules in its own private chains. In the top level builtin chains, libvirt will add links to its own private top level chains. Addressing the traffic ordering bug requires some extra steps. With everything going into the FORWARD chain there was interleaving of rules for outbound traffic and inbound traffic for each network: -A FORWARD -d 192.168.3.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.3.0/24 -i virbr1 -j ACCEPT -A FORWARD -i virbr1 -o virbr1 -j ACCEPT -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -d 192.168.2.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.2.0/24 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable The rule allowing outbound traffic from virbr1 would mistakenly allow packets from virbr1 to virbr0, before the rule denying input to virbr0 gets a chance to run. What we really need todo is group the forwarding rules into three distinct sets: * Cross rules - LIBVIRT_FWX -A FORWARD -i virbr1 -o virbr1 -j ACCEPT -A FORWARD -i virbr0 -o virbr0 -j ACCEPT * Incoming rules - LIBVIRT_FWI -A FORWARD -d 192.168.3.0/24 -o virbr1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -d 192.168.2.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable * Outgoing rules - LIBVIRT_FWO -A FORWARD -s 192.168.3.0/24 -i virbr1 -j ACCEPT -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -s 192.168.2.0/24 -i virbr0 -j ACCEPT -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable There is thus no risk of outgoing rules for one network mistakenly allowing incoming traffic for another network, as all incoming rules are evalated first. With this in mind, we'll thus need three distinct chains linked from the FORWARD chain, so we end up with: INPUT --> LIBVIRT_INP (filter) OUTPUT --> LIBVIRT_OUT (filter) FORWARD +-> LIBVIRT_FWX (filter) +-> LIBVIRT_FWO \-> LIBVIRT_FWI POSTROUTING --> LIBVIRT_PRT (nat & mangle) Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
Allow the platform driver impls to run logic before and after the firewall reload process. Reviewed-by: NLaine Stump <laine@laine.org> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 14 12月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
In many files there are header comments that contain an Author: statement, supposedly reflecting who originally wrote the code. In a large collaborative project like libvirt, any non-trivial file will have been modified by a large number of different contributors. IOW, the Author: comments are quickly out of date, omitting people who have made significant contribitions. In some places Author: lines have been added despite the person merely being responsible for creating the file by moving existing code out of another file. IOW, the Author: lines give an incorrect record of authorship. With this all in mind, the comments are useless as a means to identify who to talk to about code in a particular file. Contributors will always be better off using 'git log' and 'git blame' if they need to find the author of a particular bit of code. This commit thus deletes all Author: comments from the source and adds a rule to prevent them reappearing. The Copyright headers are similarly misleading and inaccurate, however, we cannot delete these as they have legal meaning, despite being largely inaccurate. In addition only the copyright holder is permitted to change their respective copyright statement. Reviewed-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 17 9月, 2018 1 次提交
-
-
由 Shi Lei 提交于
Signed-off-by: NShi Lei <shi_lei@massclouds.com>
-
- 27 6月, 2016 2 次提交
-
-
由 Laine Stump 提交于
These functions all need to be called from a utility function that must be located in the util directory, so we move them all into util/virnetdevip.[ch] now that it exists. Function and struct names were appropriately changed for the new location, but all code is unchanged aside from motion and renaming.
-
由 Laine Stump 提交于
I'm tired of mistyping this all the time, so let's do it the same all the time (similar to how we changed all "Pci" to "PCI" awhile back). (NB: I've left alone some things in the esx and vbox drivers because I'm unable to compile them and they weren't obviously *not* a part of some API. I also didn't change a couple of variables named, e.g. "somethingIptables", because they were derived from the name of the "iptables" command)
-
- 14 7月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
The comment above that function says: "This function can be a lot more exhaustive, ...", so let's be. Check for collisions between routes in the system and static routes being added explicitly from the <route/> element of the network XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1094205Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 23 3月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Wikipedia's list of common misspellings [1] has a machine-readable version. This patch fixes those misspellings mentioned in the list which don't have multiple right variants (as e.g. "accension", which can be both "accession" and "ascension"), such misspellings are left untouched. The list of changes was manually re-checked for false positives. [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 25 4月, 2014 2 次提交
-
-
由 Daniel P. Berrange 提交于
The networkCheckRouteCollision, networkAddFirewallRules and networkRemoveFirewallRules APIs all take a virNetworkObjPtr instance, but only ever access the 'def' member. It thus simplifies testing if the APIs are changed to just take a virNetworkDefPtr instead Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Update the iptablesXXXX methods so that instead of directly executing iptables commands, they populate rules in an instance of virFirewallPtr. The bridge driver can thus construct the ruleset and then invoke it in one operation having rollback handled automatically. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
The bridge_driver_platform.h defines many functions that a platform driver must implement. Only two of these functions are actually called from the main bridge driver code. The remainder can be made internal to the linux driver only. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 08 1月, 2014 1 次提交
-
-
由 Lénaïc Huard 提交于
When the host is configured with very restrictive firewall (default policy is DROP for all chains, including OUTPUT), the bridge driver for Linux adds netfilter entries to allow DHCP and DNS requests to go from the VM to the dnsmasq of the host. The issue that this commit fixes is the fact that a DROP policy on the OUTPUT chain blocks the DHCP replies from the host’s dnsmasq to the VM. As DHCP replies are sent in UDP, they are not caught by any --ctstate ESTABLISHED rule and so, need to be explicitly allowed. Signed-off-by: NLénaïc Huard <lenaic@lhuard.fr.eu.org>
-
- 25 9月, 2013 1 次提交
-
-
由 Laszlo Ersek 提交于
Packets sent by guests on virbrN, *or* by dnsmasq on the same, to - 255.255.255.255/32 (netmask-independent local network broadcast address), or to - 224.0.0.0/24 (local subnetwork multicast range) are never forwarded, hence it is not necessary to masquerade them. In fact we must not masquerade them: translating their source addresses or source ports (where applicable) may confuse receivers on virbrN. One example is the DHCP client in OVMF (= UEFI firmware for virtual machines): http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1506/focus=2640 It expects DHCP replies to arrive from remote source port 67. Even though dnsmasq conforms to that, the destination address (255.255.255.255) and the source address (eg. 192.168.122.1) in the reply allow the UDP masquerading rule to match, which rewrites the source port to or above 1024. This prevents the DHCP client in OVMF from accepting the packet. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=709418Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
-
- 02 8月, 2013 1 次提交
-
-
由 Roman Bogorodskiy 提交于
* Move platform specific things (e.g. firewalling and route collision checks) into bridge_driver_platform * Create two platform specific implementations: - bridge_driver_linux: Linux implementation using iptables, it's actually the code moved from bridge_driver.c - bridge_driver_nop: dumb implementation that does nothing Signed-off-by: NEric Blake <eblake@redhat.com>
-