Samba 为什么拒绝能访问服务器的 VPN 客户端

VPN 客户端能 ping 通文件服务器、能解析它的名字，却依然打不开共享。Samba 的主机策略是可能拒绝该连接的四层之一，也是人们最后才去修改的一层。允许列表是按 smbd 实际收到的源地址来评估的，而它未必是客户端自以为拥有的地址。把源地址弄对，含糊的权限问题就会变成一行配置改动。

四层都会报出同样的错误信息

拒绝可能来自路由、主机防火墙、Samba 主机策略或 SMB 身份。每一层给客户端的提示都差不多，所以靠猜会耗掉一个下午。把检查从网络往内排序，大部分猜测就可以省掉。

先从传输查起。如果 445 端口根本没到服务器，任何 Samba 设置都无关紧要，在服务器网卡上抓一次包几秒钟就能定论。接下来是服务器本机的主机防火墙，它可能在 smbd 看到之前就把合法来源丢掉。只有这两层都过了，允许列表才成为嫌疑对象。身份认证放在最后，因为登录失败和被主机拒绝在服务器日志里长得不一样，即使客户端把两者都说成访问被拒。顺序比工具更重要，因为每一层都有能回答它的命令。

找出 smbd 实际看到的源地址

在路由式访问下，服务器通常看到的是 VPN 地址池里的客户端地址。若网关做了源地址转换，它看到的则是网关的 LAN 地址，于是网关后面的所有客户端都变得无法区分。

这个差别决定了允许列表里的一条记录是策略还是漏洞。允许一个被转换过的网关地址，就等于放行它后面的所有人，而按客户端设置规则很少是这个意思。源地址要在服务器上读，不要靠客户端对自己地址的想象。在服务器网卡上抓包是看清它最便宜的办法，同一次抓包还能证明报文到底有没有到。用报文数量限制抓包，确定在跟哪个客户端之后再加主机过滤。Samba 的会话表是答案的另一半：smbstatus -b 里每个会话行的客户端列就是 smbd 记录下来的对端，这是对真正到达服务的地址最快的确认。

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

按 Samba 的读法去读允许列表

hosts allow 接受地址、网段或名字的列表，可以写在全局，也可以写在共享里面。两条在你看来等价的记录，对解析器未必等价，所以要检查的是实际生效的配置。也就是说要看合并后的视图，而不是你碰巧改过的那份文件。

一对示例前缀看起来像下面这行，这只是示例，不是对已有条目的替换。保留今天合法连接的管理端和应用端客户端，并顺手把任何拒绝列表也读一遍。主机能否被接受取决于整体策略，所以直接测试那个确切的客户端，而不是推理优先级。主机权限也不说明共享权限或文件系统模式，那些是另外的关卡。测试工具成功只说明主机策略放行了这个源，并不说明别的。

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

改那个重启之后仍然存在的文件

在普通 Linux 主机上配置路径是固定的，服务重启时会重新读取。在路由器或设备上，运行中的 smb.conf 往往是开机时生成的，手工改动下次重启就没了。要用设备支持的定制机制，通常就是它自己的配置文件。

此时最诱人的做法是因为某个帖子说能用就去刷第三方固件。对小策略问题来说这是大改动，还会让设备脱离受支持状态。先确认受支持的控制方式，因为多数设备都通过自己的界面提供允许列表。如果确实没有，这个限制是换硬件的理由，而不是用不受支持构建的理由。

记录你改了哪个文件、什么会重新生成它，下一个人就不必重做诊断。

分别测一个被允许和一个被排除的客户端

两个结果都要测，不只测你想要的那个。被允许的客户端能连接，说明改动能生效；被排除的客户端仍被拒绝，说明规则并不是简单地全放开。

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

如果连接根本到不了 smbd，答案在路由或服务器防火墙里。如果主机被允许而登录失败，问题就是身份，继续放宽允许列表没有用。诊断输出要保密，详细的 Samba 日志可能暴露共享路径和账户名。每次只改一层，否则下一次结果什么也告诉不了你。