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

Question

设置： 我有一个 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

Answer 1

你问：“有人能解释一下为什么会出现这个问题吗？ ”

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

为了更好地说明场景，让我参考下图：

在这里你可以看到：

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

还

• 我们假设 OpenVPN 隧道已建立，并且：
  • OpenVPN“服务器”可通过其自己的tun接口访问，地址为 10.10.0.1。另外，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网卡后，数据包到达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 网卡并到达 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 Server 上运行的 OpenVPN 实例。因此，此时，操作系统无事可做，所有路由（在 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 也知道它不是“操作系统路由器”，因此它并不真正想要（并且可以……）将数据包发送回本地网关。因此，这里唯一的选择是引发错误。正是您遇到的错误

用 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 客户端知道如何路由它，因为它知道 VPN 隧道是默认网关。

在 OpenVPN 服务器上不能做同样的事情，因为那里的默认网关通常没有被覆盖。另外，考虑到您可以拥有一个带有大量 OpenVPN 客户端的单个 OpenVPN 服务器：每个客户端都知道如何到达服务器，但是……服务器如何决定哪个客户端充当未知子网的网关？

至于您的第一个问题（是否可以以通用/一次性的方式编写所需的规则？），很抱歉，我没有遇到您的问题。你能改写提供更多细节吗？