☰

Fedora Server 38 作为防火墙/网关的网络问题

tag-icon • tag-icon gateway masquerade firewall-cmd fedora-server fedora-38
Fedora Server 38 作为防火墙/网关的网络问题

这个环境几乎所有东西都是双胞胎，包括两个 Web 服务器/防火墙/网关系统，而且它们的版本已经过时了，所以我决定升级其中Fedora Server 30 to 38一个。当然，我的想法是让两者都“进入现代时代”，但每次只能升级一个。

我的时间安排很奇怪，因为就在我开始升级的同时，甚至没有接触（物理或电子）另一台服务器，它就决定失败了！所以，现在我有一个“服务器宕机”的情况。-呃-不幸的是，这也意味着我没有一个可以查看的工作示例。

我没有触及的那个显然有硬件问题，我现在无法解决，所以我专注于我已经开始的那个，它现在已经从升级/更新到 Fedora Server 38 中很好地出现了……除了它有一个问题，它没有作为一个实际的网关！确认！

明确地说，通过它可以顺利访问互联网和内部网络。但它不会通过它传递数据。

当然，这都是通用的 Fedora 服务器（Fedora Core 38 对服务器版本进行了任何调整），并且 30 和 38 之间的任何差异都可能是巨大的，但这里重要的是网络。

它有两个 NIC，我按原样配置它们（即 IP 地址、掩码等），事实上，安装过程似乎很有帮助，因为它帮助我识别哪个 NIC 是内部的，哪个是外部的。我利用了过去的经验，非常确定我做对了。

确实，一旦启动，我就能立即通过 ssh 通过内部网络访问该盒子。而且，在这样的系统上有很多事情要做，但很快我就遇到了防火墙方面的问题。（那时我还没有意识到另一个系统没有响应。）

我做的第一件事是将接口移至内部和外部区域，然后在外部区域上启用伪装。我使用 forward-port 命令等转发邮件，最终外部区域如下所示：

# firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources:
  services: http https ssh
  ports:
  protocols:
  forward: yes
  masquerade: yes
  forward-ports:
        port=25:proto=tcp:toport=25:toaddr=192.168.1.1
  source-ports:
  icmp-blocks:
  rich rules:

另外，内部的：

# firewall-cmd --zone=internal --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources:
  services: dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

顺便说一句，我没有向内部区域添加任何服务 - 我猜它们显然只是默认服务。

我花了很多时间研究路由，因为一开始它对我来说就很古怪。然而，现在它变成了这样：

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router           0.0.0.0         UG    100    0        0 enp1s0
router           0.0.0.0         255.255.255.255 UH    100    0        0 enp1s0
192.168.1.1     0.0.0.0         255.255.255.0   U     101    0        0 enp2s0
192.168.1.1     0.0.0.0         255.255.255.0   U     101    0        0 enp2s0

仅供参考，此版本的 Fedora 不使用 IP 表，而是使用网络管理器 - 这是我从一开始就讨厌的工具集，但现在似乎更成熟了。无论如何，网络上可以找到的大多数资料都谈到了这种较旧的策略，并且毫无帮助。但是，这个页面为人们指明了正确的总体方向。

更新 1

我拿到了显然已经发生故障的旧硬件。这并不难，但它增加了我们修复的几率。……我说“我们的”，是因为一位同事也加入了我的行列；他专注于旧机器，而我专注于新机器。

两者都不是作为网关/防火墙传递数据，这让我很困惑。不过我的同事提醒说，一个系统已经不能正常工作了，可能是因为尝试安装某个特定的 OpenVPN 时出现了失误。既然他做了这项工作，那么他将继续在那里工作。

这必定是一件简单的事情；我们忽略了什么基本原理？！

答案1

dhcpv6-client事实证明，系统阻止了除、、和mdns之外的所有服务的直通，因为这些服务已配置为已接受。samba-clientssh

从某种意义上说，它确实运行正常，只是没有配置为传输所有位。

任何改变来自内部接口的数据包的接受的防火墙指令（无论如何实现）都会改变这种情况，无论是通过firewall-cmd或nmcli命令还是通过配置文件（例如）实现/etc/NetworkManager/system-connections/enp1s0.nmconnection。

从实际情况来看，最快的选择是针对内部界面进行以下更改之一：

  1. 将接口置于“受信任”区域，或者;

  2. 启用每个单独的“服务”和/或端口（这对于我们这些刚刚发明了自己的服务的人来说很烦人 - 你知道，“黑客”就是这样做的......），或者；

  3. 将内部区域的“目标”设置为“接受”，如下所示：firewall-cmd --zone=internal --set-target=ACCEPT，或者；

请注意，我从未尝试过选项 3，但根据文档，它应该可行。

在我看来，安全架构是有缺陷的，鉴于网络管理器仍在进行实质性开发，我将发表这些评论，希望能够拓展对此事的思考。即：

它已经具备了基本功能，但人为地限制了灵活性，应该加以改进。请注意，它已经必须执行布尔检查，以确定区域是否恰好被称为“受信任”，因此将“受信任”设置为所有区域的单比特属性更有意义。这将允许权限是加法或减法；如果位为零，则从不允许任何内容的前提开始，然后列出例外，或者如果设置，则使用允许所有内容的前提，然后列出例外。这是设计得更好（通常是大型的）、复杂的软件包做事的方式，例如，BigSur 系统，例如，它提供了这种安全逻辑 - 要么增加要么减少；您要么授予所有权限然后明确删除，要么不授予任何权限然后添加一些权限。对于系统管理来说，这要快得多，也更容易理解，而不是出现一个奇怪的例外，比如区域恰好被命名为“受信任”。

但是，我读到过，网络管理器的初衷是服务于不太熟练的普通用户，因为 IP 表被认为太难处理了。（虽然 IP 表很有挑战性，但网络管理器人员不得不屈服于它的复杂性，使用“丰富的规则”。……但我离题了。

相关内容