解决Kali系统使用OpenVPN时网络无法访问的问题及调试方法甘肃seo教程怎么做

文字总计：999字12图，预计阅读时间：1分钟

使用了这么久，按照之前的配置指南（）进行配置后，在系统、macOS系统和系统上都运行得很好。但后来收到反馈，有朋友在使用Kali时发现了一个小问题，就是连接成功后，也显示有VPN连接，但所有网络都无法访问。

一切看起来都正常，但是网络不通，只有Kali系统有问题，其他系统都使用正常。

看了日志告警，发现还有隧道保活超时提醒，此后一直无法建立连接。

这个时候就要用到debug了。前面提到（），可以通过命令设置日志级别。我们把日志级别配置为4看看有没有效果。

果然，连接完成后，出现了新的提醒。报警如下：

<pre class="code-snippet__js" data-lang="sql"><code>Recursive routing detected, drop tun packet to [AF_INET]</code></pre>

如果按字面翻译，则表示检测到递归路由，并将来自tun接口的数据包丢弃到服务器接口[]。

起初我并没有意识到发生了什么事。我在网上搜索了很长时间，找到了两万多个相关问答，但每个人的答案都很模糊，一直重复着“这道题很简单，答案就在谜语上”。。

然后我又明白了，大概是这样的：主机本身有一条默认路由，指向本地网关；连接成功后，服务器下发了两条可以替代默认路由的详细路由：0.0.0.0/1和128.0.0.0/1，然后发生了微妙的变化。新的访问请求必须到服务器网关，它本身也需要由底层网络承载。

为了验证，我还在HCL上重现了该问题，看看是否是系统问题。

我们首先构建一个包含 3 台设备的网络，然后在 RT1 和 RT3 之间建立 GRE 隧道。

当没有配置新的详细路由时，RT1和RT3流量优先走基于GRE隧道的直连路由，底层基于默认路由转发。

在调试报文转发过程时，可以看到逻辑上报文是从端口发出的，但实际上是从物理接口发出的。

然后，我们在RT1上配置一条静态路由来模拟下发的详细默认路由。

首先可以看到GRE隧道状态没有异常，但是出接口的路由掩码长度是一个GRE隧道接口，比默认路由长1位，符合最长匹配。

此时，我们看一下数据包的调试信息。

可以看到，本应底层转发的报文也进入了GRE隧道，导致报文转发异常。也就是报错中的路由递归问题。

那么如何解决呢？确实，答案就在米面，只要让路由非递归即可。

很简单，只要底层还能找到路到达另一端就可以了。

知道了问题是怎么发生的，Kali的问题就解决了。我们只需要添加到目的网段的详细路由即可。

不过这个连接过程应该是有问题的。我换了另一台服务器测试了一下，发现连接的时候发出了详细的路由。

所以我之前的测试是没有问题的，因为我的服务器一直下发这个详细的路由，但是在Kali所连接的服务器上，并没有这个详细的路由。具体原因我还需要进一步调查。

长按二维码

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。