firewall-cmd 表示没有活动的防火墙区域。为什么？

Question

在 Debian 9 上，我安装了firewalld（版本0.4.4.2-1）。

\n\n

sudo firewall-cmd --get-active-zones显示没有输出。并echo $?显示退出状态为 0 ( EXIT_SUCCESS)。为什么？

\n\n

我有一个网络接口eth0，由ip link（以及环回接口lo。

\n\n

---

\n\n

我应该说我的防火墙配置似乎大部分正常工作。FWIW，我已将默认区域从 更改为public，MyZone定义如下：

\n\n

$ sudo cat /etc/firewalld/zones/MyZone.xml\n<?xml version="1.0" encoding="utf-8"?>\n<zone>\n  <short>My Zone</short>\n  <service name="ssh"/>\n  <service name="https"/>\n  <!-- ... --> \n</zone>\n

\n\n

如果我尝试使用另一台计算机进行连接，我可以访问 SSH 和 HTTPS 服务。如果我ncat -l -p 8000在服务器上运行并尝试连接ncat my-server 8000，则连接会被正确阻止。（Ncat: No route to host. 并tcpdump显示生成了 ICMP 无法到达的回复，输入“管理员禁止”）。

\n\n

为什么firewall-cmd --get-active-zonesMyZone 不显示为活动状态？

\n\n

$ sudo firewall-cmd --state                                                                                                         \nrunning\n$ sudo firewall-cmd --get-active-zones\n$ echo $?\n0\n$ sudo firewall-cmd --get-default-zone\nMyZone\n$ ip addr show dev eth0\n2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000\n    link/ether 00:50:43:01:c0:ab brd ff:ff:ff:ff:ff:ff\n    inet 172.16.1.8/24 brd 172.16.1.255 scope global eth0\n       valid_lft forever preferred_lft forever\n    inet6 fd5e:fcf3:b885:0:250:43ff:fe01:c0ab/64 scope global mngtmpaddr dynamic\n       valid_lft forever preferred_lft forever\n    inet6 fe80::250:43ff:fe01:c0ab/64 scope link\n       valid_lft forever preferred_lft forever\n

\n\n

firewalld.service不记录任何警告。

\n\n

$ sudo systemctl status firewalld\n\xe2\x97\x8f firewalld.service - firewalld - dynamic firewall daemon\n   Loaded: loaded (/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)\n   Active: active (running) since Wed 2019-01-30 13:17:31 GMT; 56min ago\n     Docs: man:firewalld(1)\n Main PID: 509 (firewalld)\n    Tasks: 2 (limit: 4915)\n   CGroup: /system.slice/firewalld.service\n           \xe2\x94\x94\xe2\x94\x80509 /usr/bin/python3 -Es /usr/sbin/firewalld --nofork --nopid\n\nJan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...\nJan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.\n

\n\n

---

\n\n

我发现它firewalld更喜欢与 NetworkManager 一起使用。我目前没有运行 NetworkManager，听起来这有点脆弱。

\n\n

\n

https://firewalld.org/documentation/concepts.html

\n\n

如果不使用 NetworkManager，则会有一些限制...如果在网络已经启动后启动firewalld，则连接和手动创建的接口不会绑定到区域。

\n

\n\n

但是，自从安装以来我至少重新启动过一次firewalld。我检查了systemd服务。 firewalld.service已开始Before=network-pre.target。 networking.service已开始After=network-pre.target。我已经确认firewalld之前已启动networking.service：

\n\n

$ sudo journalctl -b -u networking -u firewalld\n-- Logs begin at Sat 2019-01-26 04:15:01 GMT, end at Wed 2019-01-30 14:15:33 GMT. --\nJan 30 13:17:21 brick systemd[1]: Starting firewalld - dynamic firewall daemon...\nJan 30 13:17:31 brick systemd[1]: Started firewalld - dynamic firewall daemon.\nJan 30 13:17:31 brick systemd[1]: Starting Raise network interfaces...\nJan 30 13:17:37 brick systemd[1]: Started Raise network interfaces.\n

\n\n

我没有手动重新启动网络或运行ifdown/ ifup，并且我没有运行ifplugd。内核日志（如下）表明以太网链路已启动，并且 IPv6 自启动以来一直在持续运行。

\n\n

$ sudo dmesg|grep eth0\n[    4.082350] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:50:43:01:c0:ab\n[   47.577570] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready\n[   49.981569] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled\n[   49.991543] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready\n

\n\n

我什至没有使用 DHCP。eth0in的配置/etc/network/interfaces是

\n\n

auto eth0\niface eth0 inet static\n    address 172.16.1.8\n    netmask 255.255.255.0\n    gateway 172.16.1.1\n    dns-nameservers 172.16.1.1\n

\n

Answer 1

firewalld不依赖于NetworkManager，但推荐使用。

他们不是在开玩笑。

在没有 NetworkManager 的情况下，网页文档继续说您需要在两个不同位置的配置之间复制/保持一致性。

另外，这两个地方中的第一个是ifcfg网络配置系统，Debian 上不存在该系统。言外之意，Debian 上需要 NetworkManager :-)。

（综合各种信息，很明显，只有在启动网络接口后/etc/firewalld/手动启动时才需要 中的重复配置。这包括重新启动，尽管您通常不希望重新启动。）firewalldfirewalldfirewalld

一方面，可以公平地预期在问题中观察到的具体“主要工作”行为。根据其他文档和进一步的观察，您可以合理地预期默认区域将应用​​于您的接口。

在没有 NetworkManager 的 Debian 上，将接口分配给不同的区域可能会在正在运行的系统上工作，但在重新启动时无法工作。

您可能希望对防火墙有超过“合理的期望”。如果您可以使用“推荐”配置，则更令人放心，该配置在firewalld更改时可能会得到更好的测试，而不必依赖于这种令人困惑的行为。

我仍然对其影响感到困惑，包括对红帽系统的影响。当未能正确保存区域配置时，firewall-cmd --permanent --add-interface=...可以字面显示结果“ ”，这是非常令人困惑的！success

以下是相关引用man firewalld：

如果未使用 NetworkManager 并且在网络启动后启动了firewalld，则连接和手动创建的接口不会绑定到 ifcfg 文件中指定的区域。接口将自动由默认区域处理。firewalld 也不会收到有关网络设备重命名的通知。NM_CONTROLLED=no如果设置了，所有这些也适用于不受 NetworkManager 控制的接口 。

您可以使用以下命令将这些接口添加到区域中

firewall-cmd [--permanent] --zone=zone --add-interface=interface

如果有 /etc/sysconfig/network-scripts/ifcfg-interface文件，firewalld 会尝试更改ZONE=zone该文件中的设置。

如果重新加载firewalld，它将恢复重新加载之前的接口绑定，以在NetworkManager不受控制的接口的情况下保持接口绑定稳定。在firewalld服务重新启动的情况下，这种机制是不可能的。

ZONE=对于 NetworkManager 不受控制的接口，必须保持ifcfg 文件中的设置与 firewalld 中的绑定一致。

作为实验，我尝试了提到的命令：

$ sudo firewall-cmd --zone=MyZone --add-interface=eth0
$ sudo firewall-cmd --get-active-zones
MyZone:
  interfaces: eth0

如果我的网络接口是在 后启动的，则此行为正是您从文档中所期望的firewalld。但是我的网络接口在 后没有启动firewalld。

该man页面听起来像是依赖于在启动网络接口时firewalld获取回调。ifcfg不过ifcfg是Red Hat的网络系统；它没有安装在我的 Debian 系统上。Debian 软件包似乎firewalld没有提供任何等效项。因此我们降级为“接口将自动由默认区域处理”。

我跑去sudo iptables-save查看 .iptables 生成的 iptables（仅限 IPv4）规则firewalld。如果我没有手动运行的话firewall-cmd --add-interface...，就没有提及了eth0。但如果我没看错的话，规则会使用默认区域的规则来处理此类数据包，作为后备。