VPNnetworking上的某些客户端无法访问

这种模式的问题是有些（只有一些）客户无法联系到。 请参阅下面的链接，以获取有关即将出现的章节中正在描述的模型的更多信息。

问题描述

两个客户端（1.1和1.2.3）都可以连接到VPN服务器（1）。 服务器（1）在OpenVPNconfiguration文件中没有使用客户端到客户端的声明。

服务器（1）可以同时ping两个客户端（1.1和1.2.3），客户端（1.1和1.2.3）可以相互ping通并且可以ping服务器（1）。 位于NAT后面的路由器（1.1）后面的本地客户端（1.1.1和1.1.2）可以互相ping通，并可以ping路由器（1.1）。 其他所有的客户端（1.2.1,1.2.2和1.2.3）都可以互相ping通，也可以ping通路由器（1.2）。 到目前为止没有问题。

• Proxmox 31 + KVM路由+ IP子网+ csf
• 本地局域网上的tracepath慢
• Tap0没有收到stream量
• 路由networking，子网客户端已断开tcp连接
• 如何通过服务器核心安装来configuration和启用NAT

两台路由器（1.1和1.2）都正确设置了它们的静态路由。 第一个networking（1.1）中的路由器没有设置静态路由，它们从VPN服务器被推送。 第二个networking（1.2）中的路由器不是VPN网关，因此他的路由如下：

networking192.168.1.0/24网关192.168.2.103

networking192.168.10.0/24网关192.168.2.103

然后第二个networking（1.2.3）上的VPN客户端再次从服务器上推送他的路由。

回到客户站到达 – 现在这些NAT后面的客户端不能从一个networking到达另一个networking; 一些可以，其他人不能。 举一些例子：

• login到服务器（1），我可以ping 1.1.1，但不能ping 1.1.2。

• 正在login到客户端（1.1.1），我可以ping 1.2.1，但不能ping 1.2.2。

临时修复

对于某些客户端，我可以在添加统计path时看到临时修复，这可以通过Linux机器来完成。 他们的路由表（例如机器1.1.2）可能只包含networking1.1的信息。 为其他networking（1.2）添加静态路由确实能够正常工作，但这是所有客户端无法做到的。

另一个非常临时的解决方法是尝试从1.2.2到1.1.2的traceroute命令，它实际上可能到达机器，然后我可以ping它几分钟。 过了一会儿，路线消失了。

这些都不是永久性的解决scheme。

出现一些问题

我需要说明的是，我刚刚交换了一个路由器1.2，但是所有的路由都和以前的机器一样。

还有其他一些问题出现：

• 这是一个DNS问题？ 如果是这样，为什么ping命令不能使用IP而不是域名？

• traceroute如何工作，ping不通？ 没有防火墙来阻止它，即使是这样，那么trceroute如何强制ping命令在短时间内工作呢？

• 为什么有些客户端不需要设置静态路由，而其他客户端则需要在networking上进行ping命令呢？

• 可能与networking上设备的引导顺序有关吗？ 我也尝试重新启动/closures所有这些，但它不会做任何事情。 这个想法是，内存中的路由将在重新启动时被清除，并且新路由将从路由器“被占用”。

目标

目的是为了解决这个问题，所有networking上的所有客户端都可以访问，除了路由器之外，任何地方都没有静态路由。

iptables -D FORWARD -m state --state INVALID -j DROP