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

安装程序:我有一个openvpn客户端/服务器设置(底部的configuration文件),并MULTI: bad source address from client [192.168.xx], packet dropped得到臭名昭着的MULTI: bad source address from client [192.168.xx], packet dropped在服务器MULTI: bad source address from client [192.168.xx], packet dropped 。 服务器有一个公共IP地址,而客户端在NAT后面。

先前提出的解决scheme的缺点:服务器configuration中定义的client-config-dir目前是空的。 以前的post(这里和openvpn支持论坛)build议在client-config-dir添加一个名为DEFAULT的文件,或者添加一个用户文件来解决这个问题。

但是,这似乎不是一个长期的解决scheme,因为这些规则是特定于客户端的。 所以,我可以添加一个规则来允许来自192.168.x.0客户端连接。 但是,如果他们从另一个使用192.168.y.0networking连接NAT,则需要新的规则。

问题:

  • 所需的规则是否可以用通用/一次性的方式写成?
  • 有人可以解释为什么这个问题首先发生?

服务器configuration:

 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 

客户端configuration:

 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常见问题解答报告,我敢打赌,这是由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会发生什么。

  1. 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地址与之通信”。 感谢这样的静态路线,现在…

  1. 数据包将离开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作为它的网关。

这为我修好了。