MULTI：客户端报“源地址错误”：这个地址属于谁

服务器日志会打印 MULTI: bad source address from client，丢弃数据包，但会话仍保持连接。把这条消息当成认证失败的人，往往会被这一组合弄糊涂。事实并非如此：客户端已通过认证，而到达的数据包携带的内网源地址无法被服务器关联到该客户端实例。检查发生在投递之前，所以隧道看起来正常，实际却没有任何有用的流量通过。

服务器在投递前比较什么

对每个来自客户端的数据包，用户态服务器会查看隧道内的源地址，并向内部路由状态询问该地址归哪个客户端所有。如果所有者是另一个实例，或者根本没有所有者，数据包就会被清除，并给出这条警告。

经由隧道接口的常规投递从来不会发生。

这个顺序解释了一个令人困惑的细节：主机防火墙的计数器纹丝不动，因为数据包从未到达防火墙。在主机上调整反向路径过滤在这里毫无作用，因为拒绝发生在守护进程自己的归属检查中。请把这条消息理解为关于归属的陈述，然后再判断是三种情况中的哪一种造成的。

内部地址不匹配的三种来源

客户端可能从并未分配给它的地址发送，从没人声明属于它的网络发送，或从已有所有者的身份副本发送。三者都会产生同一行日志。它们的区别在于你需要改什么。先看地址和当前分配列表，让这两个事实来选定情形。

要区分它们需要两个事实：日志中被拒绝的地址，以及服务器认为当前有效的分配。后者可以从运行实例的状态或管理视图中获得，也是唯一值得查询的权威，因为配置文件记录的是意图，而不是当前状态。

在改动任何东西之前把两者都记录下来，然后再分类。事后截的图不是产生该警告时状态的记录。还要保留时间戳，因为分配会在会话之间变动。

客户端背后的局域网与 iroute

当站点客户端路由自己的私有网络时，必须声明该网络归该客户端所有。带 iroute 条目的客户端专属文件可以做到这一点，该条目指定客户端获准携带的前缀。

指向同一前缀的内核路由是另一项独立要求，添加它不会改变守护进程的内部归属。

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

确认生效身份与文件名一致，因为不一致意味着该文件根本不会被加载，症状与条目缺失完全相同。不要为了压掉警告而添加宽泛的 iroute，那会把意外来源变成获准来源，却没有回答客户端为何发送它。OpenVPN 2.6 手册把 iroute、duplicate-cn 和身份映射记载为彼此独立的控制项。

两台机器上的同一身份

复制到第二台笔记本的配置文件带有相同的证书和相同的通用名。取决于服务器设置，较新的连接可以替换较旧的连接，而持有归属的实例会赢得归属检查。

这让故障显得时有时无，只在两台设备都唤醒时才出现。

允许多个相同通用名可以让两者都连上，但不会给它们独立的静态地址或独立的归属。如果两台设备必须共存，请分别注册，让各自拥有自己的身份和分配。把重复设置当成这条警告的修复，谜团仍在，还会多出一个。

证明归属确实变了

通过配置所有者应用修改，然后重新连接受影响的客户端，让新策略生效。

重复同样的流程，确认三件事：数据包的内网源地址、服务器与之关联的客户端实例，以及之后目的地的行为。

如果警告消失但应用仍然失败，问题只是挪了位置，并没有消失。转发、防火墙规则和返回路径是彼此分离的阶段，通过归属检查只意味着这个数据包获准离开隧道。