MULTI：来自客户端的不良来源地址 – 任何一次性解决scheme？

你问：“ 有人能解释为什么这个问题首先发生吗？

根据官方OpenVPN常见问题解答报告，我敢打赌，这是由OpenVPN引擎中的路由问题造成的。

为了更好地说明情况，请参考下图：

在这里你可以看到：

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

也

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

现在假设：

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

在这种情况下，让我们来详细检查R_PC1（192.168.1.2）发送数据包（如回显请求）到L_PC1（10.0.1.2）时发生的情况：

1. 在离开R_PC1网卡后，数据包到达OpenVPN客户端;
2. OpenVPN客户端（configuration为普通路由器），根据路由表进行路由。 因为它的默认网关是隧道，它将数据包发送到隧道;
3. 数据包到达OpenVPN服务器的tun接口。 OpenVPN将“看到”它，并且，因为它（OpenVPN服务器）知道10.0.1.2是属于它的LAN子网的一个地址，它“转发”数据包，从TUN到LAN;
4. 数据包到达L_PC1。

所以一切都很好

现在让我们来看看L_PC1回复给R_PC1的echo-r​​eply会发生什么。

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

现在，如果我们希望OpenVPN服务器能够到达远程站点，我们需要使用“静态路由”来定义路由。 就像是：

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

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

这样的静态路由将在操作系统级别运行。 换句话说，操作系统需要正确路由数据包。 这意味着类似于：“请将发往192.168.1.0/24子网的所有stream量都转发到OpenVPN引擎，操作系统可以通过P2P地址与之通信”。 感谢这样的静态路线，现在…

6. 数据包将离开OS路由上下文并到达OpenVPN。 运行在OpenVPN服务器上的OpenVPN实例。 因此，在这一点上，操作系统没有什么可做的了，所有的路由（在VPN内）都留给了OpenVPN服务器软件。

所以，现在的问题是： openvpn服务器软件如何能够使用SRC_IP 10.0.1.2和DST_IP 192.168.1.2来决定数据包的路由 ？

请注意，根据OpenVPN服务器的configuration，它对192.168.1.0/24networking和192.168.1.2主机一无所知 。 这不是一个连接的客户端。 这不是一个本地客户端。 所以？ OpenVPN也知道它不是 “OS-Router”，因此它并不真正想要（也可以）将数据包发送回本地网关。 所以这里唯一的select是提出一个错误。 确实是你遇到的错误

用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客户端连接时（例如，通过服务器上定义的临时configuration文件（client-config-dir等））应用（到服务器）。

如果你想知道为什么这个问题没有发生在上面的步骤2），我的理解是OpenVPN客户端知道如何路由它，因为它知道VPN隧道是一个默认网关。

在OpenVPN服务器上也是一样，因为那里的默认网关是不会被覆盖的。 另外，考虑到你可以有一个OpenVPN的服务器与大量的OpenVPN客户端：每个客户端知道如何到达服务器，但是…服务器如何能够决定哪个客户端充当未知子网的网关？

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

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

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

1. 在服务器上启用IP转发。
2. 在服务器的网关上添加vpn子网的路由，因为在我的情况下，服务器本地networking的网关不是服务器本身，而是路由器。 计算机试图通过网关进行回复，该网关不知道如何处理vpn子网。 所以我在路由器上添加了一个静态路由，使用目的地的vpn子网，而openvpn服务器的ip作为它的网关。

这为我修好了。