为什么我可以在 CentOS 7 中看到我的 samba 共享,但在 Fedora 30 中却看不到?

为什么我可以在 CentOS 7 中看到我的 samba 共享,但在 Fedora 30 中却看不到?

我在 Fedora 机器上配置 samba 时遇到问题。在 CentOS 上一切都运行良好,但相同的配置在 Fedora 上却出现问题。

我在同一网络上有三台计算机,我们称它们为:A、M 和 L。所有计算机的 smb.conf 中都有相同的[全局]条目。

“A”正在运行 CentOS 7,没有任何问题,并且可以根据 看到 A、M 和 L 的所有主机和共享smbtree

“M”和“L”都运行 Fedora 30,但无法解析任何 NETBIOS 名称(我无法通过主机名 ping 其他计算机),并且在 上看不到任何内容smbtree,甚至看不到它自己的共享。

有趣的是,网络上还有一台 Windows 机器。我们称这台机器为“W”。所有 Linux 系统都可以通过主机名解析该机器并对其执行 ping 操作。问题出在 Linux 机器之间的相互通信上。

smb.conf(所有机器):

[global]
    workgroup = WORKGROUP
    security = user

    passdb backend = tdbsam

    printing = cups
    printcap name = cups
    load printers = yes
    cups options = raw

    hosts allow = 127. 10.0.1.
    ntlm auth = yes

防火墙开放服务(所有机器):

samba ntp dhcpv6-client ssh samba-client

请注意,Fedora 计算机也允许mdns通过防火墙。

就是这样。它应该很简单,但它不起作用。这是怎么回事?

答案1

我终于设法确定了这一点,但我还不明白为什么需要进行其中一些更改。

由于其较旧的代码库,CentOS 7 始终“正常工作”。所有问题都是由于 CentOS 提供原始软件包以来所做的更改造成的。这进一步增强了这些服务器级操作系统及其对较旧且已知稳定的软件包的遵守这一概念的可信度。


NetBIOS 名称解析

NetBIOS 名称解析失败的问题是由firewalld“自动助手”功能造成的。内核 4.9.13 中的 2017-02-26 补丁更改了防火墙服务的默认行为。虽然 的结果firewall-cmd --get-automatic-helpers始终是system,但实际值是在内核中定义的,这就是发生的变化。

要强制执行旧行为,必须显式启用此功能:

firewall-cmd --set-automatic-helpers=yes

重新启动smb和 NetBIOS 名称现在应该可以使用pingnmblookup等。请注意,这是一个安全漏洞。请参阅有关部分安全阅读更多相关内容。在使用 更改此设置之前,请注意系统的默认设置firewall-cmd --get-automatic-helpers

或者,您可以尝试暂时禁用防火墙服务,看看是否有任何影响。


分享可见性

伟大的!现在共享可以工作了,对吧?出色地,或许

尝试查看您的分享:

smbtree -b -N

如果共享可见,那么您就完成了。如果没有,这与 samba 未能与所有可用接口绑定有关。您可以使用以下命令查看所有接口:

ifconfig | grep -Po '^\w+'

将这些接口添加到/etc/samba/smb.conf;就我而言:

interfaces = lo virbr0 wlo1
bind interfaces only = yes

我最初将 Samba 设置为仅允许通过 IP 前缀127.10.0.1.但在查看smb日志时我注意到这条消息:

Denied connection from 192.168.122.1 (192.168.122.1)

192.168.这是来自通过 NAT ( )分配地址的本地虚拟机的被阻止的连接virbr0。将此前缀添加到我的配置中后,我现在可以看到该计算机的共享,但看不到我的10.0.1网络。然后我猜测可能Samba没有绑定到这个接口(wlo1)。我把它添加到我的中smb.conf,突然一切都正常了。我可以浏览共享并访问网络设备。

接口wlo1是无线网卡,不知道为什么没有绑定。我在通过以太网连接的网络上的另一台计算机上遇到了相同的 NetBIOS 问题,并且我不必指定任何接口。这就是为什么我说您的股份可能已经可见,而无需进行此更改。


安全注意事项

根据Linux 内核邮件列表,NetBIOS 解析失败的问题是防火墙“自动帮助程序”功能更改的直接结果:

提交 3bb398d925(“netfilter:nf_ct_helper:禁用自动帮助程序分配”)正在导致防火墙中的行为回归,因为 conntrack 帮助程序处理的流量现在默认不会通过,即使之前由于缺少 CT 目标(这在之前是不必要的)此提交)。

出于安全原因进行更改:

由于安全原因必须关闭默认设置,因此应该保持原样,但是让我们对防火墙管理员友好一点,并在第一次遇到数据包可能通过旧默认值传递的情况时发出警告但我们现在可能会把它扔到地板上。

看:

Arch Linux 文档还提供了很好的总结:

您正在使用防火墙(iptables),因为您不信任您的本地(学校、大学、酒店)网络。这可能是由于以下原因造成的:当 smbclient 浏览本地网络时,它会在 udp 端口​​ 137 上发出广播请求。然后网络上的服务器会回复您的客户端,但由于此回复的源地址与目标地址不同地址 iptables 在发送列表请求时看到,iptables 不会将回复识别为“ESTABLISHED”或“RELATED”,因此数据包被丢弃。

并通过添加显式帮助器iptables而不是过于广泛的自动帮助器来引用可能的解决方案:

iptables -t raw -A OUTPUT -p udp -m udp --dport 137 -j CT --helper netbios-ns

补充阅读:

https://bugzilla.redhat.com/show_bug.cgi?id=1297235

相关内容