MULTI：来自客户端的错误的源地址-任何一次性解决方案？

设置： 我有一个openvpn客户端/服务器设置（底部的配置文件），并且MULTI: bad source address from client [192.168.x.x], packet dropped在服务器上收到了臭名昭著的消息。服务器具有公共IP地址，而客户端位于NAT之后。

先前提出的解决方案的不足之处： 该client-config-dir服务器配置目前是空的定义。以前的帖子（在此处以及在openvpn支持论坛中）建议在中添加DEFAULT带有正确规则的文件client-config-dir，或为每个用户添加具有这些规则的文件以解决问题。

但是，这似乎不是一个长期解决方案，因为这些规则是特定于客户端位置的。因此，我可以添加一条规则以允许客户端192.168.x.0进行连接。但是，如果它们从另一个192.168.y.0用于NAT的网络连接，则将需要一条新规则。

问题：

• 可以以通用/一次性方式编写所需的规则吗？
• 有人可以解释为什么首先出现此问题吗？

服务器配置：

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

客户端配置：

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

您问：“ 有人可以首先解释为什么会出现此问题吗？ ”

根据官方OpenVPN FAQ中的报道，我敢打赌这是由OpenVPN引擎内的路由问题引起的。

为了更好地阐明这种情况，让我参考下图：

在这里您可以看到：

• 连接到HEADQUARTER内部网络（10.0.1.0/24）的OpenVPN“服务器”
• 在远程站点上运行并连接到远程192.168.1.0/24网络的OpenVPN“客户端”

也

• 我们假设已建立OpenVPN隧道，并且：
  • 可通过其自己的tun接口（地址为10.10.0.1 ）访问OpenVPN“服务器” 。tun接口使用的P2P地址也是10.10.0.2（这对于以后的讨论很重要，因此让我们强调一下）
  • OpenVPN“客户端”具有IP 10.10.0.2 的tun接口

现在，我们假设：

• OpenVPN“客户端”已经重新定义了其默认网关，因此可以在隧道内重定向所有传出IP流量；
• OpenVPN“客户端”已启用IP_FORWARDING，因此可以路由来自其内部LAN（192.168.1.0/24）的数据包（我强调这一点，因为这对于我们的讨论至关重要）。

在这种情况下，让我们详细检查一下R_PC1（192.168.1.2）向L_PC1（10.0.1.2）发送一个数据包（如回声请求）时会发生什么：

1. 离开R_PC1 NIC后，数据包到达OpenVPN客户端；
2. OpenVPN客户端（配置为充当通用路由器），根据其路由表进行路由。因为它的默认网关是隧道，所以它将数据包发送到隧道。
3. 数据包到达OpenVPN服务器的tun接口。OpenVPN将“看到”它，并且，因为它（OpenVPN服务器）知道10.0.1.2是属于其LAN子网的地址，因此它会将数据包从TUN转发到LAN；
4. 数据包到达L_PC1。

所以一切都很好...

现在，让我们检查一下L_PC1回复R_PC1的回声回复。

5. echo-r​​eply离开L_PC1 NIC并到达OpenVPN服务器LAN接口（10.0.1.1）;

现在，如果我们希望OpenVPN Server能够访问远程站点，则需要使用“静态路由”定义路由。就像是：

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

请注意用作网关的P2P地址。

这样的静态路由将在操作系统级别运行。换句话说，操作系统需要正确地路由数据包。意思是：“请把所有发送到192.168.1.0/24子网的流量都转发到OpenVPN引擎，操作系统可以通过P2P地址与之通信”。有了这样的静态路线，现在...

6. 数据包离开操作系统路由上下文并到达OpenVPN。在OpenVPN服务器上运行的OpenVPN实例。因此，此时，OS无需执行任何操作，所有路由（VPN内）都留给了OpenVPN服务器软件。

因此，现在的问题是：openvpn服务器软件如何通过SRC_IP 10.0.1.2和DST_IP 192.168.1.2来决定数据包的路由？

请注意，基于OpenVPN服务器的配置，它对192.168.1.0/24网络或192.168.1.2主机一无所知。它不是连接的客户端。这不是本地客户。所以？OpenVPN也知道它不是 “ OS-Router”，因此它实际上并不想（也可以...）将数据包发送回本地网关。因此，这里唯一的选择是引发错误。确实是您遇到的错误

用FAQ的语言来说：“ ...它不知道如何将数据包路由到这台机器，因此它丢弃了数据包... ”。

我们如何解决这个问题？

从官方文档可以看到，选项iroute完全适用于我们的范围：

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

因此，您需要：

--iroute 192.168.1.0 255.255.255.0

当您的OpenVPN客户端连接时（例如通过服务器上定义的临时配置文件（client-config-dir等））应用（应用于服务器）。

如果您想知道为什么在上面的步骤2）中不会发生此问题，我的理解是OpenVPN Client 知道如何进行路由，因为它知道VPN隧道是默认网关。

无法在OpenVPN Server上执行相同的操作，因为默认网关通常不会被覆盖。另外，请考虑您可能有一台带有大量OpenVPN客户端的OpenVPN服务器：每个客户端都知道如何访问该服务器，但是...该服务器如何确定哪个客户端充当未知子网的网关？

关于您的第一个问题（可以以通用/一次性的方式编写所需的规则吗？），很抱歉，但是我没有遇到太大的问题。您可以改写提供更多详细信息吗？

我有一个看似相似的问题，但不确定是否与您的问题相同。我试图从openvpn客户端ping通到openvpn服务器的本地网络中的计算机（在服务器的配置中路由），没有得到答复，我可以在服务器的openvpn日志中看到“错误的源地址”消息。

为了解决这个问题，我必须做两件事：

1. 在服务器上启用IP转发。
2. 在服务器网关上为vpn子网添加路由，因为在我的情况下，服务器本地网络的网关不是服务器本身，而是路由器。被查验的计算机试图通过网关答复，网关不知道如何对vpn子网进行处理。因此，我在路由器中添加了一条静态路由，使用vpn子网作为目的地，并使用openvpn服务器的ip作为其网关。

这为我解决了。