文字总计：999字12图，预计阅读时间：1分钟
使用了这么久，按照之前的配置指南（）进行配置后，在系统、macOS系统和系统上都运行得很好。但后来收到反馈，有朋友在使用Kali时发现了一个小问题，就是连接成功后，也显示有VPN连接，但所有网络都无法访问。
一切看起来都正常，但是网络不通，只有Kali系统有问题，其他系统都使用正常。
看了日志告警，发现还有隧道保活超时提醒，此后一直无法建立连接。
这个时候就要用到debug了。前面提到（），可以通过命令设置日志级别。我们把日志级别配置为4看看有没有效果。
果然，连接完成后，出现了新的提醒。报警如下：
<p style='margin-bottom:15px;color:#555555;font-size:15px;line-height:200%;text-indent:2em
如果按字面翻译，则表示检测到递归路由，并将来自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所连接的服务器上，并没有这个详细的路由。具体原因我还需要进一步调查。
长按二维码
